json乱码主因是webstorm未按utf-8读取，需同步设置global/project encoding为utf-8并重启；状态栏显示gbk或iso-8859-1说明fallback编码未统一；已乱码文件应先reload验证，确认utf-8再convert；终端乱码须同步配置注册表、vm参数及运行环境变量。
WebStorm 里 JSON 文件乱码，不是文件本身编码错了，而是 IDE 没按 UTF-8 读它——关键得让它“认出”这是 UTF-8，而不是自动 fallback 到 GBK 或 ISO-8859-1。
为什么 JSON 文件右下角显示 ISO-8859-1 或 GBK？
WebStorm 读 JSON 时，不看文件扩展名，而是优先检查：BOM（如有）、<meta charset>（HTML 里嵌的 JSON 不适用）、或文件内容是否含非 ASCII 字符但没声明编码。一旦没找到明确线索，它就按 Project Encoding fallback；如果项目也没设，就用 Global Encoding。所以显示 ISO-8859-1，基本等于这两层都还是默认值（Windows 下常为 GBK）。
- 别急着改单个文件，先去
Settings / Preferences → Editor → File Encodings - 确保
Global Encoding和Project Encoding都是UTF-8（不是Default (GBK)） -
Default encoding for properties files也设成UTF-8（虽不直接管 JSON，但漏了说明整体编码策略没对齐） - 点
OK后必须完全退出 WebStorm 再重启——热加载对编码设置不可靠
JSON 文件已乱码，状态栏点开后该选 Reload 还是 Convert？
打开一个中文键名/值显示为方块或问号的 JSON 文件，右下角状态栏会标出当前识别的编码（比如 GBK 带 ⚠️）。点击它，输入 utf 快速定位到 UTF-8：
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 如果不确定原始文件真实编码，先选
UTF-8→ 弹窗选Reload：只改编辑器显示，磁盘内容不动，可安全验证是否真能正确解码 - 如果确认文件本就是 UTF-8（比如从 GitHub 下载、团队约定统一 UTF-8），再选
UTF-8→Convert：重写磁盘内容，WebStorm 从此绑定该编码，下次打开不再猜 - 千万别对
.json文件乱选GBK → Convert：中文立刻变\u4f60\u597d或问号，且不可逆
格式化 JSON 后中文变成 \u4f60\u597d 怎么办？
这是 WebStorm 内置 JSON 格式化器的默认行为，和文件编码无关，而是输出策略问题：
- 进
Settings / Preferences → Editor → Code Style → JSON - 取消勾选
Escape non-ASCII characters - 再执行
Ctrl+Alt+L（Windows/Linux）或Cmd+Option+L（macOS） - 注意：这个设置只影响 IDE 里的格式化结果，不影响运行时
JSON.stringify()的输出
终端里 console.log({ msg: "你好" }) 还是乱码？
这和 JSON 文件编码设置完全无关，是 Node.js 进程或终端自身的编码逻辑在起作用：
- Windows：注册表
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor新增字符串值Autorun，值为chcp 65001 - 所有平台：编辑
webstorm64.vmoptions（macOS/Linux 是webstorm.vmoptions），追加一行：-Dfile.encoding=UTF-8 - Run Configuration → Environment Variables 里手动添加：
file.encoding=UTF-8 - 三者缺一不可；只调编辑器编码，Terminal 输出照样崩
最容易被忽略的是：Convert 操作前没确认原始编码，以及 Terminal 的 chcp 65001 和 VM 参数漏掉任意一个——文件看着正常了，一跑起来还是满屏问号。
