Golang Unicode/Utf16与Utf8互转_处理Windows平台特定编码-Golang-PHP中文网

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

golang unicode/utf16与utf8互转_处理windows平台特定编码

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 是 \xff\xfe，但 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` 必须指向以 `\x00\x00` 结尾的 UTF-16LE 字节块

Windows 的宽字符 API（如 CreateFileW、SetWindowTextW）接收 LPCWSTR，即指向 uint16 的空终止指针。Go 中不能直接传 []uint16，必须用 C.CString 类思路手动构造，并确保末尾双字节为零。

windows-auto

Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。

下载

常见错误现象：C.GoBytes(unsafe.Pointer(&u16[0]), C.int(len(u16)*2)) → 缺少结尾 \x00\x00，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 字节。所以长度换算绝不能硬乘除。

典型坑：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))