UTF-8 编码/解码

UTF-8 字节与文本的相互转换：为什么会出现乱码

UTF-8 是什么层级的编码

Unicode 给每个字符分配一个码点（如 U+4E2D），UTF-8 规定了码点如何变成字节序列。这套规则是变长的：

ASCII 兼容是它取代 UTF-16、GBK 成为事实标准的关键原因：英文文本在 UTF-8 下字节数和 ASCII 完全一样，老系统读新文件不会崩。

乱码的三种成因

• 编码/解码用的字符集不一致。用 GBK 编码的中文，按 UTF-8 解码，得到的是"锟斤拷"或一串问号。这是最常见的一类。
• 丢失了原始字节。例如把非 UTF-8 字节强行按 UTF-8 解码成字符串，遇到非法序列时被替换成 U+FFFD，原始信息已经不可逆地丢失——之后无论怎么转都还原不回来。
• UTF-8 BOM 被当成内容。文件开头有 EF BB BF，某些解析器会把它当正文的一部分，导致第一行多出不可见字符。Windows 记事本保存 UTF-8 时默认加 BOM，这是跨平台文件出问题的常见原因。

这个工具怎么用

它做的是可逆的字节级转换，不做字符集猜测：输入文本按 UTF-8 编码成字节序列（可选十六进制、十进制、二进制或转义形式），或者把字节序列按 UTF-8 解码回文本。

判断数据是否已经损坏的方法：把文本转成字节，再原样转回来。如果结果与原文本一致，说明往返无损，问题出在别处（多半是通道或存储环节的字符集假设）；如果往返就已经不一致，说明数据在更早的环节已经经历过一次有损解码，需要回到源头取原始字节。

常见的排查顺序：确认 HTTP 响应头的 Content-Type 是否带 charset=utf-8 → 确认数据库连接与列的字符集 → 确认文件读写时是否显式指定了编码。这三处任一处按平台默认值处理，都会产生同一类故障。