JSONエスケープ解除
JSONアンエスケープは、文字列のエスケープを逆方向に変換します。\"を引用符へ、\nを改行へ、\uXXXXを対応する文字へ戻し、別のドキュメントの中に埋め込まれていたドキュメントを復元します。ログ行からコピーしてきた断片は、たいてい外側の引用符が欠けた状態で届きますが、そうした断片には意図的に寛容です。
JSONエスケープ解除はどう動きますか？
このツールにたどり着くのは、ほとんどの場合ログファイル経由です。何かがリクエストボディをログ出力する際、JSONドキュメント全体を1つの文字列フィールドに押し込んだため、目の前には引用符のあるべき場所に\"がぎっしり並び、改行の代わりに\nが現れ、Windowsパスが出てくるたびに\\が付く、1行の密なテキストがあります。技術的には読めたとしても、実用上は読めたものではありません。
アンエスケープはエスケープの逆操作で、仕組みは単純です。テキストを走査し、バックスラッシュを見つけるたびにその後ろの1文字を消費して、その組が表すものを出力します。判断が要るのは、ほぼ常に不完全な入力をどう扱うかという点だけです。
厳格なJSONパーサーなら、ここに貼り付けられるものの大半を拒否するでしょう。断片はたいてい、興味のある部分だけを選んでコピーしたせいで、前後の引用符を失っています。ログフィールドの長さ制限で途中までしか残っていないこともあります。まったく有効なJSONエスケープではないバックスラッシュを含むこともあります——生成元が別のターゲット向けにエスケープしていたからです。これらをすべて拒否するパーサは正しいのですが、役に立ちません。
だからこのツールは意図的に寛容です。外側の引用符がなくても問題ありません。必須条件にする代わりに、その旨を報告します。\qのような未知のエスケープは2文字ともそのまま残し、警告を出します。末尾のバックスラッシュは保持します。途中で切れた\uシーケンスは書かれたままにします。どの場合でも、ドキュメントの残りの部分は復元されます。部分的にでも復元されたペイロードは、エラーメッセージよりはるかに役立つからです。
Unicodeはきちんと扱われます。\uXXXXエスケープは対応する文字になり、上位サロゲートの後に下位サロゲートが続く組は、2つで表される1文字に再結合されます——この工程がなければ、すべての絵文字も、より珍しいCJKの字形も、2つの置換ボックスとして出力されてしまいます。
アンエスケープが終わると、結果を検査します。有効なJSONであれば整形して表示します。ほとんどの場合、それこそが本当に欲しかったものです。有効でなければ、パースエラーとともにプレーンテキストとして表示します。ドキュメントがログの中で途中までしか記録されていなかったのか、ログに届く前から壊れていたのかを確認できます。
エスケープ済み文字列
"{\"name\":\"Ada\",\"note\":\"line one\nline two\"}"復元されたドキュメント
{
"name": "Ada",
"note": "line one
line two"
}JSONエスケープ解除が対応するオプションとエッジケースは？
| パラメータ | 型 | デフォルト | 動作とエッジケース |
|---|---|---|---|
| \" \\ \/ | エスケープ | — | 引用符、バックスラッシュ、スラッシュです。スラッシュのエスケープはJSONでは合法ですが任意なので、ある生成ツールの出力には含まれ、別のものには含まれないことがあります。 |
| \n \r \t \b \f | エスケープ | — | 名前付き制御文字です。\nは、文字の壁と読みやすい文書の違いを作るものです。 |
| \uXXXX | エスケープ | — | UTF-16コード単位です。高いサロゲートが低いサロゲートに続くと、それがエンコードする単一の文字に再結合されます；そのない場合、すべての絵文字と多くのCJK文字は壊れたボックスとして2つ返されます。 |
| 引用符の有無 | 任意 | 存在すれば削除 | ログ行から貼り付けられた断片は通常、それらを失っています。それらがあったかどうかは必須ではなく報告されます。 |
| 未知のエスケープ | 保持 + 警告 | — | \qや同様のものは両方の文字を保持します。厳密なパーサーは全体のドキュメントを拒否します；続行すると、あなたが求めていた残りが復元されます。 |
| 単独のサロゲート | 保持 + 警告 | — | 低い半分がない高いサロゲートは文字を形成できません。ソースが文字の途中で切り捨てられたことを意味することが多いため、保持され、フラグが立てられます。 |
| 整形 | 真偽値 | true | 復元されたテキストが有効なJSONの場合、再インデントします。無効な場合、生のテキストがパースエラーとともに表示され、これは切り捨てられたログフィールドと既に壊れていたドキュメントを区別します。 |
よくある質問
ログ行が二重にエスケープされています。2回実行すればいいですか？
はい。二重エスケープは、すでにエスケープ済みの文字列がさらにエスケープされたときに起こります。ペイロードが文字列としてログに記録され、今度はそのログ行がアグリゲータによって文字列として記録される、という具合です。\"があるべき場所に\\\"が見えるはずです。出力をもう一度このツールに通せば、2層目が剥がれます。1回通しても見た目が変わらなければ、底に到達しています。
結果がまだ有効なJSONにならないのはなぜですか？
多くの場合、途切れが原因です。ログフィールドには長さ制限があるため、ドキュメントは文字列の途中やオブジェクトの途中で切られていることが多く、忠実にアンエスケープすると、本当に不完全なためにパースできないものが手に入ります。パースエラーは停止位置の行と桁を示しますが、通常それはちょうど途切れた地点です。
絵文字はどうなりましたか？
正しく表示されていれば、サロゲートペアは正しく再結合されています。代わりに2つのボックスが表示されるなら、そのツールは\uXXXXの片方ずつを独立にデコードしたということです。基本多言語面（BMP）の外にある文字は2つのコードユニットで符号化されており、結合しなければなりません。このツールは結合を行い、片方だけ見つかったときは警告を出します。それは途切れの兆候です。
JSONではないテキストを貼り付けてもいいですか？
はい。アンエスケープはテキスト処理なので、エスケープされたSQL文、HTMLの断片、シェルコマンドも問題なく処理できます。結果が有効なJSONではないと報告し、整形せずにプレーンテキストとして表示するだけです。
貼り付けたログ行はどこかに送信されますか？
いいえ。アンエスケープはブラウザ内で動作します。これは、ほとんどのツールよりも重要な点です。人々がアンエスケープするログ行には、トークン、セッション識別子、顧客レコードを含む本番環境のリクエストボディがよく現れます。サーバーサイドのツールに貼り付けると、その内容は2つ目のアクセスログにコピーされてしまいます。
アンエスケープで文字そのものが変わりますか？それとも書き方だけですか？
書き方だけです。\u00e9とéは同じ1文字の2つの表記であり、アンエスケープは表記を書き換えます——出てくるのは、エスケープ形式が符号化していたテキストそのものです。出力が入力と同じに見えることがあるのはそのためです。エスケープが1つも含まれていないログ行には、変えるものが何もありません。