JSON を検証

JSON のパーサーは辻褄が合わなくなった瞬間に止まります。その地点は、しばしば本当の誤りよりかなり後ろです。12 行目のカンマ落ちは、13 行目でカンマのあるべき場所に引用符が現れて初めて発覚します。そしてメッセージは 13 行目を指します。

だからここでは数字だけでなく、地点を印した断片が出ます。文脈が見えることが「4 列目」を「上の行のカンマが落ちている」に変えます。それが 10 秒で直すのと、200 行の文書を睨み続けるのとの差です。

同じ壊れた文書が、Chrome と Firefox と Safari で違うメッセージを出します。JavaScript のエンジンごとに文面を書いているからです。位置を文字オフセットで示すものもあれば、位置をまったく示さないものもあります。

ここでは行と列を、メッセージの文面に頼らずオフセットから計算します。どのブラウザーでも答えが同じになります。どこを見ればよいかを告げるためだけに存在する道具に求められる、最低限のことです。

閉じ波かっこや閉じ角かっこの前の余分なカンマ。2 つの要素のあいだのカンマ落ち。ダブルクォートの代わりのシングルクォート。そして引用符のないキー。突き返される文書の圧倒的多数はこの 4 つで、4 つとも JSON を JavaScript のつもりで書いたことから来ます。

5 つめはもっと厄介です。文書の先頭にある見えない文字、ほぼ確実に Excel や Windows の一部のエディターが先頭に付ける BOM です。文書は完璧に見えるのに、パーサーは 1 列目で落ちます。誰も見ない場所がちょうどそこです。

文書が妥当な JSON であるとは、構文が整っているという意味であり、それ以上ではありません。数値であるべき項目が文字列で届いても、相手の期待しない書式の日付でも、キーが半分欠けたオブジェクトでも、この検査は通ります。

ここで妥当と出る文書を API がなお突き返すなら、問題はもう構文ではなくスキーマです。それは JSON Schema のバリデーターがその API の具体的なスキーマに対して確かめることで、このページが終わるちょうどそこから始まる別の問いです。

タブを含む行の列を数えるのは曖昧です。タブは 1 文字ですが、画面上はエディターの設定次第で 4 桁分にも 8 桁分にもなります。文字数で計算した列番号は、そのとき目に見えるものと一致しません。

ここではパーサーと同じく文字を数え、抜粋のほうはタブを展開して表示します。印した地点が目の期待する位置に落ちるようにするためです。ごく小さな細部ですが、助けになる目印と混乱させる目印の違いはそこにあります。

文書が通ったときは、その形も出ます。最上位がオブジェクトか配列か、キーがいくつあるか、どこまで入れ子になっているか、どれくらいの大きさか。どう処理するかを決める前に人が見る数値です。

4 つのうち最も役に立つのは入れ子の深さです。多くのパーサーと多くの API に上限があり、自動生成される文書は誰も予期しないうちにそれを超えます。意味の分からないエラーを説明してくれる日まで、誰も見ない数値です。

文書に、正確なまま保てないほど大きな整数が含まれていれば、文書自体が妥当であってもその旨を伝えます。構文の誤りではなく、読み込む時点で起きる静かな損失で、JavaScript のパーサーを使うどのシステムでも同じように起こります。

独立した注意に値するのは、これが最も診断しにくい失敗だからです。文書はきれいに入り、きれいに出て、その途中で識別子の下の桁が変わっている。受け取ったシステムは、なぜかの手がかりなしにレコードを見つけられません。

このページは 1 つの問いに答えます。どこで落ちるか。字下げして文書を見るのは整形のページの仕事で、そちらには字下げの選択とキーの並べ替えもあります。ここではどちらも出番がありません。

この区画でエンコードとデコードを分けているのと同じ判断です。ここに来る人は壊れたものを持っていて場所が欲しく、あちらに来る人は読めないものを持っていて見たいのです。1 つにすれば、双方にとって半分が余るページになります。

何かに突き返されている文書は、たいてい本物の文書です。注文、顧客の記録、氏名と住所の入った webhook の本文。検査はページの中で行われるので、そのいずれも当方へ提供されず、当方のどのリクエストログにも残りません。

社内規程が防ごうとしているのはまさにこの事態——デバッグのために個人データを第三者のサービスへ貼り付けること——であり、ここではそれが起きません。受け取る第三者のサービスが存在しないからです。使っているあいだ、ネットワークパネルがそれを示します。