リンクを貼ったら本来は文字のはずの場所に %E3%81%82 が現れたり、クエリパラメータが謎に壊れたりした経験はありませんか?それが URL エンコードの働きです。仕組みが分かれば、あの謎の文字列を読んで筋道立てて扱えるようになります。
入力ひとつに要点が 3 つ。 URL エンコーダーで
台北 101 & friends?を符号化すると、こうなりました。%E5%8F%B0%E5%8C%97%20101%20%26%20friends%3Fこの文字列から 3 つのことが分かります。漢字 1 文字が 3 バイト(
%E5%8F%B0)になっているのは、UTF-8 が CJK に 3 バイト必要とするからです。空白は%20になり、+にはなりません —— プラス形式はフォーム本体のもので、パスのものではありません。そして&と?が escape されたのは、そのままだと値が終わって新しいパラメーターが始まってしまうからです。同じ文字列を貼れば見比べられます。
URL エンコードとは?
URL エンコードは**パーセントエンコード(percent-encoding)**とも呼ばれ、URL にそのまま置けない文字や、置くと誤解釈される文字を安全な形に書き換える仕組みです。対象の文字を % とそのバイトの 2 桁 16 進数に置き換えます。空白は %20、& は %26、日本語の「あ」(UTF-8)は 3 バイトで %E3%81%82 になります。
このルールは URL の標準規格 RFC 3986 に基づきます。目的はシンプルで、URL がコピーされても、メールで送られても、どのサーバーで解析されても、曖昧さなく通じるようにするためです。
URL エンコード / デコードツールなら、任意の文字列をその場で変換できます。処理はすべてブラウザ内で完結します。
なぜ URL にエンコードが必要か
URL には限られた ASCII 文字しか入れられません。その範囲を超えるもの —— 空白、アクセント付き文字、日本語などの非 ASCII 文字、あるいは ?・&・#・/ のように特別な意味を持つ記号 —— は、URL の構造と取り違えられないようパーセントエンコードが必要です。
たとえば ? は URL の中でクエリ文字列の開始を表します。もし「ある値の中に」文字どおりの疑問符を入れたいなら %3F と書かなければならず、そうしないと解析器はそれ以降をすべてパラメータとして扱ってしまいます。エンコードはこの曖昧さを取り除きます。
よく使う記号の変換
遭遇しやすい記号とそのパーセントエンコード形は次のとおりです。
| 文字 | エンコード後 | 備考 |
|---|---|---|
| 空白 | %20 | + はフォームデータのみ(後述) |
& | %26 | クエリパラメータの区切り |
? | %3F | クエリ文字列の開始 |
= | %3D | キーと値の区切り |
# | %23 | フラグメントの開始 |
/ | %2F | パスの区切り |
+ | %2B | 空白と誤読されないための文字どおりのプラス |
あ | %E3%81%82 | 非 ASCII、UTF-8 のバイトごとに変換 |
非 ASCII 文字(日本語、中国語、絵文字、アクセント付きラテン文字)は、まず UTF-8 のバイト列に変換され、その各バイトがパーセントエンコードされます。見た目 1 文字が複数の %XX に膨らむのはこのためです。
私たちの URL エンコーダーに 1 つの文字列を通した結果です。台北 101 & friends? は %E5%8F%B0%E5%8C%97%20101%20%26%20friends%3F になります。ここから 3 つの事実が読めます。漢字 1 文字が 3 バイトを占めたこと、空白が + ではなく %20 になったこと、そして & と ? が escape されたこと(そのままだと値が終わり、新しいパラメーターが始まってしまいます)。
RFC の表を改めて載せるより、私たちのURL エンコーダーが8 つの入力に対して実際に返した結果を置きます。各カテゴリを少なくとも 1 つ含むように選びました。うち 2 つはそのまま返ってきます。そこが要点です。~ _ . - は非予約文字なので、正しいエンコーダーは触ってはいけません。
| 入力 | エンコード後 |
|---|---|
hello | hello |
hello world | hello%20world |
a+b=c | a%2Bb%3Dc |
100% | 100%25 |
台北 | %E5%8F%B0%E5%8C%97 |
?q=x&r=y | %3Fq%3Dx%26r%3Dy |
a/b | a%2Fb |
~_.- | ~_.- |
予約文字 vs 非予約文字
- 非予約文字(
A–Z a–z 0–9 - _ . ~)はエンコード不要です。 - 予約文字(
: / ? # [ ] @ ! $ & ' ( ) * + , ; =)は URL 内で構造的な意味を持ちます。エンコードするかは文脈次第 —— 値の中では必須、構造として使うときは不可です。
この違いこそ、次の encodeURIComponent と encodeURI の使い分けの核心です。
いつエンコードすべきか
ひとことで言えば、エンコードするのは「URL に入れる部品」であって「組み上がった URL 全体」ではありません。
- エンコードするのは、これから差し込む値 —— 検索語、ファイル名、リダイレクト先、ユーザー入力や別システム由来のものなど。
- 完成した URL 全体をむやみにエンコードしないこと。構造を支える
/ ? & =まで一緒にエスケープされ、リンクが壊れます。
役立つ考え方:URL の構造は自分で組み立て、各部品は「差し込む前に」それぞれエンコードする。パラメータ値「赤 と 青」をエンコードすると %E8%B5%A4%20%E3%81%A8%20%E9%9D%92 になり、?color=... に安全に収まります。
encodeURIComponent vs encodeURI
encodeURIComponentは予約文字もエンコードします。単一の値(1 つのクエリパラメータ、1 つのパスセグメント)に使います。encodeURIは構造文字(/ ? & =)を保持します。分割したくないURL 全体に使います。
encodeURIComponent("a b&c=d") // "a%20b%26c%3Dd" ✅ 値として安全
encodeURI("https://x.com/a b") // "https://x.com/a%20b" ✅ URL 全体選び間違いはよくあるバグの原因です。値に encodeURI を使うと中の & がエスケープされず、クエリ文字列が壊れます。
空白のエンコード:%20 と +
空白はどの文字よりも人を悩ませます。%20 と + はどちらも空白を表せますが、使う場面が異なります。
- URL パスや現代のクエリ文字列では標準は
%20。 - 空白を
+にするのは、HTML フォーム送信で使われる古いapplication/x-www-form-urlencoded形式に由来します。この形式では、文字どおりの+は逆に%2Bと書く必要があります。
迷ったら %20 が安全で普遍的な選択 —— 当ツールもこれを出力します。
対照として、同じ文字列を Base64 ツールに通すと 5Y+w5YyXIDEwMQ== です。出発点は同じ UTF-8 バイト列ですが、そこから完全に分かれます。Base64 は全バイトを 64 文字のアルファベットで表し直し 4 の倍数までパディングし、パーセントエンコードは安全な文字をそのまま残して残りだけを escape します。
+ の混乱もここから始まります。私たちのエンコーダーは a+b=c に対して a%2Bb%3Dc を返します。プラス記号自体が %2B になります。そうせざるを得ません。もし文字どおりの + を残せば、+ を空白として読むデコーダーは値を黙って壊します。フォームのデコーダーはまさにそう読みます。つまり「空白としての +」と「プラスとしての +」は未エンコードで共存できません。エンコーダーは裸の + を一切出さないことで決着させています。
典型的な二重エンコードのバグ
文字列を 2 回エンコードすると、%20 は %2520 になります(% 自身が %25 にエンコードされるため)。症状:ブラウザに文字どおりの %20 が出る、空白が %2520 になる、など。解決策はちょうど 1 回だけエンコードすること —— 入力の状態が不明ならまずデコードします。デコードツールで今何を持っているか簡単に確認できます。
同じ仕組みが二重エンコードも説明します。% も URL では安全ではなく、私たちのエンコーダーは 100% を 100%25 にします。その出力をもう一度通すと %25 は %2525 へ。依然として妥当な URL で、依然としてデコードできますが、デコード結果は別の文字列です。二重エンコードは決して構文エラーにならない —— だから本番まで生き残ります。
オンラインで URL をエンコード / デコードする方法
16 進数の対応表を覚える必要はありません。テキストや URL をオンライン URL エンコード / デコードツールに貼り、「エンコード」と「デコード」を切り替えて結果をコピーするだけです。処理は完全にブラウザ内で行われるため、貼り付けた内容はアップロードされません —— トークンや個人情報を含むリンクでも安心です。バイナリデータやヘッダーを扱うなら Base64 の出番で、Base64 と URL エンコードの違いでそれぞれの使いどころを解説しています。
よくある質問
普通に見える URL は、共有する前にエンコードが必要? たいてい不要です —— ブラウザですでに動いているなら問題ありません。エンコードすべきは、新しい URL に組み込む値だけです。
なぜ & でリンクが 2 つに切れた? エンコードされていない & は新しいクエリパラメータを始めてしまいます。値の中では %26 と書く必要があります。
リンクに %2520 が出るのはなぜ? 二重エンコードされた空白です。1 回デコードすれば元の %20 に戻ります。
%20 と + は入れ替えてよい? x-www-form-urlencoded のフォーム本文の中だけです。パスや一般のクエリ文字列では %20 を優先してください。
クイックリファレンス
- パラメータ値をエンコード?→
encodeURIComponent。 - URL 全体をエンコード?→
encodeURI。 - 空白を入れたい?→
%20(+はフォームデータのみ)。 - 見慣れない
%XX?→ デコードして原文を読む。
無料の URL エンコード / デコードツールで URL とクエリパラメータをその場でエンコード・デコードできます —— すべてブラウザ内で動作します。