URL エンコード・デコードツール

URLエンコード（パーセントエンコーディングとも呼ばれる）は、文字をURLで安全に送信できる形式に変換する仕組みです。URLはASCII文字セットの特定の文字しか含められないため、それ以外の文字（日本語、スペース、特殊記号など）は%XX形式にエンコードする必要があります。XXは文字の16進数値です。 例：スペースは%20に、漢字「あ」は%E3%81%82にエンコードされます。

URLエンコーディング（パーセントエンコーディング）はRFC 3986 §2.1で定義されており、文字を%XX形式に変換します。XXはUTF-8におけるバイト値の2桁大文字16進数表現です。RFCは2つの文字クラスを定義しています：未予約文字（A-Z a-z 0-9 - _ . ~）は常にエンコードされず、予約文字（gen-delims : / ? # [ ] @ と sub-delims ! $ & ' ( ) * + , ; =）は文脈に応じてエンコードが変わります。予約文字はURLの一部では構造的な意味を持ちますが、データとして扱う場合はリテラルとして入力されます。 JavaScriptには2つのスコープが異なる組み込み関数があります。encodeURIComponent()はA-Z a-z 0-9 - _ . ! ~ * ' ( ) 以外のすべての文字をエンコードし、個別のクエリパラメータ値、パスセグメント、フラグメント識別子のエンコードに適しています。encodeURI()はさらに構造文字 : / ? # [ ] @ ! $ & ' ( ) * + , ; = を保持し、URI全体の構文構造を維持したままエンコードするために設計されています。重要な区別として、encodeURIComponent()は/と&をエンコードするためURL全体に適用すると構造が壊れるのに対し、encodeURI()はこれらを保持します。 スペース処理は最も一般的な相互運用性の落とし穴です。RFC 3986はスペース文字（U+0020）の正規のパーセントエンコーディングとして%20を指定しています。しかし、application/x-www-form-urlencoded MIMEタイプ（HTML 4.01以降のHTMLフォーム送信で使用）ではスペースを+としてエンコードします。この2つは互換性がありません：%20を期待するサーバーは+をリテラルとして解釈し、+を期待するサーバーは%20をパーセント記号に続く20として扱います。本ツールはRFC 3986に準拠する%20を生成するencodeURIComponent()を使用しています。x-www-form-urlencodedペイロード（POSTボディやレガシーミドルウェアがパースするクエリ文字列）をデコードするユーザーは、この違いを理解しておく必要があります。 マルチバイト文字の処理は自動的に行われますが、理解しておく価値があります。入力文字列はまずUTF-8バイトにエンコードされ、各バイトが個別にパーセントエンコードされます。CJK文字「你」（U+4F60）は3バイトのUTF-8（E4 BD A0）を占め、%E4%BD%A0を生成します。サーバーがGBKなどの異なる文字セットでパースすると、同じ文字は%C4%E3（2バイト）にエンコードされ、双方がUTF-8に同意していない限りデコード結果は文字化けします。二重エンコードも一般的なバグです：%2520はリテラルのパーセント記号（%25）に続く20を意味し、入力がすでにパーセントエンコードされていて2回目のエンコードが行われたことを示します。デコードモードでは不正なシーケンス（不完全な%XX）を検出し、サイレントにゴミを生成するのではなくエラーを表示します。

• encodeURIComponentとencodeURIの違い：encodeURIComponentは/ ? & #をエンコードし、クエリ値、パスセグメント、フラグメントに正しい選択です。encodeURIはこれらの構造文字を保持し、フルURLに正しい選択です。間違った関数を使用することは、URLエンコーディングで最も一般的なバグです。
• RFC 3986の予約文字セット：gen-delims（: / ? # [ ] @）はURL構文を持ち、sub-delims（! $ & ' ( ) * + , ; =）はURLコンポーネントによって区切り文字またはデータになります。文脈が予約文字をパーセントエンコードするかどうかを決定します。
• スペースエンコーディング：RFC 3986の正規形式は%20（encodeURIComponentが生成）、application/x-www-form-urlencodedは+（HTMLフォームのデフォルト）を使用します。この2つは意味的に互換性がなく、混在させるとサーバー側パーサーが壊れます。
• UTF-8マルチバイトエンコーディング：「你」（U+4F60）→ UTF-8バイト E4 BD A0 → %E4%BD%A0（3つのパーセントエンコードされたオクテット）。GBKでは同じ文字が%C4%E3（2オクテット）になります。非ASCIIテキストではクライアントとサーバーの文字セットの一致が必須です。
• 二重エンコードの検出：%2520は最初に%20にデコードされ、次にスペースにデコードされます。デコードモードの出力がこのパターンを明らかにします。%ZZや%2（不完全）のような不正なシーケンスは検出されてエラーとして報告されます。
• IRI（RFC 3987）：国際化リソース識別子はURLにUnicode文字を直接含めることを許可します。ブラウザはアドレスバーにデコードされた形式を表示しますが、ワイヤ上ではパーセントエンコードされたUTF-8形式で送信します。ツールのエンコードモードはHTTP上に実際に送信される内容を表示します。
• decodeURIComponentのエラー処理：不完全なパーセントシーケンス（%の後に2桁未満の16進数）を含む文字列を渡すとURIErrorがスローされます。ツールは呼び出しをtry/catchでラップし、サイレントに空文字列を返すのではなくエラーメッセージを表示します。