JSONが読み込めないときに疑う6か所

他の言語の癖を持ち込むと、だいたい弾かれる

貼り付けるだけで、崩れている位置が表示されます。原因の見当がついてから読み進めても構いません。

許されていない6つの書き方

書き方	JSONでは
最後の項目の後ろのカンマ	不可
シングルクォートで囲む	不可。ダブルクォートのみ
項目名のクォート省略	不可。項目名も必ず囲む
コメント	不可。仕様に存在しない
文字列の途中の生の改行	不可
全角のスペースや記号	不可

上の4つは、他の言語の書き方をそのまま持ち込むと踏みます。とくに末尾のカンマは、項目を並べ替えたり増やしたりする作業のあとに残りやすく、原因としては最多です。

下の2つは日本語環境で特有です。次で詳しく触れます。

全角が混ざる問題

日本語入力のまま記号を打つと、見た目のよく似た別の文字が入ります。全角のスペース、全角のダブルクォート、全角のコロンやカンマがその代表です。

厄介なのは、画面上ではほとんど区別がつかない点です。とくに全角スペースは何も表示されないため、目で探すのは現実的ではありません。「何度見ても正しいのに通らない」という状況の多くはこれです。

対処は単純で、目で探すのをやめて機械に判定させることです。全角と半角をそろえる処理を一度かけてから読み込ませれば、この原因は候補から外れます。

エラーメッセージの読み方

出るメッセージ	意味
Unexpected token	その位置に来てはいけないものがある
Unexpected end of input	閉じかっこが足りないまま終わった
position 数字	行き詰まった位置。間違いの位置とは限らない

覚えておきたいのは3つ目です。エラーの位置は、間違いの位置ではなく、読み取りが行き詰まった位置です。

たとえば途中で閉じかっこを書き忘れると、読み取りはその先をずっと進み続け、最後まで来てから初めて行き詰まります。指摘される位置はファイルの末尾ですが、原因は数百行前にあります。

だから「指摘された行を見ても間違いがない」のは正常です。その位置の少し手前から遡って見る、あるいは前半だけを切り出して試す、という絞り込みが有効です。

直す順序

• まず末尾のカンマを探す。閉じかっこの直前にカンマがないか。頻度が最も高い原因です。
• 次にクォートの種類と数を見る。シングルクォートが混ざっていないか。閉じ忘れがないか。
• 全角をそろえる処理を一度かける。目視では見つからない原因を候補から消せます。
• かっこの数を数える。開きと閉じが一致しているか。合わなければ、それが末尾エラーの正体です。
• それでも分からなければ半分に切る。前半だけで試し、通るなら原因は後半にあります。これを繰り返せば数回で場所が絞れます。

最後の手順は地味ですが確実です。1000行のファイルでも、10回ほど繰り返せば1行まで絞り込めます。エラーメッセージとにらみ合うより早いことが多い方法です。

整形と最小化の使い分け

JSONには、読みやすく字下げした形と、余分な空白をすべて削った形があります。どちらも意味はまったく同じです。変換しても中身は変わりません。

形	使う場面
整形（字下げあり）	人が読む・編集する・差分を確認する
最小化（空白なし）	通信で送る・設定値として1行に収める

受け取った1行のJSONが読めないときは、まず整形してください。構造が見えれば、どこがおかしいのかも判断できるようになります。逆に、設定欄に貼るために1行にしたい場面では最小化を使います。

気をつける点

• 通ったからといって、内容が正しいとは限らない。文法の確認と、項目名や値が想定どおりかの確認は別の話です。
• 数値をクォートで囲むと文字列になる。見た目は似ていても、受け取る側では別物として扱われます。
• コピーで見えない文字が混ざる。ウェブページから貼り付けると、通常の空白ではない文字が入ることがあります。
• ファイルの先頭に見えない印が付くことがある。一部の編集ソフトで保存すると、文字コードを示す印が先頭に書き込まれます。画面には何も表示されませんが、読み込む側はこれを余分なものとみなして失敗することがあります。先頭でエラーが出て原因が分からないときは、これを疑ってください。

なお、同じ項目名を2回書いた場合、多くの環境ではエラーにならず後ろに書いたほうが採用されます。設定を書き換えたつもりが反映されない、という症状はこれが原因のことがあります。エラーが出ないぶん気づきにくく、整形して構造を眺めたときに初めて重複に気づく、という見つかり方をします。

整形・変換のツール

よくある質問

エラーが指す位置に、間違いが見当たりません

エラーの位置は、読み取りが行き詰まった場所であって、間違いのある場所とは限りません。たとえば閉じかっこを書き忘れた場合、その先をずっと読み進めてから最後に行き詰まるため、指摘される位置はファイルの末尾になります。原因は数百行前にあることも珍しくありません。位置の少し手前から見直す、閉じかっこの数を数える、あるいは前半だけを取り出して試す、といった絞り込みが有効です。指摘された行だけを見つめても解決しないことが多い箇所です。

末尾のカンマはなぜエラーになりますか？

JSONが意図的に狭く設計されているためです。項目を並べるときのカンマは、あくまで項目と項目の間に置く区切りであり、最後の項目の後ろには続くものがないため置けません。プログラムを書く言語の多くは、行の追加や並べ替えをしやすくするために末尾のカンマを許していますが、JSONはさまざまな環境の間でデータをやり取りする目的で作られており、解釈の揺れを避けることが優先されました。書き慣れた言語の感覚で書くと真っ先に踏む違いです。

JSONにコメントを書きたいのですが

JSONの仕様にコメントはありません。斜線2つで始める書き方も、囲む書き方も、いずれも構文エラーになります。設定ファイルとしてどうしても説明を残したい場合は、説明用の項目を作ってそこに文字列として書く方法があります。読み込む側は使わない項目として無視できます。ただし、コメントを許した独自形式を採用しているソフトもあるため、その環境のドキュメントを確認してください。標準のJSONとして他所に渡す予定があるなら、コメントは入れないほうが安全です。

日本語が別の形式で出力されます

文字を番号で書き表す方式で出力されているためで、壊れているわけではありません。読み込めば元の日本語に戻ります。この方式は、途中の経路が日本語を正しく扱えない場合でも壊れないようにするための保険として使われてきました。現在はほとんどの環境が日本語をそのまま扱えるため、出力側の設定でこの変換を止められることが多いです。人が読む設定ファイルなら日本語のまま、送信先の環境が古い可能性があるなら変換したまま、と使い分けてください。