Java字符编码转换导致的数据丢失本质是字节与字符映射断裂，而非精度问题；解决关键在于避免隐式转换、确保编解码一致、绕过不兼容编码路径，如禁用ISO-8859-1处理中文，全程显式指定Charset，并从源头确认真实编码。
Java 中字符编码转换导致的数据丢失，本质不是“精度”问题，而是字节与字符映射断裂——比如用错误的编码解码字节流，或在不支持目标字符的编码间强行转换（如用 ISO-8859-1 存中文），造成不可逆截断。解决关键在于：**避免隐式转换、确保编解码一致、绕过不兼容编码路径**。
确认原始编码再操作
数据丢失常源于“猜编码”。必须明确字节来源的真实编码，不能凭文件后缀或系统默认推测。
- 查看数据源头：数据库连接字符串是否带
?characterEncoding=GBK；HTTP 请求头是否有Content-Type: text/plain; charset=windows-1252；老系统文档是否注明存储为latin1但实际存的是 GBK 字节 - 用十六进制工具（如
xxd或在线 hex 查看器）打开文件，观察中文字符对应的字节序列。例如 “中” 在 GBK 中是B5 D6，在 UTF-8 中是E4 B8 AD，比对可反推原始编码 - Java 中验证：用
StandardCharsets.ISO_8859_1读取字节后转成字符串，再调用.getBytes("GBK")，若结果与原始字节一致，说明原编码极可能是 GBK
禁止使用不支持中文的中间编码
ISO-8859-1、US-ASCII 等单字节编码无法表示中文。一旦用它们解码含中文的字节，就会丢失信息且不可恢复。
- 绝对避免：
new String(bytes, "ISO-8859-1")后再转 UTF-8 —— 这会把两个 GBK 字节硬塞进一个 Latin-1 字符，丢掉一半信息 - 正确做法：跳过 Latin-1，直接用原始编码（如 GBK）解码 → 得到正确 Unicode 字符串 → 再用 UTF-8 编码输出
- 示例（修复老系统 latin1 表存 GBK 字节）：
String gbkBytesAsLatin1 = new String(dbBytes, StandardCharsets.ISO_8859_1);
// 此时 gbkBytesAsLatin1 是损坏字符串，不可逆
// 应改为：
String correct = new String(dbBytes, "GBK"); // 直接按真实编码解码
文件与流操作全程显式指定 Charset
FileReader、FileWriter、Properties.load() 等 API 若不传 Charset，会用系统默认编码（Windows 常为 GBK），跨平台必出错。
立即学习“Java免费学习笔记（深入）”；
- 读文件：用
Files.readAllLines(path, StandardCharsets.UTF_8)或new InputStreamReader(new FileInputStream(f), StandardCharsets.UTF_8) - 写文件：用
Files.write(path, lines, StandardCharsets.UTF_8)，禁用FileWriter(f) - 解析 HTTP 响应体：优先用客户端自动识别（如 OkHttp 的
response.body().string()），若手动处理，先取响应头Content-Type中的 charset，再用对应编码解码response.body().bytes()
数据库场景的特殊处理
当无法修改数据库字符集（如老库用 latin1 却存了 GBK 字节），需在 Java 层做“字节透传+精准解码”。
- JDBC 连接参数保持
?useUnicode=true&characterEncoding=latin1（防止驱动自动转码） - 查询后，对字段值用
String.getBytes(StandardCharsets.ISO_8859_1)拿回原始字节，再用new String(rawBytes, "GBK")重建字符串 - MyBatis 中可在 resultType 映射后加拦截器，统一处理字段解码；或在 SQL 层用
CONVERT(CAST(col AS BINARY) USING gbk)（MySQL 8.0+）
