fx 40.0.1 是终端里的 JSON 查看器,单个 fx.exe 21801472 字节,压缩后是直接下载的 exe,没有安装包。

它要解决的是:手上有个几 MB 的 JSON,想知道里面长什么样、某个字段到底在哪一层。用 jq 得先猜路径,猜错了只回一个 null。

这次拿一份 1072296 字节、10000 条记录的 JSON 做输入,量了取字段的耗时,另外踩了一个选择器语法的坑。

一个 21801472 字节的 exe

它是单文件可执行程序,Go 编译,静态链接,不需要任何运行库。

项值说明
fx.exe21801472 字节fx_windows_amd64.exe,直接下载
版本40.0.1--version 输出一行
测试输入1072296 字节10000 条记录的数组
输入格式6 种JSON 默认,另有 YAML、TOML、EDN、MAML 与原始字符串

六种输入格式靠开关切换

默认按 JSON 解析,换成别的格式要显式给参数,不会自动识别。

参数作用
-r, --raw把输入当原始字符串,不做解析
-s, --slurp把所有输入读进一个数组
--yaml按 YAML 解析
--toml按 TOML 解析
--edn按 EDN 解析
--maml按 MAML 解析
--themes列出内置主题
--comp <shell>输出补全脚本

--themes 输出 126 行,把每套配色的字符串、数字、布尔、空值的颜色一次打印出来,可以直接贴进配置文件改。--comp bash 只回 31 字节,补全脚本做得很轻。

--slurp 是处理多行 JSON 的开关

文件里一行一个 JSON 对象时,默认只按第一行解析;加 -s 才会把全部输入收成一个数组。日志类数据基本都要这个开关。

1 MB 的 JSON,取一个字段 147 毫秒

同样是 1072296 字节的输入,取不同位置的字段耗时接近,取长度慢一些。

选择器耗时输出
.[0].name147 msitem-00000
.[9999].nested.deep.v155 ms19998
.length222 ms10000

取第一个和取最后一个差 8 毫秒

147 对 155 毫秒,说明整份文件在取值前就已经全部解析完了,位置不影响时间。这跟流式处理的工具不一样,它是先读全再答。

.length 反而最慢

222 毫秒对 147 毫秒,慢了 75 毫秒。取单个字段只输出那个值,取长度要先遍历完整的 10000 条记录再算出结果,两条路径的工作量不一样。

选择器要带点,不然静默失败

数组索引不能写成 [0].name,必须写 .[0].name。写错不报错,输出 undefined。

写法结果
.[0].nameitem-00000,正确
[0].nameundefined,退出码 1
.[9999].nested.deep.v19998,正确

写错只给 undefined

少了那个点,程序认为这是个不合法的表达式,但没有任何错误提示,只是打印 undefined 并以 1 退出。第一次用时很容易以为数据有问题。

fx 40.0.1 全屏打开一份三元素 JSON 数组:键为白色、字符串为黄色、数字为蓝色,括号与逗号灰色,对象和数组按两空格缩进,窗口标题写着 demo.json,右下角显示 1% 的滚动位置

根节点是数组时尤其要注意

根是对象时可以写 .field,根是数组时就得 .[0]。两种根结构在同一个脚本里混用时,这个点最容易漏。

界面是全屏的树

不给选择器时进交互模式,把整份 JSON 画成一棵可折叠的树,底部一行状态提示当前位置。

区域内容
主体缩进的两空格层级,键与值分色显示
折叠对象与数组可以收起
底部右侧当前滚动位置,形如 1% demo.json

什么场景值得上

面对一份结构不明的 JSON,先看清形状再决定取什么。

场景合适度说明
不知道字段在哪一层高全屏树,折叠展开,不用猜路径
脚本里取一个值中147 毫秒起步,比专门的取值工具慢
YAML 或 TOML 配置中加 --yaml / --toml 即可
处理多行 JSON 日志中要记得加 --slurp

它和取值工具的分工

fx 强在看,弱在批处理。要把结果喂给下一个命令时,输出格式和错误处理都不如专门的查询工具干净。

授权与费用

MIT 许可,个人和商业环境都不收费。源码在 GitHub 上,主要语言 Go,release 覆盖 Windows、macOS、Linux 三平台。