このツールについて
この無料の URL エンコーダー / デコーダー は、テキストをパーセントエンコードして URL やクエリ文字列の中で安全に使えるようにし、エンコードされた URL を読める文字列に戻します。
UTF-8 を正しく処理するため、アクセント付きの文字、絵文字、非ラテン文字も壊れることなくエンコード・デコードできます。すべてブラウザー内で動作し、何もアップロードされません。
パーセントエンコードとは
URL に使える文字はごく限られています。それ以外のもの — 空白、引用符、&、#、?、アクセント付きの文字、日本語や中国語やアラビア語のすべて — は、送り出す前に書き換えなければなりません。
パーセントエンコードは、文字を % とそのバイト値の16進数表記に置き換えることでそれを行います。空白は %20 に、アンパサンドは %26 に、疑問符は %3F になります。考え方は Base64 と同じ — 扱いにくいデータを、うるさい通り道でも通れる形にする — のですが、1文字ずつ行うため、結果はおおむね読める形のまま残ります。
エンコードされるのはバイトなので、UTF-8 で1バイトを超える文字は複数のエスケープになります。é は2バイトなので %C3%A9 になります。漢字はふつう3バイトで、3つのエスケープになります。絵文字は4バイトです。日本語を含む URL をエンコードすると、あれほど長く見えるのはこのためです。
なぜ重要なのか：`&` の問題
これはこのツールが防ぐために存在する不具合で、ほとんどの人が一度は経験します。
クエリ文字列は値を & と = で区切ります。
/search?q=coffee&page=2
ここで誰かが Bed & Breakfast を検索したとします。そのまま入れると：
/search?q=Bed & Breakfast&page=2
サーバーからは3つのパラメーターに見えます — q は Bed になり、次に意味のない Breakfast というパラメーター、そして page。検索は何も告げずに違う結果を返します。値を先にエンコードすれば正しく動きます。
/search?q=Bed%20%26%20Breakfast&page=2
ここから原則が導かれます。URL 全体ではなく、値をひとつずつエンコードすること。 クエリ文字列を組み立てている & と = はそのまま残さなければなりません。値の中に含まれる & は残してはいけません。
値をエンコードするか、URL 全体をエンコードするか
ここがつまずきどころであり、JavaScript に2つの関数が存在する理由です。
encodeURIComponent は /、?、#、&、= も含めてほぼすべてをエンコードします。URL の一部分、つまり検索語、ファイル名、リダイレクト先、トークンなどに使います。ほとんどの場合これが必要なもので、このツールが行っているのもこれです。
encodeURI は構造を作る文字には手をつけません。すでに正しい完全な URL を渡され、使えない文字だけを整えればよい、という前提だからです。URL 全体に使うもので、単独の値に使ってはいけません。
URL 全体を Component 版でエンコードすると、すべての / が %2F になり、アドレスは機能しなくなります。値を URI 版でエンコードすると、& がそのまま通り抜けてクエリ文字列を壊します。どちらのつもりだったかを意識することが、すべての要点です。
HTML エスケープとは別物です
パーセントエンコードと HTML エスケープは見た目が似ていますが、別の問題を解決します。
パーセントエンコード（%20、%26）は URL の中でテキストを安全にします。HTML エスケープ（&、<）は HTML 文書の中で安全にします。ページに表示される URL は両方必要になることがあり、その順序は決まっています — まず URL 用にエンコードし、その結果を HTML 用にエスケープします。
もうひとつよく知られた癖があります。+ が空白を意味することがあるのです。これは HTML フォームの名残で、application/x-www-form-urlencoded は %20 ではなく + を使います。多くのサーバーはクエリ文字列ではどちらも受け付けますが、パスの中の + は文字どおりのプラス記号です。思わぬところで空白が + になっていたら、原因はフォームのエンコーダーです。
使い方
- テキストまたは URL を入力欄に貼り付けます
- ボタンでエンコードまたはデコードします
- 入れ替えて、結果を入力欄に戻せます
- 結果をコピーします
知っておくとよいこと
- URL 全体ではなく、値をエンコードしてください。 完全なアドレスをエンコーダーに通すと、すべての / が %2F になって壊れます。
- 二重にエンコードしないでください。 % 自体が %25 にエンコードされるため、2回通すと %20 が %2520 になり、空白が失われます。リンクが不可解に壊れる最も多い原因です。
- 予約文字には意味があります — :、/、?、#、@、&、=、+、$ など。URL 内で使えますが、値の中に現れる場合はエンコードが必要です。
- 非予約文字はエンコードされません： A–Z、a–z、0–9、-、_、.、~。
- 16進数の大文字小文字は同じ意味です。 %3f と %3F は同一で、慣習では大文字が使われます。
- 単独の % は無効です。 デコードに失敗したら、16進数2桁が続いていない % を探してください。文字列が途中で切れている合図であることが多いです。
よくある質問
URL の %20 は何を意味しますか？
空白です。空白は URL では使えないため、%20 としてパーセントエンコードされます。% に続く 20 は、空白のバイト値を16進数で表したものです。空白が + と書かれているのを見ることもありますが、これはフォームのエンコードに由来するものです。クエリ文字列ではどちらも通じますが、パスの中で正しいのは %20 だけです。
URL 全体をエンコードすべきですか、一部だけですか？
一部だけです。URL の中に入れる値 — 検索語、ファイル名、リダイレクト先など — をそれぞれエンコードし、URL の構造を作っている ://、/、?、&、= はそのままにします。完全な URL をエンコードするとスラッシュが %2F になり、アドレスとして解決できなくなります。
エンコードしたらリンクが壊れたのはなぜですか？
ほぼ確実に二重エンコードです。% 自体が %25 にエンコードされるため、すでにエンコード済みの文字列をもう一度通すと %20 が %2520 になります。デコードすると空白ではなく文字どおりの %20 が返ってきます。もう一度エンコードする前に、一度デコードして実際に何を持っているか確認してください。
アクセント付きの1文字が複数の % コードになるのはなぜですか？
パーセントエンコードが文字ではなくバイトを対象にしているからです。UTF-8 では é は2バイトなので %C3%A9 になります。漢字やハングルの多くは3バイトで3つのエスケープになり、絵文字は4バイトです。異常ではなく、その文字の大きさがそのまま表れているだけです。
URL エンコードと HTML エスケープの違いは何ですか？
守っている場所が違います。URL エンコード（%26）はウェブアドレスの中でテキストを安全にします。HTML エスケープ（&）は HTML ページの中で安全にします。ページに表示されるリンクは両方必要になることがあり、順序も決まっています。片方を他方の場所で使っても、元の問題は解決しません。
入力したテキストはサーバーに送信されますか？
いいえ。エンコードもデコードもブラウザー内で行われるため、貼り付けた内容が端末から出ることはありません。インターネット接続を切っても動作します。
関連ツール
- Base64 エンコード / デコード — トークンやデータ URL で絶えず出会うもうひとつのエンコード
- JSON フォーマッター — そうしたクエリ文字列に乗ってくる JSON を整形して確認
- JWT デコーダー — URL で届いたトークンを読む
- メールアドレスと URL の抽出 — 文章からリンクをすべて取り出す
