JSON处理工具对比：从在线工具到jq命令行的实用指南

前几天调一套数据处理流程脚本跑一半直接抛异常failed to deserialize the json body into the target type: input: missing field这是典型的“某一行 JSON 数据和目标字段模型对不上”。我打开那个 .jsonl 数据集文件想快速定位是哪一行、缺了哪个字段结果编辑器的状态栏显示这一行有 18 万字符光标一移过去差点把笔记本卡死。我下意识点开浏览器收藏夹里的“JSON 工具”文件夹里面有 8 个工具攒了快三年两个在线格式化网站、一个在线转 CSV 的小站、一个 JSON 可视化编辑器、一个 Notepad 插件、一个 Chrome 扩展、一个 Postman还有一个我写了半截的 Python 处理脚本。挨个试了一圈没有一个能干净利落地告诉我就是从第 43 行开始里面少了 text 字段。最后真正救火的是一个我一直没当回事的命令行工具——jq。一条命令下去问题行全被筛出来了。后面我会详细讲它怎么做到这一步也会把 8 个被淘汰的工具挨个拆一遍给同样被 JSON 折腾过的人一个参考。1. 先说说我收藏夹里那些工具是怎么来的1.1 我日常主要和哪种 JSON 打交道我的工作经常要处理数据集尤其是一种叫 JSON Lines简称 .jsonl的格式。它和普通 JSON 数组不一样不是从[开始、到]结束、中间一堆逗号的那种大块头而是每一行都是一个独立的 JSON 对象行与行之间没有逗号加载时可以逐行读取不用把整个文件一次性吞进内存。这种格式在数据采集、清洗、模型训练里非常常见。比如 HuggingFace 的datasets库导入本地 JSON 文件时通常就是.jsonl格式很多 API 做日志导出也是一行一个 JSON 事件。我这边一个中等规模的数据集几百 MB 到几个 GB 都是常事里面每条数据大概长这样{id: 1, text: 今天天气不错, labels: [天气, 生活], meta: {source: web, ts: 1700000000}} {id: 2, text: 某电商订单异常, labels: [电商], meta: {source: app, ts: 1700000060}} {id: 3, text: 退款流程咨询, labels: [客服], meta: {source: chat, ts: 1700000120}}所以我对 JSON 工具的需求很明确格式化、校验、压缩、抽取字段、过滤数据、转换格式最好是命令行里一条命令能搞定还能塞进 Shell 脚本里跑。功能不全的工具对我来说就是鸡肋。1.2 八年工具的敝帚自珍史收藏夹里的 8 个工具不是一天攒出来的是我在无数个临时需求下今天看到一个“好像有用”就收藏明天遇到一个“应该能用上”就安装慢慢堆出来的。最早收藏的是在线格式化网站因为那时候我对 JSON 的印象就是“一串乱七八糟的字符串”扔进网页里点一下按钮就能变整齐特别香。后来做数据采集需要把 JSON 转成 CSV 给同事用又收藏了一个转换网站。再后来项目规模变大在线工具上传几 MB 的文件就开始卡我转而装了 Notepad 的插件、Chrome 浏览器扩展甚至买过一个月 Postman就为了里面那个 prettify 按钮。越攒越多但真遇到问题的时候它们反而帮不上忙。我这段时间认真复盘过这件事工具多不代表效率高。真正的分水岭不是“能格式化”而是“能不能和我的工作流融为一体”。收藏夹里的工具多数是一次性的格式化完就关掉下次再用还要重新打开、复制、粘贴做不了任何批量处理。而 jq 是那种完成格式化之后还能继续帮你查、帮你过滤、帮你转格式的工具。收藏夹里那 8 个本质上都只解决了“看”这一步jq 解决的则是“处理”全流程。2. 被替换掉的 8 个工具逐个说清楚败在哪2.1 在线派方便归方便但只适合偶尔用一次在线格式化网站典型代表是 JSON.cn、BeJSON 这类。它们的优点是零安装、打开就能用对纯新手友好。但用久了你会发现问题很明显。第一是隐私风险。你手里的数据可能是内部业务数据甚至包含用户手机号、地址。往第三方网站粘贴一份等于把数据送出去了一次。我这里有段时间上传日志做格式化后来被安全同事提醒才知道公司对这些在线工具是明令禁止的。从那以后涉及业务数据的 JSON 我根本不敢上传。第二是效率低下。浏览器开网页、粘贴数据、等待格式化、复制结果这套动作看起来只有几秒钟但如果一天要处理几十次时间成本就很吓人。更别提大文件。超过 5 MB 的 JSON 放进在线工具浏览器直接假死页面跳到“无响应”有时候连数据都找不回来。还有一个在线 JSON 转 CSV 的小工具问题更突出。它只能处理“数组里面一层对象”这种最简单的情况。一旦对象里嵌套了数组、字典转换结果直接乱套列对不上、值丢了。我刚开始以为是操作问题后来发现是工具本身就没考虑嵌套结构。它适合应付一次两次的临时需求根本扛不住真实数据。2.2 本地派装了不代表会用用了不代表能融入工作流本地工具这块我攒了四样JSON Editor Online 可视化编辑器、Notepad 的 JSON Viewer 插件、Chrome 的 JSON Formatter 扩展还有 Postman。JSON Editor Online 是个可视化编辑器左侧是原始的 JSON 文本右侧是树形结构可以展开、折叠、增删字段。它确实漂亮第一次用的时候我惊艳了好一阵。但问题是太重了处理一个小 JSON 也要开网页、等待加载而且它对大批量数据支持一般一旦文件到了几十 MB右侧树形结构渲染直接卡成幻灯片。说白了它是一个“给人看”的工具不是“给数据流水线用”的工具。Notepad 插件的典型缺点是平台锁定。它只能在 Windows 上用而我后来工作环境切成 macOS这个插件就彻底废弃了。Chrome 扩展也是这样它只是让浏览器里打开的 JSON 地址显示得更整齐遇到本地文件、管道输出、服务器响应完全用不上。Postman 就更不用说了它本质上是 API 调试工具不是 JSON 处理工具。为了一个格式化功能每次要等它启动、加载工作区杀鸡用牛刀而且牛刀还不好使。这些工具各自都很精致但它们解决的是同一个问题把 JSON 变好看。一旦问题变成“找出缺字段的行”“统计某个字段的分布”“把这几万条数据里的 email 抽出来”它们集体哑火。2.3 脚本派自己动手虽好但维护成本全在自己身上程序员碰上 JSON 问题最容易想到的就是写脚本。我以前也是这么干的而且不止一次。最轻量的是python -m json.tool它能在命令行里格式化 JSON确实是个好东西。但它的功能很单一老老实实格式化可以想过滤、想提取、想转换都要加参数、写 Python 代码等于绕了一圈回到原始时代。更失控的是我的自写脚本。最初只是写几行 Python 处理单个 JSON 文件后来需求越来越复杂要遍历 JSONL、要处理缺失字段、要按条件过滤、要输出 CSV……脚本越改越长还要处理各种边界情况最后变成了一个我没时间维护的“项目”。有一次需求变了我改了一下午越改越乱最后怒删脚本。那个下午之后我意识到很多“自写脚本”本质上是拿自己当开发资源去填工具的天坑。如果有一个现成工具能覆盖八成场景剩下两成用脚本补充根本没必要从零开始造轮子。2.4 8 个工具的横向对比工具类型主要用途被替换原因JSON.cn / BeJSON在线网站格式化、压缩隐私风险、大文件卡顿、不能批量在线 JSON 转 CSV 小站在线网站JSON 转 CSV嵌套结构支持差、数据需上传JSON Editor Online网页可视化编辑器树形编辑、格式化交互重、大文件卡顿、不可脚本化Notepad JSON Viewer桌面插件格式化、查看仅 Windows 可用、跨平台不便Chrome JSON Formatter浏览器扩展美化浏览器中的 JSON局限于浏览器、不能处理本地文件Postman桌面客户端API 调试、JSON 美化启动慢、功能太重、不适合流水线python -m json.tool命令行工具格式化功能单一、查询过滤仍需写代码自写 Python 脚本脚本处理特定数据场景维护成本高、改需求像开新项目这份表格列下来你会发现它们的共同问题没有一个是全能型的。要么只能格式化要么只能看不能处理要么功能全但太重。我需要的不是一个“JSON 显示美化器”而是一个能嵌入命令行、能批量处理、能查能改能转换的 JSON 处理器。3. 只留下这一个jq一个命令解决 90% 的 JSON 问题3.1 为什么偏偏是 jqjq 是一个命令行 JSON 处理器官网叫 jqlang.github.io/jq。它用 C 语言写的发布形式是单个可执行文件Linux、macOS、Windows 都有对应版本。不需要装运行时不需要依赖什么库下载下来就能跑。我最初对 jq 的印象是“一个玩具级别的工具”只会在终端里执行jq .然后看 JSON 变整齐。后来被那 8 个工具轮番折磨之后我才静下心去翻 jq 的文档发现它远比我想象的强。它支持字段提取、数组过滤、对象构造、条件判断、字符串操作、正则匹配、流式处理基本上能覆盖我日常 90% 的 JSON 操作。它最大的特点是“管道式设计”。在 Unix 环境里命令之间可以用管道符|串联jq 天然就是为管道而生的。cat 数据.jsonl | jq .text这是很自然的组合不需要打开任何 GUI不需要切窗口一条指令输出结果到屏幕也可以重定向到文件方便后续继续处理。3.2 格式化与校验从我的翻车现场说起回到开头那个报错。failed to deserialize the json body into the target type: input: missing field这类错误通常意味着某行数据和目标模型对不上。我当时用的 Python 模型大概长这样from pydantic import BaseModel class Sample(BaseModel): id: int text: str labels: list[str] []目标模型要求每行数据必须有text字段但数据集里混进了一些脏行。用 jq 定位脏行特别直接一条命令jq -c select(has(text) | not) dataset.jsonl-c是让输出保持单行紧凑select(...)是做条件过滤has(text) | not表示“不包含 text 字段”。运行完所有缺少 text 的行都会被打印出来。配合 jq 1.7 提供的input_line_number还可以直接输出原始行号jq -c select(has(text) | not) | {line: input_line_number, id: .id, keys: keys} dataset.jsonl我当时的输出长这样{line: 43, id: 42, keys: [id, labels]} {line: 117, id: 118, keys: [id, labels, category]}瞬间就知道问题在哪了。如果只是单纯校验 JSON 是否合法jq 也有标准做法jq -e . dataset.json /dev/null echo valid || echo invalid-e会在输入不是合法 JSON 时返回非零退出码配合和||就能判断。对 JSONL 文件逐行校验也一样jq -e . dataset.jsonl /dev/null如果第一行开始就报错说明文件开头就不对如果跑完没有输出说明整体没有语法错误。这里有个很实用的点校验和格式化是 jq 最不起眼的能力。很多人只把它当 prettify 用但其实这两步只是入口。真正让它不可替代的是下面的查询与过滤。3.3 查询与过滤替代临时写 Python 脚本的日常操作提取字段是最高频的场景。一个 JSON 对象只要取其中几个字段jq .user.name user.json嵌套字段用点号连接数组用下标。提取数组里每个对象的某个字段写法是这样jq .items[] | .name data.json这里的.items[]会把 items 数组“展开”成一个个元素然后逐个取.name。如果你的数组很大还可以继续过滤比如只取价格为 100 以上的商品jq .items[] | select(.price 100) data.json我在没完全掌握 jq 之前这种需求会写 Pythonimport json with open(data.json, encodingutf-8) as f: data json.load(f) filtered [item for item in data[items] if item[price] 100] print(json.dumps(filtered, ensure_asciiFalse))为了一个过滤逻辑开文件、读内容、写循环、输出结果这套动作重复多了真的会烦躁。用 jq 就是一行命令的事还能继续往下接管道比如统计过滤后还剩多少条jq [.items[] | select(.price 100)] | length data.json构造新对象也很常用。原始数据有一堆字段我只想保留其中几个并加一个计算字段jq .items[] | {name: .name, final_price: (.price * (1 - .discount))} data.json输出结果就是每个商品一行 JSON结构干净整齐。对于 JSONL 文件配合-c输出每行一个结果可以直接喂给下一个处理步骤。3.4 压缩、修改与转换当成数据处理流水线的标准件压缩也是 jq 的拿手好戏。格式化是往复杂里变压缩是往精简里变命令是jq -c . file.json。这个命令会把原本多行缩进的 JSON 压成一行体积小方便存日志、传消息队列、或者粘贴到一些只接受单行 JSON 的接口里。修改 JSON 结构这件事jq 也能做。比如我想给数据集里每条数据加一个timestamp字段jq . {ts: 1700000000} dataset.jsonl或者批量把status字段从old改成newjq map(.status new) data.json需要说明的是jq 不会原地修改文件它只会把修改后的内容输出到标准输出。想真正覆盖原文件需要重定向到临时文件再移动回来jq map(.status new) data.json /tmp/data.json mv /tmp/data.json data.json转换格式是另一个高频需求。把 JSON 数组转成 CSVjq 一行就能搞定jq -r .items[] | [.name, .price, .category] | csv data.json-r表示裸输出不加 JSON 字符串的引号csv会把数组变成一行逗号分隔的文本自动处理转义。结果长这样商品A,199,数码 商品B,399,家电配合输出重定向就能直接生成 CSV 文件jq -r .items[] | [.name, .price, .category] | csv data.json result.csv同样的思路tsv可以转成制表符分隔的格式。这个能力在过去我要写十行 Python现在一秒钟完成。3.5 文件大了怎么办在线工具处理大文件会卡死jq 在这方面强得多。前面提过我手里有几百 MB 甚至几个 GB 的 JSONL 数据jq 跑过滤和提取都能扛住。普通文件加载进内存处理没问题但如果你要处理的是超大单文件比如几个 GB 的 JSON 数组jq 也提供了流式模式jq --stream select(.[0] | contains([text])) big.json流式模式把 JSON 拆成一串路径和值的组合逐个处理不会一次性加载整个数据结构进内存。不过说实话流式模式的表达式写起来稍微费脑日常用到的机会不算多。大多数场景下几百万行的 JSONL 数据用jq select(...)直接跑性能完全够。实测下来一个 400 MB 左右的 JSONL 文件做字段过滤加提取耗时在几秒到十几秒之间。考虑到数据量这个速度我很满意。而且 jq 是原生 C 编译的程序启动几乎没有延迟不像图形工具又要打开界面又要加载数据。4. 从收藏到真正会用jq 避坑清单4.1 新手最容易碰的语法问题用 jq 最容易踩的坑第一个是忘了加-r。默认情况下jq 输出的字符串是带 JSON 引号的。比如执行jq .name user.json结果可能是张三而不是张三。如果你想到文件里想要的是纯文本就必须加-rjq -r .name user.json第二个坑是单引号和双引号的问题。在 Shell 里jq 表达式一般用单引号包起来比如jq .a.b。因为表达式里有$、空格、括号之类的特殊字符双引号会被 Shell 先解释一轮很容易出问题。我见过不少人在 Windows 的 cmd 或 PowerShell 里折腾半天后来换了单引号就好了。第三个坑是混淆.foo和.foo[]。.foo取的是数组整体.foo[]是展开数组里的每个元素。如果数组嵌套了一层想要每个子对象里的字段就必须写.foo[].bar。结构不对输出结果会差很多。第四个坑是 jq 用length获取对象数量或字符串长度但它对不同类型的行为不一样。数组是元素个数字符串是字符个数对象是键的个数。指望一个length走天下可能算出来和你预期不一样。4.2 编码、精度与 Windows 环境的坑中文编码问题几乎是必踩的坑。默认情况下jq 转成 JSON 字符串时会把非 ASCII 字符转义成\uXXXX比如“中文”会变成\u4e2d\u6587。这样虽然安全但不方便阅读。想保留原文加一个--unicode-output参数或者直接在命令里传-ujq -u .text dataset.jsonl另一个容易忽略的坑是长整数的精度问题。JSON 里的数字jq 底层使用双精度浮点数表示超过 2 的 53 次方的整数比如雪花 ID、某些 64 位大整数会被截断导致精度丢失。你处理包含超大 ID 的数据时如果发现 ID 尾巴变成 0别觉得是数据问题多半是 jq 的数值精度上限到了。这种情况我的建议是如果对这些 ID 只是原样透传不要用 jq 输出 JSON 格式尽量用-r转成字符串如果要做复杂处理改用 Python 的int类型更稳。Windows 环境还有个容易忽略的问题PowerShell 默认的输出编码可能不是 UTF-8导致中文乱码。我建议 Windows 上优先用 Git Bash 或者 WSL 来跑 jq省去一堆编码和引号相关的折腾。安装的话Windows 可以用winget install jqlang.jq或者scoop install jqmacOS 用brew install jqLinux 用包管理器装就行。4.3 哪些场景还是别硬用 jqjq 很强但也不是万能的。遇到下面几种情况我建议你可以放弃 jq老老实实回到 Python 或其他专用工具。一种是复杂的 JSON Schema 校验。jq 能做存在性判断可以做条件过滤但如果你想校验字段类型、枚举值、对象结构是否完全符合某个规范那就不是 jq 擅长的领域了。这类需求适合用 JSON Schema 校验库比如 Python 的jsonschema。一种是超大数据规模的频繁交互。jq 的单次查询性能很好但不适合交互式浏览。如果你需要像操作 Excel 一样频繁展开、折叠、编辑 JSON用 JSON Editor Online 或 VS Code 的 JSON 插件体验会好很多。工具不是越高级越好合适才是硬道理。还有一种是你需要把逻辑封装成可复用的业务代码。jq 表达式写出来很爽但它不是一种通用编程语言写复杂分支和循环会很别扭。如果你的处理逻辑超过十行后续还要被别人维护用 Python 或者 Go 写成一个正式的小服务会是更合理的选择。写在最后我现在收藏夹里已经空了一大半只留了几个真正高频的工具jq 是其中之一。说实话刚开始学 jq 的时候我也觉得它语法奇怪记不住.foo、.foo[]、select这些写法。但坚持用了两周之后它已经成了我肌肉记忆的一部分。每次在终端里敲出jq开头的命令我都觉得比点开收藏夹里任何图形界面工具要踏实。如果让我给一个具体建议那就是不要把它当成一个“格式化工具”来学而是当成“JSON 的水管工”让它帮你从 JSON 里取数、过滤、变形、连接下一个命令。收藏夹里的工具少了解决问题的方法反而多了。最后再多说一句如果手头有一批 JSONL 数据要处理花一个小时把jq -r、select、map、csv这几个基础操作练熟回报率高得惊人。同一个坑踩过一次就长记性但没必要在 8 个工具里反复踩。