開発者ツール · JSON フォーマッタおよびバリデータ
JSON を壊す非表示文字: BOM、スマート クオート、NBSP
· 仕組み
json 開発者ワークフロー 検証
バリデーターが最初の文字でエラーを報告し、ファイルが完璧に見える場合、通常は非表示の文字が原因です。この投稿では、バイト オーダー マーク、タイポグラフィー引用符、非改行スペース、およびそれぞれがどのように報告されるかについて説明します。
行 1、列 1、異常はありません
行 1、列 1、何も問題はありません。JSON ドキュメントは実際の位置を占める文字で始まる可能性がありますが、表示されるグリフは表示されません。この場合、バイト オーダー マークまたはゼロ幅文字が前にある場合でも、左中括弧が最初にあるように見えます。厳密なパーサーは、`{` に到達する前にその隠されたコード ポイントに遭遇するため、最初の列のレポートは曖昧ではなく正確になります。ディスプレイと文字列は単に異なるストーリーを伝えます。
キャレットが横に表示されているという理由だけで、正しく見える中括弧を削除しないでください。報告されたオフセットのコード ポイントを検査し、表示される空白を有効にするか、16 進数表示に切り替えます。 ToolAcre は解析前に先頭の BOM をサイレントに削除せず、スキャナーは最初の予期しない文字を報告します。
UTF-8 バイト オーダー マーク
UTF-8 バイト オーダー マーク — ファイルの先頭で U+FEFF にデコードされるバイト シーケンス EF BB BF。 UTF-8 ではバイト順序があいまいではないため、マークは不要ですが、一部のエディターやエクスポート ツールではエンコード署名としてマークが追加されます。 RFC 8259 では、JSON ジェネレーターはネットワーク化された JSON に BOM を追加してはならないと述べていますが、パーサーは相互運用性のために BOM を無視することを選択する場合があります。この許容誤差は、複数のツールにわたって想定することはできません。
JavaScript 文字列では、UTF-8 表現が 3 バイトを使用する場合でも、BOM は 1 文字です。 ToolAcre は文字列文字で位置を報告するため、行 1、列 1 に先頭のマークが表示されます。ファイルを配布する前に、BOM なしで UTF-8 を保存するか、U+FEFF を削除するようにエディターを構成します。
ワードプロセッサからのスマートな引用
ワード プロセッサからのスマート引用符 — 活版印刷の開始記号と終了記号は散文で洗練されているように見えますが、JSON は ASCII 引用符 U+0022 のみを文字列区切り文字として認識します。 U+201C と U+201D は通常の Unicode 文字です。文字列の外側ではプロパティ名や値を開始できないため、バリデーターはスマート クオート自体をレポートします。チャット、電子メール、またはドキュメント エディターでの自動修正では、JSON が元々有効だった後に変更が導入されることがよくあります。
区切り文字を二重引用符で置き換えてから、値に属するアポストロフィと引用符を調べます。中引用符は、`"She said “go”"` など、正しく区切られた JSON 文字列内のコンテンツとして完全に正当です。区切り文字の文法上の役割を実行するように求められた場合にのみ失敗します。
非改行スペースとゼロ幅文字
非改行スペースとゼロ幅文字 — JSON ホワイトスペースは意図的に短いリストです: 通常のスペース U+0020、タブ U+0009、ライン フィード U+000A、キャリッジ リターン U+000D。非改行スペース U+00A0 は、コロンと値の間の通常のスペースと同じに見えるかもしれませんが、リストには含まれていません。幅ゼロのスペース U+200B は何も表示しませんが、引用符で囲まれた文字列の外側では予期しない文字のままです。
Web ページでは単語をまとめるために非改行スペースが使用され、メッセージング システムでは折り返しやスクリプト処理のためにゼロ幅文字が挿入される場合があります。フォーマットされたスニペットをコピーすると、それらを設定に取り込むことができます。報告されたオフセットに基づいて、構造 NBSP 文字を通常のスペースに置き換え、意図しないゼロ幅文字を削除します。
動作例: チャット メッセージからコピーされた構成
有効な例: チャット メッセージからコピーされた構成 — 表示されるテキストは `{"mode": "safe"}` に似ていますが、最初に検証が失敗するとします。 16 進ビューでは、ブレースの前の EF BB BF が表示されます。その BOM を削除すると、次のレポートが `mode` より前の見積 (実際には U+201C) に進みます。両方のスマート区切り文字を U+0022 に置き換えると、コロンと値の間に U+00A0 が表示されます。
構造的な非改行スペースを U+0020 に変更し、もう一度検証します。受け入れられた結果を通常どおりフォーマットできるようになりました。このシーケンスは、画面に表示されているように見えるものだけを修復することが信頼できない理由を示しています。いくつかの目に見えない文字や似ている文字が、文法上の異なる位置を占める可能性があります。各行と列をたどって、実際のコード ポイントを特定し、意図的な置換を 1 つ行って、検証を再実行します。
目に見えないものを見る方法
目に見えないものを確認する方法 — エディターのレンダリング ホワイトスペース オプションを有効にして、タブとスペースを区別し、異常なギャップを明らかにし、引き続き同一に見える文字に対して Unicode インスペクターまたは 16 進ビューを使用します。 UTF-8 BOM は EF BB BF として表示され、非改行スペースは C2 A0 として、ゼロ幅スペースは E2 80 8B として表示されます。スマートな開始引用符と終了引用符は、E2 80 9C および E2 80 9D として表示されます。
カウントする前に診断の座標系を一致させます。 ToolAcre は JavaScript 文字列をスキャンするため、その列は UTF-8 バイトではなく UTF-16 コード単位をカウントします。したがって、バイト指向の 16 進エディタでは、非 ASCII 文字の後に大きな数値オフセットが表示されることがあります。報告された行を使用して検索を絞り込み、隣接するコード ポイントを検査し、必要な場合にのみ変換します。
これでカバーされない内容
これでカバーされないもの — `café` などの mojibake は完全に有効な JSON になる可能性があります。パーサーは文字列文字の通常のシーケンスを認識しますが、UTF-8 バイトが以前に別のエンコーディングとしてデコードされたという証拠はありません。同様に、引用符で囲まれた値内の非改行スペースまたはゼロ幅文字は構文的に有効です。検証では、JSON 文法に違反する文字を検出します。有効な Unicode コンテンツが作成者の意図と一致するかどうかを判断することはできません。
元のエンコーディングと誤ったエンコーディングの知識を使用して、バイトがテキストになる境界でエンコーディングの破損を修復します。 JSON 文字列のエンコードとデコードを、見た目が良くなるまで繰り返し行わないでください。すでに正しい文字が損傷する可能性があります。アプリケーション レベルの正規化もまた別の決定です。視覚的に同一の Unicode シーケンスは、有効なままでも比較が異なる場合があります。
要点: 行がきれいに見えても、報告された列を信頼してください
要点: 行がきれいに見えても、報告された列を信頼してください。目に見えない文字や類似した句読点がソース内の正確な位置を占めていることになります。先頭の BOM、中括弧、非改行スペース、またはゼロ幅マークにより、パーサーが正しく見える中括弧や引用符に到達できない可能性があります。近くに表示されている JSON をランダムに編集するのではなく、空白を表示し、コード ポイントまたはバイトを検査し、その文法的役割と矛盾するアイデンティティを持つ文字を置き換えます。
16 進数ツールがエンコードされたバイトをカウントする一方で、位置は文字をカウントする可能性があることに注意してください。そのため、すべてのオフセット番号が一致すると期待するのではなく、周囲のテキストを比較してください。ドキュメント境界でのみ BOM を削除し、スマート区切り文字を U+0022 に変換し、文字列内の正当な Unicode を消去せずに無効な構造スペースを置き換えます。