ISO_8859_1转UTF-8两种方式差异：为何第一种转换不符合预期？

第一种方式失效的核心是两次编码/解码过程中出现了不可逆的字节损坏，具体拆解如下：

• 当你用new BufferedReader(new InputStreamReader(inputStream))时，InputStreamReader会使用当前系统的默认字符集（比如Windows的GBK、Linux/macOS的UTF-8）解码输入流字节。如果输入流实际是ISO-8859-1编码，默认字符集无法识别部分字节（比如ISO-8859-1的0x80-0xFF范围字节），会把这些字节替换成�（Unicode替换字符U+FFFD）。
• 后续调用readLine().getBytes(StandardCharsets.ISO_8859_1)时，�会被转换成ISO-8859-1对应的字节0x3F（问号），这一步直接丢失了原始字节的信息。
• 最后再转成UTF-8时，得到的只能是问号或乱码，完全无法还原原始正确字符。

而第二种方式直接用ISO-8859-1作为InputStreamReader的解码字符集，每个字节都会被精准映射到对应的ISO-8859-1字符，没有中间替换的损耗，所以能正常识别。

内容的提问来源于stack exchange，提问作者pawel asdasdad