做后端接口联调那几年我浏览器书签栏里常年躺着三五个“免费JSON在线解析工具”的网址。原因很朴素日志是压缩成一行的、接口返回是几千层嵌套的、同事微信发来的是一段带中文全角引号的脏数据而我当时手里可能只有一台刚装好系统的机器连编辑器都没配。这类工具解决的就是这种“立刻要看清楚这段数据长什么样”的即时需求——把一坨没法阅读的字符串变成有缩进、有颜色、可折叠的结构顺便告诉你哪里少了个逗号、哪里多了个引号。它适合所有人写前端的要核对接口字段做数据清洗的要确认结构测试要构造用例产品经理偶尔也要从一堆返回值里捞出某个字段。下面我按自己这些年的实际使用路径把这类工具从“为什么用”到“怎么挑”再到“怎么排错”完整拆一遍中间夹着大量踩坑记录能直接抄。1. 先搞清楚在线JSON解析工具到底在解决什么问题1.1 三类最高频的真实使用现场第一类是接口调试现场。浏览器开发者工具的 Network 面板里响应体默认可能是压缩过的你点一下格式化能看到层级但一旦字段名特别长、数组特别深横向滚动会让人崩溃而且很多移动端调试场景拿不到完整开发者工具只能把响应复制出来。这时候把文本粘进在线工具左侧原始内容、右侧树形结构一眼就能定位到data.list[3].status这种位置。第二类是日志排查现场。线上服务打出来的结构化日志为了省空间往往是一行一个 JSON几十条粘在一起。人眼读就是一堵墙。在线工具做“格式化”之后每条记录展开你能迅速看出哪条缺字段、哪条字段类型变了——比如平时orderId是字符串某条突然变成了数字这类问题在压缩文本里几乎发现不了。第三类是脏数据修复现场。这种情况最消耗时间从聊天工具、文档、邮件里复制出来的 JSON经常带着不可见的零宽字符、中文引号、尾逗号、单引号、注释。它不是“格式不好看”它是根本不合法的 JSON任何语言的解析器都会直接抛异常。在线工具的价值在于它会明确告诉你“第 37 个字符附近出错”让你知道从哪儿开始改而不是让你用肉眼在一万字符里找那一颗沙子。1.2 在线工具、编辑器插件、本地脚本三者的边界很多人会问既然 VS Code 有格式化快捷键Python 一行python -m json.tool也能干这事为什么还用网页我的判断标准是**“启动成本”和“分享成本”**。启动成本上在线工具打开即用不需要装环境、不需要开项目、不需要记命令尤其适合临时借用别人的电脑、在会议中快速确认一个字段这类场景。分享成本上你把一段格式化好的结构发给同事对方不需要你的编辑器配置就能看懂反过来你把一段原始 JSON 发过去对方可能还要再格式化一遍。但边界也很清楚数据敏感、体积巨大、需要批量处理这三件事在线工具都不合适。敏感数据贴上去等于把内部字段结构交给了不认识的服务器几十兆的文件浏览器标签页会直接卡死需要把一百个文件统一格式化那是脚本的活。我自己的习惯是先用在线工具看清楚结构、定位问题确认没问题之后再回到本地用脚本批量处理。这个分工用了很多年效率最高。1.3 一个容易被忽略的前提不是所有“在线”都在你这边算判断一个在线 JSON 工具能不能用来处理稍敏感的数据有一个非常土但极其有效的办法把网页打开然后断网再粘一段 JSON 进去。如果格式化、折叠、校验全都正常说明解析逻辑跑在浏览器本地数据没有离开你的机器如果页面直接报错或者转圈说明它把内容发到了服务端。这个测试我做过很多次结果差异很大。纯前端实现的工具本质就是把 JavaScript 的JSON.parse包了一层界面性能取决于你的电脑带服务端处理的工具可能提供更复杂的能力比如超大文件流式解析、格式互转但数据要出网。知道这个区别之后你就能按数据等级分配工具公开的示例数据随便用内部接口返回的字段名和枚举值我一般只用本地解析。2. 拆开看一次“粘贴—格式化”背后发生了什么2.1 解析器干的三件事词法、语法、建树你在输入框里粘一段文本点“格式化”中间其实走了三步。第一步是词法分析把字符流切成一个个有意义的记号左花括号、字符串、冒号、数字、逗号。这一步最容易被奇怪字符绊倒——中文全角引号“”、弯引号’、零宽空格、从 Word 里带出来的不换行空格全都会被识别成“非法记号”于是报错位置往往就在这些看不见的地方。第二步是语法分析按 JSON 的语法规则把记号拼成结构。JSON 的规则其实非常少对象必须是“字符串键 冒号 值”多个成员之间用逗号分隔且最后一项后面不能有逗号数组同理值只能是字符串、数字、对象、数组、true、false、null六种。只要违反其中一条就整体失败没有“部分容忍”这一说。第三步是建树把解析结果变成内存里的对象再根据缩进参数重新序列化输出。很多人以为格式化是“在原文里加空格”其实不是它是解析后重新生成。这解释了一个常见现象你粘贴的原始文本里键的顺序格式化后可能变了——因为部分语言的实现里纯数字键会被提前排序数字1.00会被输出成1转义过的字符会被还原成真实字符。这些都不是工具的错是“解析再生成”这个机制决定的。2.2 格式化、校验、转换是三种不同的能力很多新手把这三件事混为一谈实际差别很大。格式化只关心可读性加缩进、加换行、加语法高亮。它默认你的内容是合法的遇到不合法就中断。校验关心的是合规性是否符合 JSON 语法是否符合某份 Schema 约定比如某个字段必填、某个字段必须是整数。转换关心的是形态迁移JSON 转 YAML、转 CSV、转查询参数字符串、转 TypeScript 接口定义。我见过太多人拿“格式化工具”当“校验工具”用看到能正常展开就以为数据没问题。实际上语法合法和数据正确是两码事一个字段本该是数组返回了对象JSON 语法完全合法格式化工具不会给你任何提示。真正要卡住这类问题得靠 Schema 校验或者自己写断言。能力关注点典型失败表现适用时机格式化缩进、换行、高亮内容不合法直接报错阅读、定位字段语法校验是否符合 JSON 规范指出出错字符位置修复脏数据Schema 校验字段类型、必填、范围列出不符合约定的路径接口契约验证格式转换JSON 与其它格式互转嵌套结构被拍平或丢失数据导入导出2.3 为什么有些工具能“自动修复”有些不能带“修复”按钮的工具做的事通常是容错解析先尝试标准解析失败后按一组预设规则逐条试探——去掉尾逗号、把单引号换成双引号、给没引号的键补上引号、删掉注释、把undefined换成null。这套逻辑在多数场景下很好用但它有明确的风险修复是猜测不是还原。举个真实例子某次同事发来一段数据里面有个值写的是2024-01-01单引号被自动替换成双引号后语法通过了但这个字段本应是日期对象还是字符串工具不知道还有一次一段文本里有注释掉的字段// amount: 100自动清理注释时把它删了结果看起来“修复成功”实际上丢了一条业务数据。我的做法是修复功能只用来看“大概哪里坏了”修完必须肉眼过一遍被改动的位置。尤其涉及金额、ID、时间这三类字段任何自动改动都要人工确认。3. 挑工具别只看界面六个硬指标3.1 指标一解析是本地还是服务端前面说过断网测试法这里补一个细节有些工具是混合模式小内容本地解析超过一定体积才上传服务端。判断方法是打开浏览器开发者工具的网络面板粘一段内容点格式化看有没有新的请求发出去。这个方法笨但比看隐私政策快得多。另外要注意“分享链接”功能。很多工具支持把当前内容生成一个短链接发给别人这个功能默认意味着内容已经存到了对方服务器。如果只是自己看绝对不要点分享如果确实要发给同事先把字段名和值全部替换成占位符再生成。3.2 指标二大内容下的响应速度浏览器里跑解析瓶颈通常在两个地方字符串拼接和 DOM 渲染。十万字符级别的 JSON做得好的工具是秒开做得差的会卡三到五秒甚至标签页无响应。测试方法很简单找一段两万行左右的数组数据粘进去观察从点击到出现结构的时间以及滚动是否流畅。一个经验值纯前端工具在 1MB 以内基本都能用5MB 以上开始明显吃力20MB 以上大概率崩溃。超过这个量级别硬扛转成本地脚本处理。我试过用在线工具打开一份三十多兆的日志导出浏览器直接提示页面无响应等了半分钟只能强关。3.3 指标三错误提示的精度这是区分工具好坏最核心的一条。差的工具只告诉你“格式错误”好一点的说“第 128 个字符附近”最好的会高亮出错位置、给出上下文、并用一句人话解释原因比如“这里期望一个逗号或右花括号却遇到了字符串”。精度为什么重要因为真实世界的脏数据出错点往往在几千字符之后。你没有一个准确位置就只能二分法一段段删着试非常低效。我在排查一条两万字符的配置时靠的就是错误位置直接定位到一处多余逗号前后不到十秒。3.4 指标四树形视图的交互质量格式化文本谁都能做树形视图才是拉开差距的地方。我关注几个点节点能否一键折叠到指定层级长数组是否分页或懒加载点击节点能否直接复制该节点的路径比如$.data.items[2].id搜索能否只搜键名、只搜值、或两者都搜。路径复制这个功能看着小实际极其省事。你要在代码里取某个深层字段手写路径容易错点一下复制出来直接贴上省掉反复数括号的功夫。3.5 指标五附加能力是否真的用得上常见的附加能力有JSON 转 YAML、转 CSV、转 TypeScript 接口、生成 JSON Schema、JSONPath 查询、对比两段 JSON 的差异、生成转义后的字符串。这些不是越多越好关键看是否准确。以“转 TypeScript 接口”为例好的实现会把同名字段的不同类型合并成联合类型把数组元素类型推断出来差的实现遇到null就报错遇到嵌套数组就拍平。再比如“两段 JSON 对比”好的实现能精确到数组元素的增删改差的实现只能做文本行对比一格式化就全是差异。我的建议是主力用格式化 校验 路径复制这三样其余能力按需临时找专门工具。功能堆得越多的页面往往每一块都做得不够深。3.6 指标六界面的“不打扰”程度这条听起来虚实际影响很大。有些页面打开就是三层弹窗、悬浮广告、自动播放的视频你粘完数据还得先找关闭按钮。有些页面把输入区做得极窄长行必须横向滚动。有些页面深色模式刺眼长时间看很累。我最后长期留下的那两三个共同点是首屏就是输入框和结果区没有遮挡快捷键清晰常见是 CtrlEnter 格式化、CtrlShiftF 压缩字号可调。工具是拿来干活的不是拿来看广告的。4. 实操把一段脏 JSON 修到能跑4.1 第一步永远是“定位”不是“动手改”拿到一段报错的内容先别急着删字符。正确的顺序是粘贴 → 触发校验 → 读错误信息 → 找到报错位置的前后二十个字符 → 判断属于哪类问题。这里有个细节不同实现报的“位置”口径不一样有的是字符下标从 0 开始有的是“第 N 个字符”从 1 开始有的是行列号。对着差一位会让人抓狂。我的做法是不看具体数字直接看工具高亮的那个位置如果没有高亮就把报错数字前后各取三十个字符复制到一个小文本里单独看通常一眼就能看出问题。还有一个高频陷阱报错位置指向的字符本身可能是无辜的。比如 JSON 里少了一个右花括号解析器可能一路读到文件末尾才报错位置指向最后一行但真正的问题在第一行。这种情况的规律是报错位置在结尾附近通常意味着前面某处括号或引号没闭合。反过来报错位置在开头附近通常是第一个字符就有问题比如文件带了 BOM。4.2 常见非法写法与对应修法下面这张表是我这些年整理出来的基本覆盖了九成以上的“看起来像 JSON 但解析不了”的情况。现象典型写法为什么错怎么改尾逗号{a:1,}JSON 不允许最后一个成员后带逗号删掉逗号单引号{a:1}JSON 字符串必须双引号全部换成双引号无引号键{a:1}键必须是字符串给键补双引号注释{a:1 // 备注}JSON 规范不支持注释删除或移到外部文档中文引号{“a”:1}全角符号不是合法记号替换为半角双引号undefined{a:undefined}不是 JSON 值改为null或删除该键NaN / Infinity{a:NaN}不是合法数字改为null或字符串缺逗号{a:1 b:2}成员之间必须有逗号补逗号括号不配对{a:[1,2}数组未闭合补齐]BOM 头文件开头有不可见字符首字符不是合法记号另存为无 BOM 的 UTF-8这张表里我最想强调的是中文引号和BOM这两项因为它们完全不可见肉眼排查几乎无解。中文引号通常来自在聊天工具或文档里编辑过BOM 通常来自某些编辑器默认保存格式。遇到“明明看起来完全正确却报错”的情况优先怀疑这两个。4.3 大整数精度一个不报错但会出错的地方这一类问题比语法错误更危险因为工具不会给你任何提示。JavaScript 的数字是双精度浮点能精确表示的整数上限是 2 的 53 次方减一也就是 9007199254740991。超过这个范围解析时就会丢精度。典型受害者是订单号、雪花算法生成的 ID、某些平台的用户标识——这些值经常是 18 位、19 位数字。你在一段 JSON 里写{id: 1234567890123456789}粘进在线工具它可能显示成1234567890123456800末尾几位变了。如果你从这个界面复制出去用数据就已经毁了。更麻烦的是某些工具在格式化时不做提示你根本不知道它变过。我的处理原则很简单所有可能超过 15 位的数字标识在 JSON 里一律用字符串承载。如果拿到的数据已经是数字形态先别在在线工具里复制结果而是回到源头用能保留大整数的解析方式处理很多语言的 JSON 库支持把数字解析成高精度类型或原始字符串。这条规则救过我很多次。4.4 转义字符与代理对看着一样其实不一样字符串里的转义是另一个高发区。\n是真换行\\n是反斜杠加 n两者在界面上可能显示得很接近。JSON 里还允许\uXXXX形式的 Unicode 转义四个十六进制数字表示一个码元。问题出在超出基本平面的字符上比如很多表情符号它们在 UTF-16 里占两个码元写成\uD83D\uDE00这种“代理对”。单独一个\uD83D是不完整的某些宽松的解析器会容忍严格的不行。如果你在工具里看到一堆\u开头的片段先确认它们是否成对出现。实操建议需要人眼确认内容时用工具的“反转义”或“显示原始字符”功能需要把内容嵌进代码字符串时再用“转义”功能生成。这两步别搞反否则会出现“我明明写的是中文代码里变成一串 u”的困惑。5. 进阶用法路径提取、结构转换与契约校验5.1 用路径表达式精准捞出你要的那一块面对一个几百 KB 的响应你真正需要的往往只是其中一小块。手点折叠也能找到但如果有路径查询效率是数量级的差别。路径表达式的写法各家略有差异但基本形态一致$表示根.key取对象成员[0]取数组下标[*]取全部元素。比如$.data.list[*].orderId就能把列表里所有订单号一次性提取出来变成一个新数组。这个能力在几个场景下特别值钱一是要从几百条记录里核对某一列值是否符合预期二是要把嵌套结构里的某个字段单独拎出来做统计三是要确认某个深层字段是否存在直接查路径比一层层点开快得多。需要注意的是过滤条件的兼容性。带条件筛选的写法比如按某字段值过滤数组在不同工具里支持程度差别很大遇到不生效的情况别怀疑自己的写法直接换成“先提取全部再用本地脚本过滤”更稳。5.2 JSON 转表格什么时候能做什么时候做不了把 JSON 转成 CSV 或表格是数据同学的高频需求。这里有个前提必须说清楚表格是二维的JSON 是树形的转换一定会损失信息。能做的情况数组里每一项都是扁平的键值对且键基本一致。这种“记录数组”转表格非常顺一行一条记录一列一个字段。做不了或会丢信息的情况字段里嵌套了对象或数组。转换工具的处理方式通常是三种——把嵌套对象序列化成一段字符串塞进单元格、把数组用分号拼接、或者直接丢弃。三种都不理想你得先想清楚下游要什么。我的做法是先在在线工具里看一下结构确认字段是否扁平再决定要不要转。如果必须转嵌套结构先在工具里把它拍平比如把user.name提升成独立列再导出拍平这个动作在很多工具里没有现成按钮得自己写一小段脚本用在线工具确认结果对不对。5.3 Schema 校验把“语法没错但语义错了”挡住前面提过语法合法不等于数据正确。真正能挡住字段类型错误的是 Schema 校验。基本思路是先写一份“期望结构”的描述哪些字段必填、每个字段是什么类型、数组元素是什么类型、有没有枚举范围、字符串有没有长度限制。然后把实际数据丢进去比对不符合的会按路径列出来比如$.data.items[2].amount期望是数字实际是字符串。这件事的价值在联调阶段特别明显后端改了一个字段类型没通知前端拿到的数据语法完全合法格式化工具一路绿灯跑到业务逻辑才炸。有了 Schema 校验在数据入口处就能拦住。不过要提醒一句Schema 是契约不是文档。它应该跟着接口一起维护写完就丢在一边的 Schema 很快就会和实际数据对不上反而制造噪音。如果团队没有维护契约的习惯那不如退一步用几条简单的断言脚本代替。6. 常见问题与排查技巧实录6.1 大文件一粘就卡死怎么办先说结论别跟浏览器硬碰硬。纯前端解析要一次性把整个字符串读进内存、建树、再渲染成 DOM 节点这三步在几十兆的量级上必然崩。就算侥幸没崩滚动也会卡成幻灯片。我的处置顺序是这样的第一步先确认是不是真的需要看全文。多数时候你要找的只是一条记录或一个字段用本地命令先过滤一遍把范围缩小到几 KB再粘进在线工具看结构。第二步如果只是想验证整体是否合法用命令行工具跑一遍校验它只输出“通过”或“第几行第几列出错”不占内存。第三步如果确实要做结构分析把文件按行拆开或者按顶层数组元素切片分批处理。这里分享一个实用的命令很多机器自带 Python验证一个文件是否合法只要一行python -m json.tool big.json /dev/null echo OK || echo FAIL它会把错误位置打到标准错误输出里比在浏览器里等半分钟强得多。如果只想压缩不想格式化很多工具链也支持流式处理内存占用低得多。6.2 中文变成乱码或问号乱码的根因几乎总是编码不一致文件实际是 GBK 存的工具按 UTF-8 读中文就变成问号或方块反过来文件是 UTF-8某个本地编辑器按 GBK 打开也会乱。排查方法先看乱码的形态。如果是一串问号通常是解码失败后的替换字符如果是看起来像“锟斤拷”这种固定组合是典型的双重编码错误如果中文完全消失可能是工具在解析时把非 ASCII 字符过滤掉了。解决路径确认源文件的真实编码多数编辑器状态栏会显示把它转成 UTF-8 再粘如果是从数据库或接口直接复制的先确认传输过程没有做二次编码。我在线上排查过一例接口返回的 JSON 里中文字段显示正常但复制到剪贴板再粘贴就乱了最后发现是终端编码设置的问题跟 JSON 本身无关。6.3 明明一模一样就是报“非法字符”这是最让人上火的一类。文本看起来完全正确每个字符都对但就是过不了。真相通常是存在不可见字符。最常见的有三种从网页或文档复制时带进来的零宽空格U200B、不换行空格U00A0、以及某些系统带的 BOMUFEFF。这些字符在编辑器里不显示在大部分字体下宽度为零肉眼绝对看不出来。处理办法把内容粘进一个能显示不可见字符的编辑器打开“显示空白字符”之类的选项或者干脆用一条命令把非 ASCII 的可疑字符替换掉。更省事的办法是重新手打一遍出错位置附近的引号和逗号因为问题往往就集中在标点符号上——从聊天工具复制时引号很容易被替换成弯引号。6.4 键的顺序变了是不是工具出问题了不是。这是“解析后重新生成”的正常表现。需要知道两条规则第一JSON 规范里对象的成员是无序的任何依赖顺序的逻辑本身就不严谨第二很多语言的实现在序列化时会对整数形态的键做特殊排序或者按内部哈希顺序输出。所以你看到的顺序变化不代表数据错了。如果你确实需要保留顺序比如生成给人看的配置、或者做文本 diff那就不该走“解析再生成”这条路而应该用只做缩进、不改动内容的格式化方式或者干脆保留原始文本。这一点在做配置文件的版本对比时特别重要我吃过亏格式化工具把键重排了diff 出来一大片红色实际业务上什么都没改。6.5 复制出去的内容带了一堆转义反斜杠在树形视图里点“复制值”有时拿到的是{\a\:1}这种被包了一层的字符串。原因是这个值本身在 JSON 里就是字符串类型里面装的是一段序列化后的 JSON 文本。判断方法很简单看这个节点在树里是不是字符串类型通常有引号标记或不同颜色。如果是那你复制的就是字符串的字面内容反斜杠是它的一部分。要拿到里面的结构得先把它“解一层”用工具的反序列化功能或者把这段字符串单独粘进输入框再解析一次。这个坑在对接那些“把 JSON 当字符串塞进字段”的接口时天天遇到比如某些消息队列的载荷、某些日志的 message 字段。7. 几条我用了很多年的硬规矩7.1 敏感数据的三步脱敏法只要数据要贴到浏览器里的第三方页面就先脱敏。我的流程固定三步。第一步替换标识类字段。所有 ID、手机号、邮箱、地址、姓名统一换成占位符保持类型不变——字符串还是字符串数字还是数字长度尽量接近这样不会掩盖类型问题。第二步保留结构删掉内容。数组至少留两条元素对象至少留一层嵌套因为很多问题恰恰出在“数组只有一条所以没暴露”“嵌套太深导致某层字段缺失”上。全删光就看不出结构了。第三步检查有没有藏在字符串里的信息。最容易被忽略的是错误信息、日志 message、URL 查询参数——这些字段里经常夹着内部标识、路径、参数值看起来是普通文本实际包含大量信息。脱敏之后再看结构绝大多数问题照样能定位因为你排查的是“字段在哪、类型对不对、有没有缺”这些跟具体值关系不大。7.2 本地兜底方案一定要有一个在线工具再方便也有三个时刻指望不上没网、数据不能出本机、文件太大。所以必须准备一套本地方案。最轻量的方案是编辑器自带能力主流编辑器都有“格式化文档”命令选中一段 JSON 按快捷键就排好版还能折叠、搜索、跳转。这个方案几乎零成本缺点是校验能力弱报错信息不够细。稍强一点的是命令行工具。除了前面提到的 Python 自带模块很多语言都有一行式的格式化命令配合管道可以把输出直接写到文件里。适合批量处理。再强一点的是自己写十几行脚本把“读取、解析、报错定位、输出”串起来还能顺手做字段检查。这个方案我在做数据导入时反复用因为导入前的校验规则是业务特定的通用工具满足不了。我的实际组合是临时看一眼用在线工具日常用编辑器快捷键批量处理用脚本。三者分工明确谁也不替代谁。7.3 一个提高效率的小习惯先压缩再对比处理配置或接口响应时经常要判断“两次返回有没有变化”。直接对比格式化后的文本缩进差异会制造大量噪音。我的做法是先各自压缩成一行再对比。压缩之后没有空格和换行干扰差异只可能来自内容本身。如果对比出来还是有一大片不同那说明结构真的变了这时候再分别格式化逐层找差异点。这个顺序很重要先压缩对比定位到具体字段再格式化看上下文。反过来做你会在一堆缩进差异里迷失。7.4 关于“免费”这件事的判断免费工具的可持续性是个现实问题。我的观察是纯前端实现的工具服务端成本几乎为零长期免费的概率高提供分享链接、云端保存、大文件处理这类功能的服务器成本实打实要么靠广告要么靠增值服务要么某天悄悄关停。所以我的策略是不依赖单一网址。收藏两三个不同实现、不同风格的主力一个、备用一个。同时把本地方案练熟这样无论哪个站点哪天打不开手上的活都不会停。这个习惯看着保守但在我经历过的几次工具站关停里一次都没耽误事。最后分享一个我经常用的小技巧遇到一段结构特别复杂、层级特别深的 JSON别急着逐层展开找字段。先用搜索框搜你要的键名多数工具会把匹配到的节点自动展开并高亮同时显示完整路径。拿到路径之后再回到根节点按路径逐层核对结构比盲目点开快十倍。这个动作我一天要做几十次算是这类工具里性价比最高的一个功能。
