go无内置utf-16编解码支持,unicode/utf16仅转换rune与uint16切片,不处理字节序、bom或空终止;应使用golang.org/x/text/encoding/unicode包,并注意windows api调用时手动补零及正确预估长度。

Go 里没有内置 UTF-16 编码支持,unicode/utf16 只处理编码转换逻辑,不负责字节序或 BOM
Go 标准库的 unicode/utf16 包不是编解码器,它只提供 Encode 和 Decode 函数,把 []rune 和 []uint16 互相转换。它不碰字节([]byte),也不管你是 Little-Endian 还是 Big-Endian,更不会自动识别或写入 BOM。
windows API(如 WideCharToMultiByte)默认用 UTF-16LE,而 Go 的 encoding/binary 需你显式指定 binary.LittleEndian 才能正确序列化 []uint16 成字节流。
- 常见错误现象:
String(unsafe.Slice(&u16[0], len(u16)*2))直接转字符串 → 字节序错乱,Windows 上读出来是乱码 - 正确做法:先
utf16.Decode得到[]rune,再用[]byte(string(runes))转 UTF-8;反向则先 UTF-8 解码为[]rune,再utf16.Encode+binary.Write(指定 LE) - Windows 场景下必须手动处理 BOM:UTF-16LE 的 BOM 是
xffxfe,但 Go 程序读文件时若带 BOM,os.ReadFile会原样返回,需自己跳过前 2 字节再解码
golang.org/x/text/encoding/unicode 是唯一靠谱的 UTF-16 编解码器
如果你要读写磁盘上真实的 UTF-16 文件(比如 Windows 记事本保存的 .txt),别手写转换逻辑——直接用 x/text/encoding/unicode。它封装了 BOM 检测、字节序自动识别、以及与 io.Reader/Writer 的无缝对接。
- 使用场景:读取 Windows 生成的 UTF-16LE 文件、向 COM 接口传 UTF-16 字节、与 Cgo 调用 Windows API 交互
- 关键参数:
unicode.UTF16(unicode.LittleEndian, unicode.UseBOM)——UseBOM表示写入时加 BOM,读取时自动跳过;若设为unicode.ExpectBOM,则读取时强制要求 BOM,缺则报encoding.ErrInvalidUTF16 - 性能影响:比纯
utf16.Decode多一次内存拷贝,但对大多数 I/O 场景可忽略;兼容性远高于手撸逻辑,尤其在跨平台混合 BOM 存在时
Cgo 调用 Windows API 时,*uint16 必须指向以 x00x00 结尾的 UTF-16LE 字节块
Windows 的宽字符 API(如 CreateFileW、SetWindowTextW)接收 LPCWSTR,即指向 uint16 的空终止指针。Go 中不能直接传 []uint16,必须用 C.CString 类思路手动构造,并确保末尾双字节为零。
- 常见错误现象:
C.GoBytes(unsafe.pointer(&u16[0]), C.int(len(u16)*2))→ 缺少结尾x00x00,API 调用崩溃或截断字符串 - 正确做法:分配
len(runes) + 1个uint16,最后一位清零;用C.CString不行(它按字节处理),得用C.malloc+unsafe.Slice+copy - 注意:
utf16.Encode输出不含结尾零,必须手动补;且整个切片需保持有效生命周期,不能是局部[]uint16的底层数组
UTF-8 和 UTF-16 长度不等价,len([]byte(s)) != len(utf16.Encode([]rune(s))) * 2
一个中文字符在 UTF-8 占 3 字节,在 UTF-16 占 2 字节;但遇到 Unicode 辅助平面字符(如 emoji ?、古汉字),UTF-16 需要两个 uint16(代理对),而 UTF-8 仍只需 4 字节。所以长度换算绝不能硬乘除。
立即学习“go语言免费学习笔记(深入)”;
- 典型坑:
buf := make([]byte, len(src)*2)预估 UTF-16 字节长度 → 对含 emoji 的字符串严重溢出 - 安全做法:先
utf16.Encode([]rune(s))得到[]uint16,再用len(u16) * 2;或直接用x/text/encoding的Encoder.Size方法预估 - Windows 路径限制:MAX_PATH 是字符数(
wchar_t个数),不是字节数。所以判断路径是否超长,该用len(utf16.Encode([]rune(path))),而非len([]byte(path))
事情说清了就结束。最常被绕开的是 BOM 处理和空终止——这两点在 Windows 平台几乎必踩,而且错误表现往往延迟到运行时才暴露。