Android与JVM在InputStreamReader行为差异的核心在于默认字符集来源不同：JVM由系统locale和-Dfile.encoding决定，Android则固定返回UTF-8；因此必须显式指定Charset（如StandardCharsets.UTF_8），避免依赖默认值导致乱码或签名不一致。
Android 和 JVM（标准 Java）在 InputStreamReader 行为上的差异，核心不在 InputStreamReader 本身，而在于底层默认字符集（Charset.defaultCharset()）的来源与稳定性不同。这种差异直接影响未显式指定编码时的文本解析结果，尤其在跨平台文件读取或网络响应处理中容易引发乱码或签名不一致问题。
Android 与 JVM 默认编码机制本质不同
标准 JVM（Java 8–17）的 defaultCharset() 由操作系统 locale 和启动参数 -Dfile.encoding 共同决定，Windows 常为 GBK/Cp1252，Linux/macOS 多为 UTF-8；而 Android 的 Charset.defaultCharset() 在绝大多数版本中**固定返回 UTF-8**（自 Android 7.0 起已稳定），且不受系统语言设置影响——它不读取 locale，也不响应 -Dfile.encoding（该参数在 Android 上无效）。
这意味着：
- 同一段无参
new InputStreamReader(is)代码，在 Windows JVM 上可能用 GBK 解码，在 Android 上始终用 UTF-8 - 若源文件是 UTF-8 编码，Android 表现正常；JVM 则可能因平台默认编码错配而乱码
- 若源文件是 GBK 编码，Android 必然乱码；JVM 在中文 Windows 下反而可能正确
InputStreamReader 构造必须显式传入 Charset
依赖默认编码是不可靠的，尤其在混合部署（如 Java 后端 + Android 客户端共用一套协议或配置文件）场景下。适配的关键不是“兼容默认值”，而是**主动切断对 defaultCharset 的依赖**：
立即学习“Java免费学习笔记（深入）”；
- 永远避免
new InputStreamReader(inputStream)—— 这是乱码高发源头 - 统一使用
new InputStreamReader(inputStream, StandardCharsets.UTF_8)，类型安全、无异常、语义明确 - 若需支持 GBK/ISO-8859-1 等旧编码（如解析遗留 Windows 记事本文件），也必须显式传入对应
Charset，而非靠探测或猜测 - Android 上虽默认 UTF-8，但显式声明可防止未来 API 变更或低版本兼容风险（如 Android 4.x 部分 ROM 存在非 UTF-8 默认行为）
文件读取链路需全程编码对齐
仅设置 InputStreamReader 编码还不够。常见陷阱是：文件以 UTF-8 读入成 String，后续又调用 string.getBytes() 转回字节——此时若未指定编码，JVM 仍可能用系统默认编码（Java 17 及之前），而 Android 固定为 UTF-8，导致两端字节序列不一致（例如用于校验或加密）。
正确做法：
- 读取阶段：
Files.newBufferedReader(path, StandardCharsets.UTF_8)或new InputStreamReader(new FileInputStream(f), StandardCharsets.UTF_8) - 字符串转字节阶段：
str.getBytes(StandardCharsets.UTF_8)—— 绝不使用无参getBytes() - 若涉及 MD5/SHA 签名，确保整个字节生成路径（读取 → 字符串 → 编码 → 摘要）在 Android 和 JVM 上采用完全相同的 Charset 实例
特殊场景：BOM 和自动编码探测慎用
Android 不支持 BOM 自动识别（如 InputStreamReader 不会跳过 UTF-8 BOM），而部分 JVM 工具类（如 Apache Commons IO 的 FileUtils.readFileToString）可能尝试探测 BOM 并切换编码。这种行为在两端不一致，易造成隐性差异。
建议策略：
- 禁用自动探测：所有文本输入流一律按约定编码打开，不依赖 BOM 或启发式判断
- 若必须兼容带 BOM 的 UTF-8 文件，在读取前手动检查并跳过 EF BB BF 字节头，再交由 UTF-8
InputStreamReader处理 - 网络响应中优先依据 HTTP
Content-Type头的 charset 字段（Android OkHttp 和 JVM HttpClient 均支持），而非 body 内容特征
