URLエンコーダー・デコーダー

URLの構造は、特定の文字 — パスセグメントを区切る`/`、クエリ文字列を導入する`?`、パラメータを区切る`&`、フラグメントの`#` — がどこに現れても固定の構造的意味を持つことに依存しています。検索語やユーザー名のような、URLの中に置かれる値が、文字通りそれらの文字の1つを含んでいる場合、「このアンパサンドは実際の値の一部だ」と「このアンパサンドは2つのクエリパラメータを区切っている」を区別する何らかの方法が必要です。パーセントエンコーディングはその仕組みです: 構造的な意味を持つ文字が、構造としてではなくリテラルデータとして現れる必要があるとき、`%`とその16進数バイト値に置き換えられます。そのため`&`は`%26`になり、パラメータの区切り文字ではなくデータとして曖昧さなく読まれます。

最もよくあるURLエンコードのミスは、間違いなく、組み立てられた完全なURLを間違った関数でエンコードすることです — 個々の単一の値ではなく完全なアドレスに対して、`/`、`:`、`&`、`?`を含むすべての予約文字をエスケープする`encodeURIComponent`を使うことです。プロトコル後の`://`は`%3A%2F%2F`になり、クエリパラメータを区切る各`&`は`%26`になり、URLはもはやURLではなくなります — サーバーが解析できる構造を一切持たない長いエンコード文字列になってしまいます。正しいアプローチは逆順です: まず個々の値 — 検索語、リダイレクト先、実際のデータが何であれ — を個別にエンコードし、それからそのすでにエンコードされた値を周囲のURL構造に挿入します。組み立てられた全体を後で決してもう一度エンコードしないでください。

これがまさに、このツールが汎用の「エンコード」ボタン1つではなく2つの別々のモードを提供する理由です: URLの一部になろうとしている単一の値をエンコードするためのコンポーネントモードと、構造的な文字を意図的に保持しながらアドレス全体をエンコードするより珍しいケースのための完全URLモードです。

スペースのための2つの異なるエンコーディング慣習が今日も現役で使われており、交換可能ではありません。パーセントエンコーディング、汎用の標準は、スペースを`%20`として表現し、URLのどこでも有効です — パス、クエリ文字列、どこでもです。スペースのための`+`慣習は、`application/x-www-form-urlencoded`コンテンツタイプを使うHTMLフォーム送信専用に、より古く限定された標準に由来し、クエリ文字列の中だけで有効です。URLパスに現れるリテラルの`+`はスペースとしてまったく解釈されず、単にプラス記号の文字です。このツールは常にどんな文脈でも有効な`%20`を生成し、エンコードされたURLを読み戻す際は両方の形式を正しくデコードします。

パーセントエンコーディングのルールは、何がそれを構築・消費するかにかかわらずどんなURLにも適用されます — バックエンドサービスが構築するWebhookペイロード、モバイルアプリが開くディープリンク、スクリプトが組み立てるAPIリクエストなどです。スペース、アンパサンド、非ASCII文字を含みうる値がURL文字列に補間されるところならどこでも同じルール — 値を挿入する前にエンコードする — が適用されるため、これはブラウザだけでなくバックエンドとスクリプティングの両方の関心事です。