InputStreamReader 不处理加密 Header，必须先解密再解码：需在字节层面完成解密（含 IV 提取、magic 验证、AES 解密等），剥离或跳过 Header 后，将纯净明文字节流传给 InputStreamReader 按指定编码转换为字符。
InputStreamReader 本身不处理加密 Header，它只负责字节到字符的解码转换。如果文件带有加密 Header（比如自定义密钥标识、校验块、AES 加密头等），必须在交给 InputStreamReader 之前完成解密，否则会因数据被加密而无法正确解码，直接导致乱码或 IOException。
先解密，再用 InputStreamReader 转换
InputStreamReader 的职责非常明确：接收原始字节流，按指定编码（如 UTF-8）将字节解码为字符。它不解析协议、不解密、不跳过头部——它把传给它的每一个字节都当作待解码内容。因此，带加密 Header 的文件必须走“解密 → 剥离 Header（如有）→ 提供纯文本字节流”这一前置流程。
- 若 Header 是固定长度（如前 32 字节为 AES IV + 密钥标识），可用
InputStream包装器（如SkipInputStream或手动skip()）跳过；但必须确保跳过的字节已参与解密逻辑，不能跳过密文主体 - 若整个文件含 Header 且整体加密（如用 AES/CBC 加密了包括 Header 在内的全部内容），需先用对应密钥和算法完整解密，再将解密后的
ByteArrayInputStream或CipherInputStream传给 InputStreamReader - 常见错误：直接把加密后的
FileInputStream包进InputStreamReader(..., "UTF-8")—— 此时读出的不是中文或 ASCII，而是解密失败的乱码二进制解释，readLine()很可能提前抛出MalformedInputException
典型安全处理链路示例
以 AES-128-CBC 加密的 UTF-8 文本文件为例（Header 含 16 字节 IV + 4 字节 magic number）：
- 用
FileInputStream读取全文件 - 提取前 16 字节作为 IV，验证后 4 字节 magic（如
0x454E4352表示 "ENCR"） - 用 IV 和密钥初始化
Cipher，解密剩余字节得到明文byte[] - 将明文字节数组包装为
ByteArrayInputStream -
此时才传给
new InputStreamReader(bais, "UTF-8")，后续交由BufferedReader按行读取
避免编码与解密顺序错乱
关键原则：解密是字节层面操作，编码/解码是字符层面操作，二者不可颠倒。
立即学习“Java免费学习笔记（深入）”；
- 错误做法：用
InputStreamReader先读加密字节 → 转成 String → 再尝试解密字符串 → 结果因编码损失（如字节截断、替换）彻底失败 - 正确做法：始终在
byte[]或InputStream层面完成解密，确保传给 InputStreamReader 的是标准 UTF-8（或其他目标编码）的纯净字节序列 - 若 Header 中嵌入了实际编码信息（如 Header 第20字节标明 “01=GBK, 02=UTF8”），需先解析 Header 获取 charsetName，再动态构造
InputStreamReader(decryptedStream, charsetName)
不推荐绕过解密直接“适配”
试图让 InputStreamReader “兼容”加密 Header 是无效的。例如：
- 设置
charsetName = "ISO-8859-1"强行读取——只能得到加密后的字节直译，无法还原原文 - 用
String(byte[], 0, len)构造再转码——同样因未解密，结果仍是无意义字符串 - 依赖
BufferedReader.mark()/reset()回退跳过 Header——InputStreamReader 不支持 mark（调用会抛IOException("reset() not supported")）
