大家好我是 SiKi老师。把关卡名“森林”输出成 JSON 后文本里出现了\u68ee\u6797。这不一定是中文丢了。先区分 JSON 的字符表示和文件的字节编码再决定怎样让协作者直接读到中文。本文在 Windows、Python 3.12.14 中测试自拟字典并在独立临时目录写入、回读一份自有文件。不覆盖真实游戏配置没有引擎导入、终端字体或跨电脑显示的实测结论。一 先看默认输出究竟是什么下面只生成文本不写文件importjson data{level:森林,hint:按空格开始}escapedjson.dumps(data)print(escaped)本机实际输出{level: \u68ee\u6797, hint: \u6309\u7a7a\u683c\u5f00\u59cb}Python 3.12 JSON 文档 说明ensure_ascii默认是True将非 ASCII 字符转义。文本里的这些转义是中文字符的一种 JSON 表示不应直接当作读取错误。如果编辑器显示的是乱码字符或问号则需要保留原字节并调查编码或显示过程。本文的开关针对转义表示不会修复已经丢失的字符更不该用搜索替换把所有反斜杠删掉。二 需要直接阅读中文时关闭转义对同一个字典再次生成文本readablejson.dumps(data,ensure_asciiFalse)print(readable)实际得到{level: 森林, hint: 按空格开始}这个参数改变非 ASCII 字符的输出表示不是指定 UTF-8 文件编码。json.dumps返回 Python 的str此时还没有决定文件里的字节怎样写。即使关闭这个参数JSON 仍要对必要字符作转义。不要将它解释为“输出中再也没有反斜杠”。也不要把文本更易读当成字段类型、范围或来源已经校验通过。三 解析回去核对数据而不只看外观可以在前面代码后面加上assertjson.loads(escaped)dataassertjson.loads(readable)data这两条断言在本机都通过说明两种文本在本例中解析回同一个字典。判断有没有丢失中文时这比比较打印出来的字符长度更有用。文本不一样解析后的数据仍可能相同反过来屏幕上看起来一样的字形也不证明字符串或文件字节完全相同。本文没有测试 Unicode 规范化、不可见字符或孤立代理项不作这些结论。这里的断言只是两份自拟字段的回读验证。真实配置还需要检查必填字段、数据类型和允许值可解析 JSON 不能替代业务校验。四 写文件时另行约定 UTF-8实际写入测试用了自己的临时目录。需要复现时也只在新建练习目录操作别把输出路径换成现有项目配置frompathlibimportPathfromtempfileimportTemporaryDirectorywithTemporaryDirectory(prefixjson-readable-)asfolder:targetPath(folder)/level.jsontarget.write_text(readable,encodingutf-8)restoredjson.loads(target.read_text(encodingutf-8))assertrestoreddata本机测试通过。我还读取这份临时文件的字节用 UTF-8 解码后与readable比较结果相同。测试结束只清理脚本自己创建的临时目录不接触用户工程。这明确了写入和读取的共同编码不代表接收方所有编辑器都会正确显示。交付说明应写清 UTF-8并保留可回读的样例。本文没有使用系统默认编码来碰运气。五 出错时分清是哪一层失败我另外运行readable.encode(ascii)实际得到UnicodeEncodeError。虽然ensure_asciiFalse保留了中文但 ASCII 编码仍不能表示本文这些汉字。这是编码阶段失败不是json.dumps没有生效。对于“终端报错”“编辑器看不到中文”“解析后字段不对”这几种现象分别保存错误信息、文件编码约定和解析结果避免同时修改几个环节。不要为了让输出成功就忽略编码错误并丢掉字符。本文没有测网络传输、压缩、字体、BOM 处理或游戏加载器兼容性也不提供原配置的覆盖方案。当前结论是关闭非 ASCII 转义便于直接读中文字节编码仍要单独约定。你遇到的是合法的\u转义还是回读之后中文值确实变了先完成这一步比较再决定改哪段代码。