🧰 UtlKit

文字列エスケープツール:25 文字の入力が JS・HTML・URL の 3 転義で 27・45・45 文字になるまで、JS 9 種・HTML 5 種・パーセントエンコード モードと往復ルールを解説

アンパサンド・引用符・角括弧を含む 25 文字の文字列を貼り付けると、ツールは JS エスケープ後 27 文字・HTML エスケープ後 45 文字・URL エスケープ後 45 文字を返し、6 モードと往復の逆変換を提供します。すべてブラウザ内です。

文字列はシステムをまたぐときに壊れやすい。JavaScript 文字列の中の二重引用符、HTML 属性の中の &、クエリパラメータの中の空白:それぞれに危険な文字と、それを無害化する独自のやり方がある。エスケープ/アンエスケープツールは、貼り付けた文字列をその目的地向けに安全な形へ変換し、逆方向へも戻せる。すべてブラウザ内で完結し、何もアップロードされず、タブの外へ出ない。6 つのモードは 3 つのターゲット × 2 つの方向:Escape JavaScript、Unescape JavaScript、Escape HTML、Unescape HTML、Escape URL、Unescape URL。25 文字の入力を 1 つ取ると、& とコロンの入った挨拶と、角括弧で囲まれた引用フレーズ。HTML エスケープ後は 45 文字、URL エスケープ後も 45 文字、そしてその 2 つの 45 文字の結果は別の文字列である。そこが肝心だ。

6 つのモード:3 ターゲット × 2 方向

JavaScript モードは 128 の ASCII コードのうち 9 つを 2 文字のシーケンスへ書き換える:バックスラッシュ、二重引用符、単一引用符、改行、復帰、タブ、バックスペース、フォームフィード、NUL。25 文字の例に対して変化するのは 2 つの二重引用符だけで、& と角括弧はそのまま残り、出力は 27 文字になる。実際のタブと改行を含む文字列は、その位置に字面のバックスラッシュ t とバックスラッシュ n を得て戻る。HTML モードは正確に 5 文字を変換する:& は 5 文字の参照に、角括弧の 2 つは 4 文字の参照に、二重引用符は 6 文字の参照に、単一引用符は数値参照に。URL モードはパーセントエンコーディング。各エスケープにアンエスケープの対があり、全変換は貼り付けの時点で実行され、サーバーへの往復は無い。

25 文字の例、3 つの行き先

例を書き出すと、挨拶、&、コロン、そして角括弧で囲まれた引用フレーズ、合計 25 文字。JavaScript エスケープは 2 つの二重引用符の前にそれぞれバックスラッシュを 1 つ付け、合計 27 文字。HTML エスケープは唯一の & を 5 文字の参照に、2 つの二重引用符を 6 文字の参照に、角括弧の対を 4 文字の参照へ置き換える:25 に 20 を足して 45。URL エスケープは 4 つの空白、&、コロン、2 つの二重引用符、2 つの角括弧、すなわち 10 個の 1 文字を 10 個の 3 文字パーセントシーケンスへ変え、これも 45 に着地する。この入力の偶然の一致だ。3 つの行き先に 3 つの答え。入力はそのままその場で変えられず、ツールは常に新しい文字列を出力欄へ書き出す。

URL エスケープ:パーセントエンコードが残すもの

encodeURIComponent は 96 の印刷可能 ASCII 文字のうち 71 をそのまま残す。62 の文字と数字、それに 9 つの記号、すなわち感嘆符、単一引用符、丸括弧 2 つ、アスタリスク、ピリオド、ハイフン、アンダースコア、チルダである。残りはすべてパーセント記号 + 16 進 2 文字になる。だからこそこれはコンポーネントレベルのエンコーダであり、URL エンコーダではない。クエリ文字列付きの 53 文字の完全なアドレスに対して実行すると、スラッシュ、コロン、質問符、等号がすべて %2F、%3A、%3F、%3D になり、75 文字のコンポーネント https%3A%2F%2Futlkit.com%2Ftools%2Fstring-escape%2F%3Fq%3DTom%20%26%20Jerry ができる。URL の一部分か URL 全体か、どちらをエンコードするかの問題は、URLエンコーダ/デコーダが明示的に分ける。逆向きは decodeURIComponent であり、%E0 のような不完全なシーケンスにはエラーを投げる。ツールはそれを捕捉し、半解码の文字列ではなくエラーメッセージを表示する。

行き先でモードを選ぶ

ルールは行き先優先。JavaScript パーサに読ませるコードには JavaScript エスケープ、マークアップとして解析されるテキストや属性値には HTML エスケープ、クエリパラメータには URL エスケープ。近隣ツールが端をカバーする:HTMLエンティティ エンコーダ/デコーダは命名参照と数値参照を扱い、ノンブレークスペースは  、省略記号は … になる。二進制的なペイロードは Base64 エンコーダ/デコーダがテキストチャネルから完全に持ち出す。問題が「どう引用するか」ではなく「バイトが何か」のときは、Hex/UTF-8/Base64変換が同じバイトを 16 進・UTF-8 テキスト・Base64 の 3 形で示す。

エスケープ済み文字列とツール群の接点

エスケープは滅多に孤立して起こらない。エスケープ後の出力が JSON ペイロードに入る場合、JSON フォーマッタに貼り付ければ、きれいにパースされるか、壊した正確な文字を指し示すかのどちらか。入力が見えない文字で一杯のクリップボードから来た場合、空白クリーナーがエスケープの判断の前にタブと改行を可視化するので、出力のバックスラッシュ t は自分が送ったタブであり、意外なものではない。

往復と二重エスケープの罠

ツールの各エスケープには、同じ 128 コード表を逆向きに辿る逆関数がある:JavaScript エスケープの後に JavaScript アンエスケープすると元の文字列がそのまま戻り、URL のペアも 16 進ペアを含めて往復する。一方通行は二重エスケープだ。HTML エスケープを 2 回回すと、参照内部の & 自身もエスケープされ、結果は参照が指す文字ではなく参照の見えるテキストとしてレンダリングされる。戻すには 1 回ではなく 2 回のアンエスケープが要る。失敗モードはエスケープそのものではなく、2 回適用すること、または誤ったモードで 1 回適用することだ。文字列の問題が文字ではなく構造にあるとき、エスケープツールは正しくない器具だ。HTMLフォーマットガイドが同じ文書のフォーマット側を扱う。

関連ツール

よくある質問

HTML エスケープモードはなぜ他の文字より先に & を変換するのか?

このモードが書き出す 5 つの参照 &、<、>、"、' はすべて & で始まるため。1 回のパスで & を先に置換すると、あとから書かれる 4 つの参照に内蔵された & はスキャンされず、25 文字の例はちょうど 20 だけ増えて 45 に着地する。順序を変えると、参照の & がその場で二重エスケープされ、同じ入力の出力は 45 よりずっと長くなる。

JS エスケープが 25 文字の例で変えたのは 2 つの二重引用符だけ。壊れているのか?

壊れていない。JS エスケープは 128 の ASCII コードのうち 9 つだけを書き換える:バックスラッシュ、二重引用符、単一引用符、改行、復帰、タブ、バックスペース、フォームフィード、NUL。& と角括弧は JavaScript 文字列の中で完全に合法なのでそのまま通り、出力は 27 文字、入力のまま 2 つのバックスラッシュが増えただけ。同じ入力を HTML エスケープに回すと 45 に届くのは、その行き先では & と 2 つの角括弧が危険な文字だからだ。何が危険かを決定するのはモードである。

URL エスケープモードが私の完全なアドレスのスラッシュと疑問符をエンコードした。それは間違いか?

誤りではないが、このモードはコンポーネントレベルのエンコーダであり、URL エンコーダではない。encodeURIComponent は 96 の印刷可能 ASCII 文字のうち 71 をそのまま残し、スラッシュ、コロン、質問符、等号を含むすべてをエンコードするので、クエリ文字列付きの 53 文字の完全なアドレスは 75 文字のコンポーネント https%3A%2F%2Futlkit.com%2Ftools%2Fstring-escape%2F%3Fq%3DTom%20%26%20Jerry になる。構造をそのままに URL 全体を 1 つの単体として扱いたいなら、URLエンコーダ/デコーダがその分割を明示する。逆向きでは、decodeURIComponent は %E0 のような不完全なパーセントシーケンスで例外を投げ、ツールは半解読の文字列ではなくエラーを表示する。

エスケープの後にアンエスケープすれば、元の文字列が必ず戻るのか?

一度もエスケープされていない入力なら、戻る。JS エスケープの後に JS アンエスケープは同じ 128 コード表を往復し、入力をそのまま返す。URL のペアも往復する。16 進ペアも含めてだ。失敗は別の 2 つの方向から来る。1 つは二重エスケープ:HTML エスケープを 2 回回すと、2 回目のパスが 1 回目で書き出した参照の中の & もエスケープするので、戻すのにアンエスケープが 2 回必要なこともある。もう 1 つは、エスケープされたことの無いデータをアンエスケープすること:合法なシーケンスを構成しないパーセント記号 + 2 文字の 16 進、例えば不完全な %E0 に入ると decodeURIComponent は例外を投げ、ツールは半解読の文字列ではなくエラーを表示する。

なぜ 25 文字の例が HTML エスケープでも URL エスケープでも 45 に着地するのか?

別の 2 つの足し算、同じ着地点。HTML エスケープは唯一の & に 4 を足し、2 つの二重引用符に各 5 を、2 つの角括弧に各 3 を足す:25 に 20 を加えて 45。URL エスケープは 4 つの空白、&、コロン、2 つの二重引用符、2 つの角括弧、すなわち 10 個の 1 文字を 10 個の 3 文字パーセントシーケンスへ変える、これも 25 に 20、これも 45。一致はこの特定の入力の偶然であり、2 つの 45 文字の出力は別の文字列だ:一方は & 参照でいっぱい、もう一方はパーセント 3 文字組でいっぱい。各行き先が自分の危険な文字を数え、たまたま同じ合計を請求したのだ。

関連記事