UTF-16 LE转UTF-8全攻略：从原理到代码实践

在实际开发中把 UTF-16 LE 的文本转换成 UTF-8 的文本是一类很常见的编码迁移任务。Windows 记事本的“Unicode”另存为在很长一段时间里实际写出的就是 UTF-16 LE旧版日志系统、ERP 导出的 txt、部分 Windows 软件生成的配置文件也可能是 UTF-16 LE。这些文件一旦交给 Linux Shell、Web 后端、Java 服务或前端页面往往会显示成乱码原因不是字符内容被破坏而是不同程序对同一串字节使用了不同的解码规则。下面从编码原理、命令行工具、Python 脚本、Windows PowerShell、Java 实现和结果验证几个角度把 UTF-16 LE 转 UTF-8 的完整做法梳理清楚。1. 先理解 UTF-16 LE 和 UTF-8 到底存了什么1.1 Unicode 字符、编码方案和字节序要分开看“UTF-16 LE”和“UTF-8”都是 Unicode 的编码方案。它们表示的是同一个字符表只是把字符写成字节时的规则不同。先明确两个概念“字符”在 Unicode 中有一个编号叫码点例如汉字“编”的码点是 U7F16。“编码”决定这个码点如何变成字节。UTF-8 和 UTF-16 对同一个 U7F16 会写出完全不同的字节序列。UTF-8 是变长编码大部分常用汉字占 3 个字节ASCII 字符占 1 个字节。UTF-16 基本用 2 字节表示一个码元常用汉字绝大多数在 BMP 内因此占 2 个字节但增补平面字符需要用 4 字节的代理对表示。UTF-16 LE 中的 LE 是 Little Endian即小端字节序。它的含义是一个 UTF-16 码元占 2 字节低字节先写高字节后写。比如字符“编”的码点是 U7F16写成 UTF-16 LE 就是16 7F如果写成 UTF-16 BE则是7F 16所以“LE”不是编码格式的全部“UTF-16 LE”规定了码元内部低字节在前这一点直接决定了我们解码时不能把字节顺序搞反。1.2 一个汉字在两种目标编码中的字节差异以文本“编”为例。它只有一个字符但写成 UTF-16 LE 和 UTF-8 后文件体积会明显不同。UTF-16 LE 表示0x16 0x7FUTF-8 表示0xE7 0xBC 0x96也就是说如果文件里全部是中文字符UTF-16 LE 文件约为每个汉字 2 字节UTF-8 文件约为每个汉字 3 字节。转换后文件变大是正常现象不能用“文件变大就是转错了”作为判断标准。再看一个混合场景。如果文本是“编A”在 UTF-16 LE 下“编”是两个字节ASCII 字符“A”也会占用两个字节其中高位补 00x16 0x7F 0x41 0x00在 UTF-8 下“A”只占一个字节0xE7 0xBC 0x96 0x41这就是为什么用十六进制编辑器打开 UTF-16 LE 文件时会看到大量00字节。这些00不是文件出错而是 ASCII 字符在高位补出的零字节。转换成 UTF-8 后这些多余的空字节会消失。1.3 BOM 的作用和容易误解的地方BOM 是 Unicode 编码文件中可选的一段开头标记作用是让读取方判断文件用的是哪种编码和字节序。编码BOM 十六进制UTF-16 LEFF FEUTF-16 BEFE FFUTF-8 带 BOMEF BB BFWindows 记事本保存为“Unicode”时文件开头通常会有FF FE这是 UTF-16 LE 的 BOM。很多 Windows 程序在读取时会通过FF FE自动判断出 UTF-16 LE不需要用户手动选择编码。但这带来一个常见陷阱如果文件带 BOM而我们又用UTF-16LE作为源编码去转换有些工具会把开头的FF FE当作字符 UFEFF 而不是 BOM 来处理导致转换结果开头多出一个不可见字符。因此后续所有命令和代码都要先考虑“源文件是否有 BOM”不能盲目指定编码。注意BOM 只能作为编码判断的辅助信息不是文件编码的绝对保证。有些程序生成文件时不会写 BOM这时候必须依靠外部约定或内容采样来确认编码。2. 动手前先判断源文件编码再决定转换命令2.1 用 file 命令得到初步结论在 Linux 或 macOS 上可以用file命令快速查看文件编码。假设文件名为input_utf16le.txt执行file input_utf16le.txt如果文件带 UTF-16 LE 的 BOM正常会看到类似输出input_utf16le.txt: Little-endian UTF-16 Unicode text, with CRLF line terminators想得到更利于脚本解析的 MIME 格式可以执行file -bi input_utf16le.txt输出可能是text/plain; charsetutf-16lefile命令适合作为第一步判断。它主要依赖文件头特征和内容采样对于不带 BOM 且内容较短的 UTF-16 LE 文件识别可能不够可靠所以仍需要配合十六进制查看。2.2 用 xxd 直接查看文件开头的十六进制只看文字工具的输出还不够。编码问题最终是字节问题所以需要直接看字节。用xxd查看文件前 32 字节xxd -l 32 input_utf16le.txt | head -n 4如果是带 BOM 的 UTF-16 LE 文件开头会先出现ff fe之后每个 ASCII 字符后面跟一个00、每个中文字符占两个可见字节。例如包含“编A”的文本大致如下00000000: fffe 167f 4100 ...A.如果文件不带 BOM则直接从正文的第一个 UTF-16 码元开始。Windows 上如果没有xxd可以使用其他十六进制查看器或者用 PowerShell 读取前几个字节。示例$bytes [System.IO.File]::ReadAllBytes(C:\temp\input.txt) | Select-Object -First 16 $bytes | ForEach-Object { $_.ToString(X2) } -Join 执行后看到FF FE就说明源文件很可能是 UTF-16 LE 带 BOM。2.3 生成一个可控的测试样例为了验证后续转换命令是否有效建议先创建一个内容已知、编码明确的小文件。用 Python 生成一个不带 BOM 和一个带 BOM 的 UTF-16 LE 文件python3 - PY from pathlib import Path text 编码转换测试\r\n Path(test_utf16le.txt).write_bytes(text.encode(utf-16-le)) Path(test_utf16le_bom.txt).write_bytes(b\xff\xfe text.encode(utf-16-le)) print(已生成) PY生成后分别执行file和xxd确认两个文件的差别。区别只在最前面的FF FE两个字节后面的正文内容完全一致。后面的转换命令会分别处理这两种情况。3. Linux/Unix 最快路线iconv3.1 无 BOM 文件的直接转换命令如果已经确认源文件是没有 BOM 的 UTF-16 LELinux/Unix 环境中最直接的转换方式是iconv。基本命令iconv -f UTF-16LE -t UTF-8 test_utf16le.txt -o output_utf8.txt参数含义-f UTF-16LE声明源编码是 UTF-16 小端。-t UTF-8目标编码是 UTF-8。-o output_utf8.txt把转换结果写入新文件。转换完成后用file检查新文件file output_utf8.txt如果源文件内容主要是中文和 ASCII正常输出会显示为 UTF-8 文本或类似Unicode text, UTF-8 text。再用xxd查看前几字节不应再看到连续的00补位字节。3.2 带 BOM 的源文件不能无脑用 UTF-16LE当源文件已经通过xxd确认开头是FF FE时有两种处理思路。第一种是保留 BOM让转换器按 BOM 自动识别字节序iconv -f UTF-16 -t UTF-8 test_utf16le_bom.txt -o output_auto_utf8.txt但-f UTF-16比较依赖 BOM 做自动识别。如果一个文件被标记为 UTF-16却没有 BOM很多实现会直接报错或者按默认字节序解析并产生错误文本。第二种是稳妥地先去掉 BOM再按 UTF-16 LE 转换。因为已知 BOM 占前两个字节可以用tail跳过tail -c 3 test_utf16le_bom.txt | iconv -f UTF-16LE -t UTF-8 output_no_bom.txt-c 3的含义是从第 3 个字节开始输出也就是跳过了FF FE。这样后续iconv看到的全部是 UTF-16 LE 正文。更建议的做法是在转换前先通过脚本读取 BOM如果发现FF FE就剥离 BOM 后再用UTF-16LE解码避免“源文件带 BOM”和“源编码声明”这两个信息互相冲突。3.3 输出端不要随意使用 UCS-2 别名iconv支持很多编码别名其中常见的是UCS-2LE。不要用UCS-2LE替换UTF-16LE。原因在于UCS-2 只支持 BMP 内的码点无法处理增补平面字符。如果源文本中包含位于增补平面字符例如生僻汉字或扩展符号其 UTF-16 表示是一个代理对。用 UCS-2 转换时会把这个代理对当成两个独立字符处理结果就是目标文件里出现乱码或错误映射。处理现代文本时源编码统一写UTF-16LE目标编码统一写UTF-8不要使用UCS-2LE这类旧别名。查看当前 iconv 支持的别名可以执行iconv -l | grep -i -E utf-16|ucs-2输出会列出 UTF-16 和 UCS-2 相关的多个名称但实际项目里坚持选显式、现代的UTF-16LE。4. Python适合单文件和批量转换的可靠方案4.1 判断 BOM 并选择正确的解码方式Python 内置支持 UTF-16LE但直接调用utf-16-le.decode()时需要自己处理 BOM。正确思路是先读取原始字节然后判断开头是否满足 BOM再选择解码规则。下面的函数可以读取 UTF-16 字节串import codecs from pathlib import Path def read_utf16(data: bytes, allow_le_guess: bool True) - str: if data.startswith(codecs.BOM_UTF16_LE): # 开头是 FF FE去掉 BOM 后按小端解码 return data[len(codecs.BOM_UTF16_LE):].decode(utf-16-le) if data.startswith(codecs.BOM_UTF16_BE): # 开头是 FE FF去掉 BOM 后按大端解码 return data[len(codecs.BOM_UTF16_BE):].decode(utf-16-be) if allow_le_guess: # 没有 BOM但外部已经确认源编码是 UTF-16LE return data.decode(utf-16-le) raise ValueError(未检测到 UTF-16 BOM且不允许猜测为 UTF-16LE)关键点是codecs.BOM_UTF16_LE的值是b\xff\xfe。codecs.BOM_UTF16_BE的值是b\xfe\xff。不要在没有 BOM、也没有外部编码信息的情况下仅凭前两个字节猜测大小端。ASCII 内容在小端文件里看起来是41 00在大端文件里是00 41如果猜反了解码出来的字符顺序会乱。这里使用“去掉 BOM 再按显式编码解码”的方式比直接依赖utf-16自动处理更可控也更容易在批量脚本中保持规则一致。4.2 单文件转换函数写好读取逻辑后封装一个转换函数import codecs from pathlib import Path def convert_utf16_to_utf8(src_path, dst_path, write_utf8_bomFalse): src Path(src_path) dst Path(dst_path) raw src.read_bytes() if raw[:2] codecs.BOM_UTF16_LE: text raw[2:].decode(utf-16-le) elif raw[:2] codecs.BOM_UTF16_BE: text raw[2:].decode(utf-16-be) else: # 明确接收的是 UTF-16LE不带 BOM text raw.decode(utf-16-le) content text.encode(utf-8) if write_utf8_bom: dst.write_bytes(codecs.BOM_UTF8 content) else: dst.write_bytes(content)使用方法convert_utf16_to_utf8( test_utf16le.txt, output_python.txt, write_utf8_bomFalse )默认输出为不带 BOM 的 UTF-8。如果目标是交给 Windows 记事本等程序使用且对方依赖 BOM 识别编码可以把write_utf8_bom修改为True。4.3 批量转换目录并记录失败文件实际项目中往往不只是转换单个文件而是转换整个日志目录。此时可以遍历目录import codecs from pathlib import Path def convert_file(src: Path, dst: Path): raw src.read_bytes() if raw[:2] codecs.BOM_UTF16_LE: text raw[2:].decode(utf-16-le) elif raw[:2] codecs.BOM_UTF16_BE: text raw[2:].decode(utf-16-be) else: text raw.decode(utf-16-le) dst.write_bytes(text.encode(utf-8)) failed [] for src_path in Path(logs).glob(*.txt): try: dst_path Path(converted) / src_path.name dst_path.parent.mkdir(parentsTrue, exist_okTrue) convert_file(src_path, dst_path) except UnicodeDecodeError as exc: failed.append((str(src_path), str(exc))) if failed: for path, err in failed: print(f[解码失败] {path}: {err}) else: print(全部转换完成)这里默认使用严格模式遇到无法解码的内容会抛出UnicodeDecodeError。刚开始批量转换时建议先输出失败文件清单而不是直接改用errorsignore吞掉错误。因为ignore会跳过无法映射的字节转换完成后文件能打开但可能已经丢失了无法恢复的内容。注意如果确实需要容忍部分坏字节建议使用errorsreplace让被替换的位置变成 UFFFD 替换字符至少能看出哪些位置有问题。不要在不做备份的情况下静默忽略异常。5. Windows 场景PowerShell 与系统编码切换的干扰5.1 Windows PowerShell 5.1 的 Unicode 参数代表 UTF-16 LEWindows PowerShell 5.1 中-Encoding Unicode表示 UTF-16 LE。很多旧版 PowerShell 脚本会这样写Get-Content -LiteralPath C:\temp\input.txt -Encoding Unicode | Set-Content -LiteralPath C:\temp\output.txt -Encoding UTF8这条命令读取 UTF-16 LE 文件再