JSONのエスケープ／アンエスケープ

仕組み

1. 文字列を貼り付け: エスケープするテキストを入力します, 引用符、改行、バックスラッシュ、その他の特殊文字を含むプレーンテキストです。
2. エスケープまたはアンエスケープを選択: JSONに埋め込むためにテキストをエスケープするか、JSON文字列を読み取り可能なテキストにアンエスケープするかを選択します。
3. 結果をコピー: エスケープまたはアンエスケープされた出力が瞬時に表示されます。コードまたはデータで使用するためにコピーします。

なぜJSONエスケープを使うのか?

JSON文字列には厳しいエスケープルールがあります, 二重引用符は\"、改行は\n、バックスラッシュは\\、タブは\tになる必要があります。これらの文字を正しくエスケープしないと、API、設定ファイル、データパイプラインを壊すJSON解析エラーが発生します。このツールはすべてのエスケープとアンエスケープを自動的に処理し、手動の検索置換を排除し、エスケープシーケンスの見落としによる微妙なバグを回避します。

機能

• 完全なエスケープカバレッジ: 引用符、バックスラッシュ、改行、タブ、キャリッジリターン、Unicodeエスケープシーケンスを処理します。
• 双方向: 1つのツールでエスケープ(テキスト → JSON文字列)とアンエスケープ(JSON文字列 → テキスト)の両方。
• 瞬時の結果: 入力するにつれて出力が更新され、遅延はありません。
• クリップボードにコピー: エスケープまたはアンエスケープされた結果のワンクリックコピー。
• プライバシー第一: すべての処理はローカルで行われます, 機密文字列がデバイスを離れることはありません。

よくある質問

JSONエスケープが処理する文字は?

JSONはエスケープを必要とします: 二重引用符(")、バックスラッシュ(\)、スラッシュ(/)、改行(\n)、キャリッジリターン(\r)、タブ(\t)、フォームフィード(\f)、バックスペース(\b)、U+FFFFを超えるUnicode文字。このツールはすべてを処理します。

なぜJSON解析エラーがエスケープに関連しているのですか?

一般的な原因には、文字列値内のエスケープされていない二重引用符、文字列内のリテラル改行(\nである必要がある)、エスケープされていないバックスラッシュが含まれます。壊れた文字列をここに貼り付けて適切にエスケープしてください。

周囲の引用符は含まれますか?

デフォルトでは、ツールは囲み引用符なしでコンテンツをエスケープし、結果をJSON文字列に貼り付けることができます。出力を二重引用符で囲みたい場合は、「引用符を含める」オプションを有効にします。

JSON 文字列仕様を 1 つの表で

RFC 8259(2017 年 12 月、Tim Bray による)は現在の JSON 標準であり、RFC 7159 と元の RFC 4627 を置き換えています。仕様のセクション 7 は、文字列リテラル内でエスケープする必要がある文字を正確にリストアップしています:

同等の規則は ECMA-404(第 2 版、2017 年 12 月)にあり、IETF 仕様と同期して保持されています。JSON には 8 進数(\012)や 16 進数(\x41)のエスケープはありません、それらは JavaScript のみ;JSON は上記の 8 つの名前付きエスケープと \uXXXX のみをサポートします。

\uXXXX エスケープとサロゲートペアの罠

JSON の \uXXXX シーケンスは UTF-16 コードユニットをエンコードします、Unicode コードポイントではありません。これは絵文字と補助プレーン文字にとって重要です。😀(U+1F600)のような単一の絵文字は \u1F600(これは合法な 4 桁 16 進数の形式でさえありません)ではなく、サロゲートペアとしてエスケープされます:\uD83D\uDE00、高位と低位のサロゲートをエンコードする 2 つの連続したエスケープ。高サロゲートの範囲は U+D800–U+DBFF;低サロゲートの範囲は U+DC00–U+DFFF;一緒に U+10000 から U+10FFFF(補助プレーン)をカバーします。

これはエスケープされた絵文字バグの最も一般的な原因です。RFC 8259 セクション 7 は明示的に述べています:「基本多言語面にない拡張文字をエスケープするには、文字は UTF-16 サロゲートペアをエンコードする 12 文字のシーケンスとして表されます。」👨‍👩‍👧‍👦 のような家族 4 人の絵文字は、技術的には 4 つの基本絵文字と 3 つのゼロ幅結合子で、JSON 文字列で 30+ 文字としてエスケープされます。バイト数はそれに応じて膨らみます:生の UTF-8 25 バイト、JSON エスケープ後 ~58 バイト。

HTML、URL、SQL、CSV 内の JSON

JSON エスケープだけでは、JSON が別の形式に埋め込まれている場合には不十分です。各コンテキストは独自のレイヤーを追加します。

HTML 内の JSON。古典的な罠は、ペイロードに </script> という文字列リテラルが含まれているときの <script>const data = {{ payload | json }};</script> です。HTML パーサーは文字列の途中でスクリプトタグを閉じ、JSON の残りはページ上に可視テキストとしてレンダリングされます。修正はオプションの \/ エスケープです:<\/script> は JSON 有効かつ HTML 安全です。OWASP のクロスサイトスクリプティングのチートシートは、HTML 埋め込み用の JSON で常に <、>、&、' をエスケープすることを推奨しています。

URL クエリ文字列内の JSON。2 つのレイヤー:まず JSON エスケープ、次にパーセントエンコーディング。{"name":"Bob"} は %7B%22name%22%3A%22Bob%22%7D になります。パーセントエンコーディングを忘れることが、不正な JSON-in-URL バグの第 1 位の原因です。

SQL 内の JSON。PostgreSQL jsonb カラムに保存された値はネイティブで解析され、それ以上のエスケープは不要です。しかし SQL 文字列リテラルに埋め込まれた JSON(INSERT INTO t (data) VALUES ('{"key":"value"}'))は JSON に加えて SQL 文字列エスケープが必要です:シングルクォートを 2 つにする('')、またはより良いのは、パラメータ化クエリを使う。

CSV セル内の JSON。CSV のクォートは JSON とは異なります(CSV は二重化されたクォート "" を使い、バックスラッシュシーケンスではありません)。CSV セルに JSON を埋め込むには両方のレイヤーが必要:文字列を JSON エスケープし、結果を CSV エスケープする("..." で囲み、内部の任意の " を 2 倍にする)。

言語をまたがるランタイム API

JSON の出自と、Crockford が省いたもの

JSON は最初、Douglas Crockford によって 2001 年に State Software で形式化されました、もともと非同期データ交換のために JavaScript オブジェクトをシリアライズするためでした。最初の公開言及は 2003 年の JSON.org サイトでした。Crockford は 2006 年 7 月に RFC 4627 として正式に指定しました、部分的には同時期に競合する特許試みに対抗するためでした。標準は 2017 年 12 月の RFC 8259 で STD 90 ステータスに移行しました。

JSON の最大の設計決定は、JavaScript のサブセットにすることでした、つまり任意の JSON ドキュメントは JS インタプリタで eval'd でき、正しい値を生み出します。これによりブラウザでの採用は摩擦なく進みましたが、いくつかの JS の癖を永続的に固定しました:整数型なし(すべての数値は IEEE 754 double)、日付型なし、NaN や Infinity なし。2⁵³−1 を超える大きな整数は、サイレント精度損失を避けるために文字列シリアライズ("id": "9007199254740993")が必要です。

Crockford は意図的に、あなたが恋しく思うかもしれないものを省略しました:コメント(「JSON からコメントを削除しました、なぜなら人々がそれを使ってパースディレクティブを保持しているのを見たからです、これは相互運用性を破壊する可能性がありました」、2012 年 5 月)、末尾のカンマ、およびスキーマ言語(後で JSON Schema として追加され、別々に維持され、現在のドラフト 2020-12)。コミュニティバリアントの JSON5 はコメントと末尾のカンマを復元しますが、RFC 準拠ではありません;主に人間が編集する設定ファイル(.babelrc、.swcrc)で使用されます。

一般的なユースケース

• HTML 属性にデータを埋め込む、"、<、> を含む文字列を貼り付け、data-* 属性やインライン script タグに安全な形式を取得。
• API リクエストボディを手で作る、エンドポイントを curl していてペイロードに引用符や改行が含まれている時。
• ログ行ペイロードを構築する、メッセージが反対側でシェルクォーティングプラス JSON パースを生き残らなければならない場合。
• レガシーデータの移行、CSV / XML / TSV から JSON へ、手動の引用符エスケープパス。
• サーバーレスポンスのデバッグ、値が \u シーケンスを含む場所、それが実際に何であるかを見るためにアンエスケープします。
• テストを書く、期待される JSON 出力を貼り付け、テストアサーションに含めるためにエスケープします。
• テンプレートエンジン(Jinja2、Nunjucks、Liquid、ERB)が JavaScript または HTML に JSON を埋め込む。

よくある間違い

1. JSON 有効でない JavaScript エスケープを使う。「A」のための \x41 と改行のための \012 は JS 文字列リテラルでは有効ですが JSON では無効です。JSON は 8 つの名前付きエスケープと \uXXXX のみを許可します。
2. JSON 文字列にシングルクォートを使う。'hello' は JavaScript で動作しますが JSON 無効です。JSON 文字列はダブルクォートを使う必要があります。
3. クォートなしのオブジェクトキー。{name: "Bob"} は JavaScript で動作しますが JSON 無効です。キーはダブルクォート内の文字列リテラルである必要があります。
4. 末尾のカンマ。[1,2,3,] は JS で動作しますが JSON 無効です。RFC 8259 はそれらを明示的に禁止しています。
5. インラインコメント。// foo と /* foo */ は標準 JSON で無効です。コメントが必要な場合は JSON5 を使う;すべてのパーサーが受け入れるとは期待しない。
6. 単一の \uXXXX として絵文字を手動でエスケープする。U+FFFF を超える絵文字は UTF-16 サロゲートペア、連続した 2 つの \uXXXX エスケープが必要です。

その他のよくある質問

常にフォワードスラッシュ / をエスケープすべきですか?

いいえ、フォワードスラッシュ / は JSON でエスケープなしで許可されています;エスケープ \/ はオプションです。例外は JSON が HTML <script> タグ内に埋め込まれている場合:/ を \/ としてエスケープすると、リテラル部分文字列 </script> がタグを早期に閉じることを防ぎます。一部のエンコーダ(PHP の JSON_HEX_TAG、カスタム JS 置換)はこれを行います;ほとんどは行いません。

JSON.stringify が私の非 ASCII 文字をエスケープするのはなぜですか?

デフォルトではしません。JavaScript の JSON.stringify("café") はリテラル é を持つ "café" を生成します。あなたが見ているのは別のライブラリかもしれません:Python の json.dumps はデフォルトで ensure_ascii=True で、ASCII 外のすべてを \uXXXX としてエスケープします;PHP の json_encode も JSON_UNESCAPED_UNICODE を渡さない限り同様に動作します。両方の動作は有効な JSON ですが、ファイルサイズと可読性が異なります。

JSON はバイナリデータを保存できますか?

直接はできません。JSON 文字列は Unicode 文字のシーケンスで、バイトではありません。標準的な回避策はバイナリを最初に Base64 エンコードし、結果の ASCII 文字列を通常の JSON 値として保存することです。エンコードされたデータは生のバイトより ~33% 大きくなります。非常に大きなバイナリの場合は BSON、MessagePack、CBOR などのバイナリ形式を使う、またはバイトを別途保存して URL で参照します。

なぜ一部のツールは é の代わりに \u00e9 を表示するのですか?

両方とも同じ文字に対する有効な JSON です。"caf\u00e9" と "café" は同じ文字列にデコードされます。一部のエンコーダは最大のクロスエンコーディングの安全性のために非 ASCII をエスケープします(出力は純粋な ASCII なので消費者のエンコーディングは関係ありません)、他は可読性のために元の UTF-8 を保持します。JSON を消費するものに基づいて選択してください。

私のテキストはどこかにアップロードされますか?

いいえ。このツールはブラウザのネイティブ JSON.stringify と JSON.parse API を完全にクライアントサイドで使います。ネットワークコール、アナリティクス、ロギングはありません。API トークン、内部データ、またはサーバーサイドのエスケープツールに貼り付けたくないものをエスケープするのに安全です。