JSON 严格模式：收下 .5，拒掉尾逗号

# JSON 严格模式：收下 .5，拒掉尾逗号

Zillio 里有个 ldb，对外叫 rdb。它每次存表之前，都要先看一眼客户端递上来的 filter JSON，坏的挡在门外。这个「看一眼」以前是手写的，一百来行。前天（9 月 27 日）上游给 `getJson` 加了个 `json: 2` 严格模式，我以为可以把那一百行删了，结果第一次替换反而把冒烟测试跑挂了一条。

## 一、默认的 getJson，宽松得有点吓人

Fun 的 `getJson()` 是个流式扫描器，图的是快和宽容。宽容到什么程度：

```fun
?. '{ "a" : }'.getJson().a;                 // a
?. '{bad}'.getJson().@toJson(json:true);    // {"":"bad"}
?. '{"a":1,}'.getJson().a;                 // 1，尾逗号照收
```

键后面没值，它把键名拿来当值，`{"a": }` 就变成 `{"a":"a"}`；`{bad}` 拆出一个空键。这也怪不得它，Fun 本来就不爱报错，作者的原话是「最怕报错，很吓人，所以 fun 语言相对温柔」，宽容是刻意的默认。但一个数据库后端不能温柔，坏 JSON 收进去，坏的就是库里的数据。于是 rdb 自己写了 `CheckJsonStrict`，配一组 `JsWs / JsLit / JsStr / JsNum / JsArr / JsObj / JsVal`，一百行左右，专拦这些。（吐槽：干后端的，最后都在给数据格式当门卫。）

## 二、`json: 2` 第一次，替不了

上游 `1dbdd59` 给 `getJson` 加了严格模式：`json: 2`。实现是在原来那台扫描器上挂一个 `StrictFail` 开关，只在几处硬伤上报错，未闭合、括号失衡、冒号后面没值、数字后面跟字母、裸词、顶层残留。

我拿它把 rdb 的手写校验换掉，`run-smoke.sh` 直接挂了一条：尾逗号被收下了。方向反了，是净回归。

原因也不复杂：`,` 和 `;` 在扫描器里只做一件事，把当前项 flush 掉。所以尾逗号、首逗号、重复逗号、缺逗号，它一概察觉不到；数字只贪婪扫一段 `[0-9.eE+-]` 再交给 `StrToNum`，`1.`、`.5`、`03` 这种也不管。严格开关管的是「结构坏了」，不是「文法坏了」。

## 三、补一个状态机

于是同一天连着九笔提交，把分隔符文法真做了进去。核心是一个状态变量 `st`：

```
0  期待一个值或键
1  一个值刚完成
2  刚过 ','
3  刚过一个对象键
4  刚过 ':'，等值
```

再加一个和解析栈平行的 `StackObj`，记每一层打开的容器是不是对象。这里有个省事的地方：容器只能从「值槽」打开，关掉之后外层状态必然是 1，所以状态不用按层各存一份，一个全局的 `st` 就够。

补上之后，这些全被拒了：尾逗号 `{"a":1,}`、首逗号 `[,1]`、重复逗号 `[1,,2]`、缺逗号 `[1 2]`、缺冒号 `{"a" 1}`、`;` 和 `=` 当分隔符、单引号与反引号串、`@` 日期、`0xff`、`nil`、非字符串的键（`{a:1}` / `{1:2}` / `{[1]:2}`）、收尾括号和容器对不上（`[1,2}`）、顶层值后面的残留（`{"a":1} 2`）、全空白。空文档报 `no JSON value`。

这一批还顺带修了一个老毛病：输入的结尾以前不算终结符，最后一条如果没带分隔符就被丢掉，`name: zhang, age: 20` 只剩 `name`。现在结尾当成一个隐式的分隔符。

## 四、故意不收的那一处

有一块是**故意**保持宽松的：数字。`.5`、`03`、`1.` 在严格模式下照样接受。

理由实在：真实世界里的 JSON 就有人写 `.5`，为一个理论上的文法洁癖去拒它，是给自己找麻烦。严格模式该拦的是「结构错」和「明显的垃圾」，不是把每一个不完全符合 RFC 8259 的数字都推出去。所以它只拒完全不含数字的记号，单独的 `.`、`-`、`--`。

字符串这一侧则收得很紧：未转义的控制字符、非法的转义、四位十六进制不对的 `\u`，都拒；但这些检查是折进「找右引号」的那一趟扫描里做的，没有额外多跑一遍。解码用的 `esc()` 一行没改，所以宽松模式和 FD 解析逐字节不变。

验证也做得挺实。JSONTestSuite 里 95 个合法用例（`y_*`）全过；188 个非法用例（`n_*`）拒掉 170 个，剩下 18 个全是数字文法那一类，属于有意放行。再拿 Python 的 `json` 和 Node 的 `JSON.parse` 各跑几千条随机与变异语料做差分，合法的输入没有一条被严格模式误拒。这点比「拒了多少」更要紧，一个会把好数据判坏的严格模式，没人敢用。本机复跑 `fun/test/strict-valid.fun`，全 PASS。

## 结语

严格不是把人拦在门外，是拦住不该进来的东西。多拒一条垃圾容易，少误伤一条真数据难；`json: 2` 花在后者上的心思，比花在前者上的多。

等它稳一稳，rdb 里那一百行 `CheckJsonStrict` 就能整个删掉，改用 `getJson(json: 2)`。手写的校验终于可以退休，这也算给那九笔提交一个交代。