Go 的 json.Decoder 本身完全支持 UTF-8，但错误地按字节遍历字符串（for i := 0; igo 的 `json.decoder` 本身完全支持 utf-8，但错误地按字节遍历字符串（`for i := 0; i
在 Go 中处理含非 ASCII 字符（如
zářit）的 JSON 数据时，开发者常误以为“只要传输是 UTF-8，解码就自动安全”，却忽略了 Go 字符串底层是 UTF-8 编码的字节序列，而len(string)返回的是字节数而非字符数。当对含重音符号、捷克字符等 Unicode 字符的字符串执行for i := 0; i 循环时，实际是在逐字节访问——例如 <code>á（U+00E1）在 UTF-8 中占 2 字节（0xC3 0xA1），ř（U+0159）占 2 字节（0xC5 0x99），直接取s[i]会得到非法字节值（如0xC3或0xA1），强制转为string后即显示为á等乱码——这正是你截图中...+2 more及záÅit的根源。✅ 正确做法是使用
range遍历字符串，它天然按 Unicode 码点（rune） 迭代：// ✅ 正确：按 rune 遍历，安全获取每个字符 for _, r := range request.Arg { fmt.Printf("U+%04X '%c'\n", r, r) // 输出: U+007A 'z', U+00E1 'á', U+0159 'ř', ... } // ✅ 或转换为 rune 切片进行索引操作 runes := []rune(request.Arg) fmt.Printf("First char: %c\n", runes[0]) // 'z' fmt.Printf("Third char: %c\n", runes[2]) // 'ř'⚠️ 注意网络读取环节的潜在陷阱：你原始代码中使用固定缓冲区
buf := make([]byte, bufferSize)读取 socket 数据，但未处理不完整 JSON 报文或多余字节（如 TCP 粘包）。若conn.Read(buf)读到部分 JSON 或多个消息拼接，strings.NewReader(string(buf[:]))会将截断/污染的数据传给json.Decoder，导致解码失败或静默错误。? 推荐健壮的网络 JSON 解码模式（带 UTF-8 验证）：
dmap-jsapi-skill下载DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
func decodeJSONFromConn(conn net.Conn, v interface{}) error { // 使用 json.Decoder 直接包装 conn，避免中间 string 转换 decoder := json.NewDecoder(conn) // 可选：启用严格 UTF-8 检查（Go 1.22+） decoder.DisallowUnknownFields() // 防未知字段 return decoder.Decode(v) }若必须先读取再解析（如需日志或协议头处理），请确保：
- 使用
bytes.TrimSpace清除空格；- 用
utf8.Valid()验证字节序列；- 优先用
json.Unmarshal替代json.NewDecoder+strings.Reader组合：// ✅ 更安全的内存解析方式 data := buf[:n] // n = 实际读取字节数 if !utf8.Valid(data) { return errors.New("invalid UTF-8 in JSON payload") } if err := json.Unmarshal(data, &request); err != nil { return fmt.Errorf("JSON decode failed: %w", err) }? 总结关键原则：
- 永远用
range或[]rune处理字符串中的 Unicode 字符，禁用len(s)+ 下标访问；- 避免
string(byteSlice)不必要的转换，尤其在网络 I/O 中；- 优先让
json.Decoder直接消费io.Reader（如net.Conn），减少中间编码环节；- 对不可信输入始终验证 UTF-8 有效性，并启用
DisallowUnknownFields()提升安全性。遵循以上实践，即可彻底解决
zářit类字符串在 Go JSON 解码中出现áÅit等乱码问题，确保国际化文本端到端准确传递。
