テキスト・URLエンコード・コンポーネントエンコードを自由に相互変換
URLコーデックの使い方は非常にシンプルです：
URLコーデックは、Web開発やAPI連携において以下のような場面で活用されています：
HTMLフォームから送信されるデータ（application/x-www-form-urlencoded）をエンコード・デコード。POST/GETパラメータの確認やデバッグに最適です。スペースは「+」に変換されます。
検索クエリやフィルタ条件をURLクエリパラメータとしてエンコード。日本語や特殊文字を含む検索キーワードをURL安全な形式に変換します。例：「東京タワー」→「%E6%9D%B1%E4%BA%AC%E3%82%BF%E3%83%AF%E3%83%BC」
REST APIのエンドポイントURLに含まれるパラメータをRFC 3986準拠の形式でエンコード。コンポーネントエンコードを使用すると、スペースは「%20」に変換され、スラッシュやコロンも保持されます。
ブラウザのアドレスバーやアクセスログに表示されたエンコード済みURLをデコードして、元の文字列を確認。エラー原因の特定やログ解析に役立ちます。
OAuth 2.0のredirect_uriやstateパラメータをエンコード・デコード。認証フロー内で送信されるURLパラメータの検証やデバッグに使用します。
URLエンコード（パーセントエンコーディング）は、URL内で使用できない文字や特殊文字を、「%」記号と16進数の組み合わせで表現する方式です。URLは本来ASCII文字のみを扱うため、日本語などの多バイト文字や特殊記号を送信する際に必要です。
HTMLフォーム送信時はフォームエンコードを、REST APIのURLパスやクエリパラメータにはコンポーネントエンコードを使用します。迷った場合は、コンポーネントエンコード（RFC 3986）を選択すれば大半のケースで正しく動作します。
はい、同じものです。URLエンコードは正式には「パーセントエンコーディング」と呼ばれ、「%」記号を使用して文字を表現するためこの名前が付いています。
主な違いはスペースの扱いです。フォームエンコード（application/x-www-form-urlencoded）ではスペースを「+」に変換しますが、コンポーネントエンコード（RFC 3986）では「%20」に変換します。また、エンコード対象の文字セットも若干異なります。
日本語などの多バイト文字は、UTF-8バイト列に変換された後、各バイトが「%XX」形式でエンコードされます。例えば「あ」は「%E3%81%82」（3バイト）になります。
英数字（A-Z, a-z, 0-9）、ハイフン（-）、アンダースコア（_）、ピリオド（.）、チルダ（~）以外のほとんどの文字がエンコードされます。スペース、スラッシュ（/）、コロン（:）、日本語などの非ASCII文字、特殊記号がエンコード対象です。
不正なエンコード形式（%の後に16進数2桁がない、無効なUTF-8バイト列など）の場合、デコードエラーが発生します。また、複数回エンコードされた文字列は、複数回デコードが必要な場合があります。
いいえ、URLエンコードは単なる文字列のエンコード（変換）であり、暗号化ではありません。エンコードされた文字列は簡単にデコード可能で、セキュリティ保護の目的では使用できません。
各言語に組み込み関数があります。JavaScript: encodeURIComponent()、Python: urllib.parse.quote()、PHP: rawurlencode()、Java: URLEncoder.encode()、Ruby: ERB::Util.url_encode()などが利用できます。
既にエンコードされた文字列を再度エンコードすることです。例えば「%20」を再エンコードすると「%2520」になります。意図しない二重エンコードはバグの原因になるため注意が必要です。
Base64エンコード・デコード
HTML特殊文字をエンコード・デコード
URLエンコード・デコード
エンコードされたURLを元に戻す
URLを安全な形式にエンコード