無料 JSON バリデーター
JSON構文をリアルタイムで検証します。行番号付きの詳細なエラーメッセージを取得し、一般的な問題を自動修正し、JSONを瞬時にフォーマット/ミニファイします。
JSON検証について
JSONバリデーターは2値の質問に答えます、これは整形式のJSONドキュメントですか?、入力をブラウザが内部で使用するのと同じパーサーに渡し、構文を受け入れるかどうかを報告します。このツールはそれだけを行います。ドキュメント内のデータが意図したことを意味するかどうかはチェックしません。その2番目の質問、ドキュメントはアプリケーションが期待する形、型、制約を持っているか?、はスキーマ検証で、Ajv(下記参照)のようなツールの領域です。2つの活動は互いを補完し、異なる質問に答えます; もう一方が欲しかったときに一方を使うのはカテゴリーエラーです。便利な類推は、ワードプロセッサーのスペルチェック / グラマーチェックの区別です: スペルチェック(構文)は各単語が本当の単語かどうかを伝えます; グラマーチェック(スキーマ)は文が意味をなすかどうかを伝えます; 両方とも有用で、どちらももう一方を置き換えず、どちらもエッセイが良いかどうかを伝えません。{"phoneNumber": 12345}は整形式のJSONですが、アプリケーションが"+1-555-555-1234"のような形式の文字列を期待していた場合、それは間違っており、構文バリデーターはそれを伝えることができません。
構文チェックを超えて、このツールはまた、開発者が誤って無効なJSONを書く4つの最も頻繁な方法を書き直すベストエフォートの「一般的な問題を修正」パスを提供します: トレイリングカンマ、シングルクォート文字列、引用符なしのキー、およびundefinedリテラル(nullに書き直されます)。これはヒューリスティックでパーサーではないため、採用する前に常に修正された出力を確認してください。
JSONの簡単な歴史
JSONは非常に短い伝記を持っています。頭字語はState Software, Inc.で造語されました。これはDouglas CrockfordとChip Morningstarが2001年3月に共同設立した小さなコンサルティング会社で、後にAjaxウェブアプリケーションと呼ばれるものを構築するためでした。最初のJSONメッセージは2001年4月にMorningstarのベイエリアのガレージにあるコンピューターから送信されました。CrockfordはJSONを発明したと主張しません、フォーマットは既にJavaScript言語内のオブジェクトリテラルのサブセットとして存在していました; 彼の貢献はそれを剥がし、名前を付け、ウェブサイトを立ち上げ(json.orgは2002年に3つの表記でのグラマーの記述とJavaScript参照パーサーで立ち上がりました)、採用のためにロビー活動をすることでした。2005年12月はほとんどの歴史家がJSONが主流に渡った瞬間として指摘するものです: その月、Yahoo!はそのウェブサービスのいくつかをJSONで提供し始めました。IETFは次にそれを取り上げました: RFC 4627("The application/json Media Type for JSON")、Crockford自身が書いたもので、2006年7月に情報文書として公開され、Standards Trackではありません。標準化団体は2013-2014年に追いつきました: ECMA-404 第1版2013年10月(意図的に最小限、実質的な内容6ページ)、RFC 71592014年3月(トップレベル制限を緩和し、オブジェクトと配列だけでなく、任意のJSON値が完全なドキュメントになれるように)、そして現在のペア2017年12月: RFC 8259(現在Internet Standard STD 90)とECMA-404 第2版が規範的に整合しています。2つはペア結合します: それぞれが他方を規範的に参照し、それらを一貫させる約束を含んでいます。ISO/IEC 21778:2017としても公開されています。
200語でのJSONグラマー
JSONドキュメントは単一の値で、オプションで空白で囲まれます。正確に6つの値型があります: オブジェクト、ゼロ以上の名前/値ペアの順序のないコレクション、{"k": v, "k2": v2}と書かれます; 配列、順序付けられたシーケンス、[v, v2, v3](仕様により配列は順序を保持します); 文字列、ダブルクォートで囲まれたUnicode文字のシーケンス(シングルクォートは許可されません; バックスラッシュは\"、\\、\/、\b、\f、\n、\r、\tに加えて\uXXXXをエスケープします; 制御文字U+0000からU+001Fまではエスケープする必要があります); 数値、厳格なASCII形式(オプションのマイナス記号、先頭ゼロのない整数部、オプションの小数部、eまたはEでのオプションの指数); true / false、JSONブール値、小文字のみ; null、値の不在、小文字のみ。トークン間の空白は許可され、無視されます。コメントなし。トレイリングカンマなし。オブジェクトキーはダブルクォート文字列でなければなりません。 グラマーは1ページに収まります。厳格な数値形式は、hex(0xFF)、octal(0777)、+記号、Infinity、NaN、および1.のような末尾の小数点を禁止します; これは、より緩いECMAScript数値形式を受け入れる環境で手でJSONを書く人を捕まえます、最も一般的には、JSONファイルに16進数の色コードを貼り付けたことがある人。
なぜグラマーがこれほど厳格か、Crockfordのデザイン選択
2つの意図的な省略がユーザーが手でJSONを書くときに感じるほとんどの摩擦を説明します。コメントなし。 JavaScriptには//と/* */の両方のコメントがあります; JSON、JavaScriptのサブセットには、どちらもありません。Crockfordが述べた理由、2012年にGoogle+に投稿されたもの、はそれ以来何千回も引用されています: 「私がJSONからコメントを削除したのは、人々がそれらをパース指示を保持するために使用しているのを見たからです。これは相互運用性を破壊する慣行です。コメントの欠如が一部の人々を悲しませることは知っていますが、そうあるべきではありません。」 議論は、コメントが拡張を招くということです、もし// @schema foo.jsonがあなたのconfigにあり、あなたのツールがそれを読むなら、あなたのconfigファイルはもうJSONではありません。トレイリングカンマなし。 カンマはセパレーターであり、ターミネーターではありません。[1, 2, 3]は合法ですが[1, 2, 3,]はそうではありません。理由はコメントと同じです: グラマーのシンプルさとパーサー間の均一性です。コストは、複数行のJSONオブジェクトを編集する人、プロパティを追加、プロパティを並べ替え、最後のプロパティを削除する人がカンマについて考えなければならないことです。undefinedなし。 JavaScriptにはundefinedがあります; JSONにはありません。nullを使うか、プロパティを完全に省略してください。入力のBOM。 JSONドキュメントの先頭にあるbyte-order mark(U+FEFF)は送信されたJSONでは禁止されていますが、パーサーはそれが現れた場合に無視してよいです。実際には、古いWindowsエディタによって「BOM付きUTF-8」として保存されたファイルは、一部のパーサーを静かに壊し、他のパーサーで静かに動作します。
一般的なJSONエラー:
- 末尾のコンマ: オブジェクトまたは配列の最後の要素にコンマを付けることはできません
- 二重引用符ではなく一重引用符: JSONは文字列に二重引用符のみを許可します
- 引用符のないキー: オブジェクトのキーは常に二重引用符で囲む必要があります
- コメント: JSONはコメントをサポートしていません(一部のツールは受け入れますが)
- エスケープされていないバックスラッシュ。 JSON文字列内では、
\はエスケープ文字です。"C:\Users\Alice"は\Uと\Aが認識されないエスケープであるため失敗します。治療法はすべてのバックスラッシュを2倍にすることです:"C:\\Users\\Alice"。 - エスケープされていない制御文字。 JSON文字列内のリテラル改行、タブ、またはU+0000-U+001Fの他の文字は禁止されています。ほとんどのユーザーは、改行を
\nとしてエスケープせずに複数行の文字列をJSON値に貼り付けたときにこれに当たります。 - NaNとInfinity。 JSONグラマーの一部ではありません。ブラウザの
JSON.parseはそれらを拒否します。JSON.stringifyはNaNまたはInfinityをシリアル化するように求められるとnullを生成するので、ラウンドトリップは静かに情報を失います。 - 空の入力。 "Unexpected end of JSON input" をスローします。落とし穴は、
Content-Type: application/jsonで戻ってきたが本文が空のHTTPレスポンスは、fetch().then(r => r.json())チェーンでこのエラーを生成します。
JSON Schema、形状検証の標準
JSON SchemaはJSONドキュメントの構造と制約を記述するためのJSONベースの語彙です。最初の提案は2007年10月にKris Zypによって提出されました; IETF Internet-Draftシリーズは2009年12月5日のdraft-zyp-json-schema-00から始まりました。連続するドラフトは次の10年半の間に6人の著者と編集者を通じて進化しました。現在の安定バージョンは2020-12ドラフトです(「2020-12」名は、それが派生した開発スナップショットを指します; 実際の正式リリースは2022年6月16日でした)。最も使用される4つのアサーションキーワードが日常の作業のほとんどを担います: type(値を6つのJSON型のいずれかまたは許容可能な型のリストに制約する)、required(オブジェクトが含まなければならないプロパティ名のリスト)、properties(プロパティ名から値のサブスキーマへのマップ)、およびitems(配列のすべての要素に適用されるスキーマ)。minimum、maximum、minLength、maxLength、pattern(regex)、format(date-time、email、IPv4など)、および複合キーワード(allOf、anyOf、oneOf、not)と組み合わせると、JSON Schemaはデータが満たす必要のあるほぼすべての「形状」制約を表現できます。スキーマ自体はJSONドキュメントで、ある人は優雅と感じ、ある人はめまいがすると感じる方法で再帰的です。
Ajv、支配的なJavaScriptスキーマバリデーター
JavaScriptでスキーマ検証を行いたい場合、標準的な答えはEvgeny PoberezkinによるAjv(Another JSON Schema Validator)です。そのトリックはスキーマを最適化されたJavaScriptにコンパイルすることです: ランタイムにスキーマとデータツリーを歩く代わりに、すべてのチェックをハードコードしネイティブ速度で実行する関数を生成します。これにより、大きなドキュメントとホットな検証パスでナイーブなバリデーターより劇的に高速になります。AjvはJSON Schemaのドラフト04、06、07、2019-09、および2020-12をサポートします; express-validator、AWS API Gateway リクエスト検証、および多くの主要なNode.jsフレームワークに組み込まれているバリデーターです。Pythonの場合、標準的な選択はJulian Bermanによるjsonschemaです; Javaの場合、Networknt のjson-schema-validator。ポイントは、スキーマ検証は解決された、成熟した、よくツール化された問題ですが、スキーマを書くことによって参加する必要がある問題であることです。このツールはあなたのためにスキーマを書きません; 構文検証のみを行います。
JSON5とJSONC、緩いスーパーセット
JSON5はjson5.orgで指定されたJSONの正式なスーパーセットで、もともと2012年にAseem Kishoreによって設計され、現在はJordan Tuckerによってメンテナンスされています。厳格なJSONが禁止するすべてを許可します: コメント(//と/* */の両方)、トレイリングカンマ、シングルクォート文字列、引用符なしのオブジェクトキー(それらが有効なECMAScript識別子の場合)、16進数、先頭/末尾の小数点(.5または5.)、InfinityとNaN、および符号付きの数値。JSON5ドキュメントは通常.json5拡張子を使用し、json5 npmパッケージのようなライブラリで解析されます。JSONCは、VS Codeの設定ファイル(settings.json、launch.json、tasks.json)で使用されるMicrosoftの非公式の「コメント付きJSON」モードです。コメントは仕様で許可されます; トレイリングカンマは参照パーサーで許容されますが警告が表示されます。緩い形式は厳格なJSONの規律が邪魔になる人間が編集する設定ファイル向けです; マシン間のデータ交換には、厳格なJSONが依然として正しい選択です。このツールはブラウザの厳格なJSON.parseを使用するため、両方を拒否します、貼り付ける前にコメントとトレイリングカンマを取り除くか、JSON5/JSONCパーサーを使用して最初に厳格なJSONに変換してください。
非常に大きな入力のためのストリーミングバリデーター
ブラウザのJSON.parseはドキュメント全体を単一のオブジェクトツリーとしてメモリにロードします。ほとんどの入力に対してこれは問題ありません; ログファイル、マルチギガバイトのAPIエクスポート、またはセンサーデータダンプの場合は、そうではありません。ストリーミングアプローチは、ドキュメントをトークンストリームとして消費し、構造全体を一度にメモリに保持することなくイベント(「配列開始」、「文字列値」、「オブジェクトキー」)を発行することです。clarinetはMarak Squiresによる標準的なNode.jsストリーミングJSONパーサーで、SAX XMLパーサーパターンをモデルにしています。Oboe.jsはJim Higsonによるブラウザフレンドリーな同等品(2013年の彼の論文から起源)で、fetch経由でJSONをストリーミング中に消費し、一致したJSONPathごとにイベントを発行するように設計されています; もはや積極的にメンテナンスされていませんが、それが先駆けた技術はまだ便利です。JSONStreamはnpmでパイプフレンドリーなNode使用のためにclarinetをラップしています。このような純粋ブラウザツールは利用可能なメモリで制限されます; ギガバイト規模のJSONを検証する場合は、Nodeでストリーミングパーサーを実行するか、コマンドラインでjq --streamを使用してください。
実際のワークフローでJSON検証が重要な場所
設定ファイルは最高のレバレッジケースです: tsconfig.json、package.json、ESLintとPrettier configs、Docker Compose、AWS IAMポリシー。単一の無効な文字がビルドを壊す可能性があります; 構文バリデーターはビルドが行う前にそれを捕まえます。APIレスポンスが次です: 外部APIに対する開発はしばしばペイロードを見つめて「これは実際に有効なJSONか?」と尋ねることを意味し、コードのより深いところでパースバグを追いかける前にです。Webhookペイロード、Stripeイベント、GitHub Actionsトリガー、Slack incoming webhooks、はJSONです; 迅速な貼り付けと検証は、不正な署名または迷子のバイトが本文を破損したケースを捕まえます。ログエントリー(Splunk、Datadog、Loki構造化ログ)は行区切りJSONです; 1つの悪い行が摂取パイプライン全体を壊します。生成されたJSONファイル(lockfile、ビルドマニフェスト、テストフィクスチャ)は、通常の開発中にノイズの多い方法で漂流することがあります; 構文バリデーターは生成ステップ自体が失敗したケースを捕まえます。
構文のみのバリデーターの正直な限界
構文バリデーターは論理エラーをキャッチできません。「電話番号」フィールドが文字列ではなく整数を含んでいることを伝えることはできません; 「日付」文字列が不正な形式だがたまたま有効な文字列であること; 必須フィールドが欠けていること; 正である必要のある数値が負であること; 一致すべき2つのフィールドが一致しないこと。これらはすべてスキーマ検証の問題です。本番システムの正しいパイプラインは: (1) 最初のゲートとしての構文検証、これはJSONとして解析しますか? (2) 2番目のゲートとしてのスキーマ検証、期待する形を持っていますか? (3) 3番目のゲートとしてのビジネスロジック検証、データは他の状態を考慮して意味をなしますか?3つのレイヤーすべてにツールが存在します; これは最初のみを処理します。最初に構文バリデーターにペイロードを貼り付ける利点は、最も安価で最も一般的な失敗モード(迷子のカンマ、欠けているブレース)を、それ以外ではそれらを溺れさせるより高価なスキーマエラーから分離することです。
プライバシー: なぜブラウザのみがここで重要なのか
サーバー上のJSON検証はドキュメントをアップロードする必要があります。通常の公開データの例では、これは無害です。認証トークン、顧客PII、内部従業員記録、構成秘密、または未リリースの製品データを含むAPIレスポンスの場合は、そうではありません。最も慎重な削除ポリシーでも、アップロードはサーバーログ、おそらくCDNキャッシュ、おそらく分析パイプライン、おそらくバックアップに残ります。このツールはJavaScript経由でブラウザでJSON.parseを実行します。貼り付けられたドキュメントは決してネットワークを越えません、ボタンをクリックする間にDevToolsのネットワークタブで検証するか、ロード後にページをオフラインに(機内モードに)してバリデーターがまだ機能することを確認してください。秘密を持つwebhookペイロード、認証ヘッダーを持つAPIレスポンス、データベース資格情報を持つ設定ファイル、または見知らぬ人のハードドライブにコピーされたくない他のJSONを検証するのに安全です。
よくある質問
有効なJSONとは?
有効なJSONは次のいずれかの型でなければなりません: オブジェクト({})、配列([])、文字列("")、数値、ブール値(true/false)、またはnull。すべての文字列とオブジェクトのキーは二重引用符を使用する必要があります。数値は先頭にゼロを付けることができません。要素間のスペースは許可されています。
「一般的な問題を修正」は何をしますか?
修正は一般的なエラーを自動的に修正しようとします: 末尾のコンマ、一重引用符を二重引用符に変換、引用符のないキー、undefined値をnullに変換。これはヒューリスティックなツールであり、すべてを修正できるとは限りません, 結果を慎重に確認してください。
アプリケーションでJSONを検証するには?
JavaScript: JSON.parse()を使用してエラーをキャッチします。Node.js: fs.readFileSync() + JSON.parse()。Python: json.loads()またはjson.load()。ほとんどの言語に組み込みのJSONライブラリがあります。
JSON5またはJSONC(コメント付きJSON)を検証できますか?
直接はできません。このツールはブラウザの厳格なJSON.parseを使用し、RFC 8259に従います、コメント、トレイリングカンマ、シングルクォート、引用符なしのキーは構文エラーです。入力がJSON5(json5.org、Aseem Kishore 2012、Jordan Tuckerによって維持)またはVS CodeのJSONCの場合、json5 npmパッケージまたはjsonc-parserパッケージをインストールし、厳格なJSONに変換し、その後検証してください。「一般的な問題を修正」パスは違いのサブセットを処理しますが、完全なJSON5 / JSONCパーサーではありません。
サイズ制限はありますか?
ハードリミットはありませんが、ブラウザのJSON.parseはドキュメント全体を単一のオブジェクトツリーとしてメモリにロードします。何万行も快適に動作します; マルチギガバイトのログダンプはメモリを使い果たします。非常に大きなJSONには、clarinet(Marak Squires)またはOboe.js(Jim Higson、2013)のようなストリーミングパーサーを実行するか、コマンドラインでjq --streamを使用してください。これは全体をロードすることなく任意のサイズのドキュメントを処理できます。
私のJSONドキュメントはアップロードされますか?
いいえ。JSON.parseはJavaScript経由でブラウザで実行されます。貼り付けられたドキュメントは決してネットワークを越えません、Validateをクリックする間にDevToolsのネットワークタブで検証するか、ロード後にページをオフラインにしてツールがまだ機能することを確認してください。秘密を持つwebhookペイロード、認証ヘッダーを持つAPIレスポンス、またはデータベース資格情報を持つ設定ファイルの検証に安全です。