Go 的 json.Decoder 本身完全支持 UTF-8，但若对字节切片误用 string(buf[:]) 导致截断空字节或包含未读取的垃圾数据，会破坏 UTF-8 编码完整性，造成多字节字符（如 á, ř）被错误解析为乱码。
go 的 `json.decoder` 本身完全支持 utf-8，但若对字节切片误用 `string(buf[:])` 导致截断空字节或包含未读取的垃圾数据，会破坏 utf-8 编码完整性，造成多字节字符（如 `á`, `ř`）被错误解析为乱码。
在 Go 中解析含非 ASCII 字符（如捷克语 zářit）的 JSON 数据时，看似正确的解码逻辑却输出乱码（如 záÅit），根本原因并非 encoding/json 不支持 UTF-8——它原生支持且要求输入必须是合法 UTF-8——而是字节流预处理阶段引入了编码污染。
你原始服务端代码的关键问题在于：
buf := make([]byte, bufferSize) _, err := conn.Read(buf) // ⚠️ Read 返回实际读取长度 n，但 buf[n:] 仍为零值字节！ s := string(buf[:]) // ❌ 错误：将整个底层数组转为字符串，包含大量 \x00 和可能的残留垃圾
conn.Read(buf) 仅写入前 n 个字节，而 buf[:] 强制取全部 bufferSize 字节。当 string(buf[:]) 被构造时，末尾的 \x00 或历史残留字节会被当作 UTF-8 序列的一部分解析，导致 json.Decoder 在解码 "zářit" 时实际面对的是类似 "zářit\x00\x00..." 的损坏输入。UTF-8 是变长编码（á = \xc3\xa1，ř = \xc5\x99），插入非法字节会令解码器错位，将 \xc3 单独解释为 Ã，\xa1 单独解释为 ¡，从而产生 záÅit 这类典型乱码。
此外，你示例中 for i := 0; i 的输出异常，正是因为 <code>len(s) 返回的是字节数（6），而非 Unicode 码点数（5）。request.Arg[0]='z'（1 字节），request.Arg[1]='\xc3'（UTF-8 第一字节，单独打印为 Ã），这进一步印证了底层字节被错误拆解。
✅ 正确做法：始终使用实际读取长度构造字符串，并确保 JSON 输入纯净。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
✅ 推荐解决方案
1. 修正 socket 读取逻辑（关键！）
buf := make([]byte, 4096) // 合理缓冲区大小
n, err := conn.Read(buf)
if err != nil {
log.Printf("Read error: %v", err)
return
}
// ✅ 仅使用实际读取的 n 字节
s := string(buf[:n])
r := strings.NewReader(s)
d := json.NewDecoder(r)
request := Request{}
if err := d.Decode(&request); err != nil {
log.Printf("JSON decode error: %v", err)
return
}2. 更健壮：直接从 io.Reader 解码（推荐用于网络）
避免中间字符串转换，减少出错环节：
// 直接将 conn 传给 Decoder（需确保 conn 发送的是完整、无粘包的 JSON） d := json.NewDecoder(conn) // 注意：需配合协议确保单次读取一个完整 JSON 对象 err := d.Decode(&request)
若存在粘包（多个 JSON 消息连发），应先按协议分帧（如换行分隔、长度前缀），再逐帧解码。
3. 调试 UTF-8 字符串的正确方式
不要用 len(s) 遍历字节，而应遍历 rune（Unicode 码点）：
// ✅ 正确遍历字符
for i, r := range request.Arg {
fmt.Printf("Position %d: U+%04X '%c'\n", i, r, r)
}
// 输出：Position 0: U+007A 'z', Position 1: U+00E1 'á', Position 2: U+0159 'ř', ...
// ✅ 验证 UTF-8 合法性（可选）
if !utf8.ValidString(request.Arg) {
log.Println("Invalid UTF-8 detected!")
}⚠️ 重要注意事项
-
Go 的
string类型天然存储 UTF-8 字节序列，只要来源合法（如json.Decoder输出），其内容必为有效 UTF-8。 -
...+2 more是调试器对长字符串的省略提示，与编码无关；真正问题是字节流污染。 - .NET Core 默认发送 UTF-8 JSON，无需额外设置，但需确保 Go 端不引入额外字节。
- 使用
json.RawMessage可延迟解析，便于检查原始字节是否符合预期。
总结：Go JSON 解码 UTF-8 的核心原则是——保证输入字节流纯净且完整。杜绝 string(buf[:]) 这类“全数组转换”，严格使用 buf[:n]；优先考虑 json.NewDecoder(io.Reader) 直接解码；调试时用 range string 替代 for i 。遵循这些实践，即可彻底避免 <code>zářit 变成 záÅit 的诡异问题。
