inputstreamreader仅负责字节流到字符流的编码转换，不处理压缩或加密；读取压缩/加密数据需先解压或解密得到原始字节流，再交由inputstreamreader按指定字符集转换。
InputStreamReader 本身不处理压缩或加密，它只负责字节流到字符流的编码转换。要读取压缩/加密后的数据，必须先解压或解密得到原始字节流，再交给 InputStreamReader。
先解压再转字符（如 GZIP、ZIP）
压缩流（如 GZIPInputStream、ZipInputStream）是 FilterInputStream 的子类，可嵌套在原始 InputStream 外层。解压后得到的是原始字节，再用 InputStreamReader 指定正确字符集即可还原文本。
- 确保解压后字节序列符合目标字符编码（如 UTF-8），否则 InputStreamReader 会乱码
- 推荐显式传入 Charset，避免依赖平台默认编码：
new InputStreamReader(new GZIPInputStream(in), StandardCharsets.UTF_8) - ZIP 文件中若含多个条目，需先用
ZipInputStream.getNextEntry()定位具体文件条目，再包装 InputStreamReader
先解密再转字符（如 AES、DES）
解密操作必须在 InputStreamReader 之前完成，因为 InputStreamReader 不认识密文格式。通常使用 CipherInputStream 包裹解密后的字节流。
- 解密前需正确初始化 Cipher（包括算法、模式、填充、密钥、IV），且与加密端严格一致
- CipherInputStream 会自动按块解密并输出明文字节，后续可安全传递给 InputStreamReader
- 注意：如果解密后内容本身是某种编码（如 UTF-8），则 InputStreamReader 的 charset 必须匹配，否则仍会乱码
组合使用时的典型顺序
实际流程是“原始源 → 解密 → 解压 → 编码转换”，对应流包装顺序为：
- 原始输入流（如 FileInputStream）
- → CipherInputStream（解密）
- → GZIPInputStream（解压）
- → InputStreamReader（指定 charset）
反向顺序会导致异常（例如先解压再解密，会因密文非合法 GZIP 格式而抛 IOException）。
注意事项与常见坑
字符编码和加解密/压缩是正交问题，但容易混淆。关键点：
- InputStreamReader 的 charset 参数只影响字节→字符的解释方式，不参与任何解密或解压逻辑
- 不要试图用 InputStreamReader 直接读取 .zip 或 .aes 文件——它无法识别这些格式
- 资源务必按包装逆序关闭（最外层 InputStreamReader 关闭时，通常会级联关闭内层流；但为保险起见，建议用 try-with-resources）
- 如果加解密/压缩过程有校验（如 MAC、CRC），应在解密/解压后验证，再交给 InputStreamReader，避免处理损坏数据
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
