URLエンコード / デコード
URLに含まれる特殊文字をエンコード・デコードします。encodeURIComponent / decodeURIComponent を使用します。
使い方
- テキストを入力 — エンコードまたはデコードしたいテキストを入力欄に貼り付けます。日本語・特殊文字・絵文字も UTF-8 として正しく扱われます。
- エンコードを実行 — 「エンコード」ボタンで
encodeURIComponent相当の処理を実行。日本語・記号 (& = ? # 等)・スペースが%XX形式に変換されます。 - デコードで元に戻す — 「デコード」ボタンで
%XX形式を元の文字に復元。ブラウザのアドレスバーにあるエンコード済 URL の中身を読み解く際に活用。 - 入出力を入替 — 「入出力を入替」で結果を入力欄にコピー。エンコード → デコード → 確認のループを素早く繰り返せます。
- クリップボードにコピー — 「コピー」ボタンで変換結果をクリップボードに保存。URL クエリパラメータ・OAuth state・curl コマンド作成に即活用。
こんな場面で使えます
- クエリパラメータの生成 — 検索 URL (?q=日本語クエリ) の正しいエンコード確認
- OAuth / OIDC の redirect_uri — 認可エンドポイントに渡す URL のエンコード
- API リクエストのデバッグ — Postman / curl で送る URL の正確性検証
- エンコード済 URL の解読 — 取得した URL から元のパラメータ値を読み解く
- 多言語ファイル名の URL 化 — 日本語・中国語・絵文字を含むファイル名を URL に組み込む
よくある質問
URL エンコードとは何ですか？
URL エンコード (パーセントエンコーディング) は、URL に使用できない文字を %XX 形式 (例: 半角スペース → %20、& → %26、日本語の「あ」→ %E3%81%82) に変換する仕組みです。RFC 3986 が標準仕様で、日本語や記号を URL に含める際に必要です。
encodeURI と encodeURIComponent の違いは？
encodeURI は URL 全体を対象とし、スラッシュ / コロン / ハッシュ等の URL 構造文字はエンコードしません。encodeURIComponent はクエリパラメータの値など部分的なエンコードに使い、すべての非予約文字以外を変換します。本ツールは encodeURIComponent を使用しているため、クエリパラメータ値の生成に最適です。
日本語 URL は正しくエンコードされますか？
はい、日本語文字は UTF-8 でバイト列に変換された後、各バイトが %XX 形式にエンコードされます。例: 「日本」→ %E6%97%A5%E6%9C%AC。Shift_JIS でエンコードしたい場合は本ツールでは対応していないため、サーバー側のエンコード設定で対応してください。
URL の予約文字と非予約文字の違いは？
RFC 3986 は URL で使える文字を非予約文字 (A-Z a-z 0-9 - . _ ~) と予約文字 (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) に分けています。非予約文字は常にそのまま、予約文字は文脈 (パス・クエリ・ハッシュ) によって扱いが変わります。クエリパラメータ値では予約文字も全てエンコードすべきです。
+ はスペースを表しますか？
クエリ文字列内 (application/x-www-form-urlencoded) では + がスペースを表す慣例があります。一方 URL のパス部では + はリテラルの + として扱われます。本ツールは encodeURIComponent を使うため、スペースは %20 にエンコードされ、+ は %2B にエンコードされます。
日本語ファイル名の URL は？
日本語ファイル名 (例: レポート.pdf) を URL に含める場合は、各文字を UTF-8 → %XX 形式にエンコードします。本ツールでエンコードすると「%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88.pdf」のような形になります。Web サーバー側 (nginx/Apache) も UTF-8 対応で配信できる設定が必要。
OAuth の redirect_uri はどう扱う？
OAuth 2.0 の認可エンドポイントに渡す redirect_uri パラメータは encodeURIComponent でエンコードします。例: https://example.com/cb → https%3A%2F%2Fexample.com%2Fcb。本ツールでエンコード結果を確認してから OAuth フローに組み込むと、リダイレクトの不一致エラーを未然に防げます。
二重エンコード問題とは？
既にエンコード済の文字列を再度エンコードすると %XX の % 自体が %25 に変換されてしまい、デコード時に元データが復元できなくなります (例: %20 → %2520)。本ツールでデコード結果を確認してから次のエンコードに進むのが安全。サーバー側でも 1 回だけデコードする設計が原則です。
開発者ツールの全体像
本ツール (URL エンコード) は 開発者ツール活用ガイド (sub-Pillar) の一部です。Base64・HTML エスケープとの使い分け、OAuth state パラメータの作成、二重エンコード問題の回避を Pillar ガイドで体系的に確認できます。