URLエンコードの早見表と変換

URLの中にそのまま書ける文字は、英数字62種と - . _ ~ を足した66種類だけです。それ以外は「%」と2桁の数字に 化けます。ASCII 128文字ぶんの早見表と、貼った文字の変換を、 同じ1枚に置きました。日本語1文字が %XX 3つになる理由も、 バイトを並べて見せます。

URLにそのまま書ける文字は、たった66種類しかない

URLの決まりを書いた RFC 3986 は、そのまま置いてよい文字をunreserved（予約されていない文字）として名指ししています ── 英字52・数字10・そして - . _ ~ の4つ、 合わせて66文字だけ。残りは2つに分かれます。

1つは区切りの役を持つ文字で、大きな区切りが # / : ? @ [ ] の7つ、 小さな区切りが ! $ & ' ( ) * + , ; = の11個。もう1つは、どちらの役も無くて居場所が無い11文字 ── 半角スペース " % < > \ ^ ` { | } です。

印字できるASCIIは95文字なので、66＋7＋11＋11＝95 でぴったり埋まります。 この足し算は条文の集合の定義から数えたもので、よそから写した数ではありません （単体テストが固定しています）。だから「URLを人に送ったら壊れた」の正体はいつも同じで、66種類の外にある文字が、化けないまま置かれています。

日本語1文字が %XX 3つになるのは、UTF-8が3バイトだから

% のうしろの2桁は文字番号ではなく、バイトの値です。UTF-8はコードポイントの大きさでバイト数を変えていて、 RFC 3629 の表では U+0080〜U+07FF が2バイト、U+0800〜U+FFFF が3バイト（1110xxxx 10xxxxxx 10xxxxxx）、 U+10000以上が4バイトと決まっています。

ひらがな（U+3041〜309F）・カタカナ（U+30A0〜30FF）・CJK統合漢字（U+4E00〜9FFF）は まるごと3バイトの範囲に入ります ── この3つの範囲の21,183文字を全部通して数え、 3バイト以外が0件であることを確かめました。 だから「あ」は U+3042 → E3 81 82 → %E3%81%82。1文字が9文字になります。絵文字はもう一段大きく、🦙（U+1F999）は4バイトで %F0%9F%A6%99 と4つ並びます。 上の道具は 文字ごとに「文字 → 文字番号 → バイト → %表記」の4段を並べて出すので、 なぜ3つなのかを自分で数えて確かめられます。

半角スペースが %20 になるときと + になるときがある

同じ半角スペースなのに、URLの道の部分では %20、 検索フォームが送るときは + になります。どちらかが間違いなのではなく、決まりが2つあるからです。 パーセントエンコーディング（RFC 3986）に + の 特別扱いは無く、空白は %20 になります。いっぽう HTMLのフォームが使う application/x-www-form-urlencoded は、1995年の RFC 1866 が 「space characters are replaced by +（空白は + に置き換える）」と決めていて、 いまの WHATWG URL Standard にも「spaceAsPlus が true なら 0x20 は U+002B (+) に する」という形で残っています。

ここに落とし穴があります。戻すときは、先に + を空白に直してから %XX をほどくのが決まりです（URL Standard のパーサの手順がその順番）。だから %2B はほどいた結果の + であって、空白にはなりません。順番を逆にすると 1%2B2+3 が「1 2 3」になり、足し算が消えます。上の道具は + を空白として読むかどうかを選べて、 どちらで読んだかを画面に出します。

encodeURI と encodeURIComponent の違いは、ちょうど11文字

JavaScriptの2つの関数は、変換しない文字の集合が違うだけです。ECMA-262 の Encode を読むと、どちらも英数字と ! ' ( ) * - . _ ~ を常に残し、encodeURI だけが追加で ;/?:@&=+$,# を残します （仕様の中にこの文字列がそのまま書いてあります）。

0から127までを1文字ずつ通して数えると、そのまま残る文字は encodeURIComponent が71・encodeURI が82で、差は ちょうど11 ── 条文と数が合います。 使い分けもここから決まります。URLを丸ごと渡すなら encodeURI（区切り記号まで 化けさせると壊れる）、?q= のうしろに入れる値なら encodeURIComponent（区切り記号を残すと値がそこで切れる）。

ただし ECMA-262 自身が「この予約文字の集合は RFC 2396 にもとづいており、より新しい RFC 3986 の変更を反映していない」と但し書きを付けています。! ' ( ) * - . _ ~ を残すのは1998年の古い規格の名残で、 いまのフォームの決まりで残るのは * - . _ の4つだけ。 上の早見表を右へ3列たどると、その食い違いが行ごとに見えます。

同じ「あ」でも %E3%81%82 と %82%A0 の2通りがある

%XX はバイトの値でしかないので、どの文字コードでバイトにしたかが決まらないと元の文字に戻せません。 RFC 3986 §2.5 は、新しい方式が文字を扱うときはまず UTF-8 でバイトにしてから %エンコードすべきだと書いていて、 その例としてカタカナの「ア」＝%E3%82%A2 を 挙げています（この値も、手で書かずにこの道具に作らせています）。

しかし2000年代の日本のサイトは Shift_JIS でページを作っていたので、そのころのURLでは 同じ「あ」が %82%A0 になっています。EUC-JP なら %A4%A2。だから %82%A0 を UTF-8 として読もうとすると必ず失敗します。この道具は失敗を空欄で返しません。何バイト目が読めなかったかを言い、 実際に読めた文字コードとその結果を並べて、どれが読みたかったかを人に選んでもらいます。

読めてしまうことがあるのが、いちばん怖いところです。EUC-JP の 「あ」（%A4%A2）を Shift_JIS として読むと、 エラーにならずに半角カナ2文字になります。だから「この文字コードです」と 1つだけ名指しはせず、読めたものを全部並べています。 文字化けそのものを読み解きたいときは、文字化け復元の ページのほうが向いています。

? と & と # は区切りの役。文字として書きたいなら化けさせる

URLは記号で区画が分かれています。: と // のうしろが住所、? から先が問い合わせ、& が項目の切れ目、= が名前と値の境目、# から先はページの中の位置です。

だから値の中に & を素で書くと、そこで項目が切れます。 「トム&ジェリー」を検索語にしたつもりが「トム」と「ジェリー」の2項目として送られ、 受け取った側は「ジェリー」を知らない名前として捨ててしまう ── これが実際に起きる壊れ方です。文字として渡したいなら %26 に化けさせます。同じ理由で ? は %3F、# は %23、/ は %2F、= は %3D。そして % 自身は %25 です ── RFC 3986 §2.4 が「% は %エンコードの目印なので、データとして使うには %25 に しなければならない」と明記しています。

上の道具は貼られたURLを区画に割って、どの記号がいま区切りとして働いているかを、色ではなく文字の名札で示します。割るのは「英字ではじまる名前と :」がある文字列だけです。RFC 3986 の付録Bに載っている 正規表現はどんな文字列にも当たってしまうので、それだけで判断すると 「10:30」の「10」までしくみの名前だと言ってしまいます。 §3.1 の決まりを満たさないときは、当てずっぽうで割らずに「URLの形になっていません」と 言います。

2回エンコードすると %2520 になって、戻し方が1通りでなくなる

%20（半角スペース）をもう一度エンコードすると、 先頭の % が %25 に化けて %2520 になります。1回ほどけば %20、2回ほどいてやっと空白。プログラムの受け渡しで 「念のためもう一度」と掛けると、こうして二重になります。

RFC 3986 §2.4 は「実装は同じ文字列を2回以上エンコードしても、デコードしてもならない」 と書き、理由も添えています ── データとしての % が、 %エンコードの始まりと読み違えられるからです。逆に、深く考えずに2回ほどくのも 危険です。%253F を2回ほどくと ? になり、値だったはずのものが区切り記号に変わってしまいます。

だからこの道具は、貼られた文字列に %25 があれば 「二重の可能性があります」と文字で伝え、1回ほどいた結果と2回ほどいた結果を並べます。 勝手に2回ほどいて1つの答えを返すことはしません。

Googleは「ASCII以外の文字はパーセントエンコードを行う必要があります」と書いている

URLに日本語を使ってよいのか、という問いには、検索側の公式な答えがあります。 Google 検索セントラルの「URL構造のベストプラクティス」は、読み手の言語の単語をURLに使うことをすすめたうえで、リンクの href では「予約されていないASCII文字はエンコードされない 形式のまま残る可能性があります。さらに、ASCII以外の文字はパーセントエンコードを行う 必要があります」としています。

同じページに載っている例が 🦙✨ → %F0%9F%A6%99%E2%9C%A8 と gemüse → gem%C3%BCse で、 どちらもこの道具が出す値と一致します（絵文字2つで %XX が7つ ── 🦙 は4バイト、✨ は3バイト）。つまり「日本語のURLを使う」と「%エンコードする」は対立しません ──人が読む姿は日本語のまま、送る姿は %XX の並び、というのが正しい形です。 あわせて Google は、単語の区切りにアンダースコアではなくハイフンを使うようすすめています。_ も - も どちらも66文字の中にあって化けませんが、意味の伝わり方が違います。

文字をURLに置くためではなく、そのまま送れる形にまとめたいときはBase64のページのほうが向いています（あちらにも URLエンコードの変換が付いています）。バイトの値そのものを見たいときはn進数へどうぞ。

出どころ: RFC 3986（新しいタブで開きます）（§2.1 の大文字・§2.2 の区切り・§2.3 の unreserved・§2.4 の %25 と二重禁止・§2.5 の 「ア」の例・§3.1 のスキーム・付録B）、RFC 3629（新しいタブで開きます）（UTF-8のバイト割り当て表）、WHATWG URL Standard（新しいタブで開きます）（§1.3 の percent-encode set と、+ を先に空白へ直す段の順番）、ECMA-262 19.2.6（新しいタブで開きます）（encodeURI の ;/?:@&=+$,# と、RFC 2396 にもとづくという但し書き）、RFC 2396（新しいタブで開きます）（§2.3 の mark）、RFC 1866（新しいタブで開きます）（§8.2.1 の + と %0D%0A）、RFC 20（新しいタブで開きます）（制御文字33個の名前と、DELについての断り）、WHATWG Encoding Standard（新しいタブで開きます）（Shift_JIS の並べ方）、Google 検索セントラル「URL構造のベストプラクティス」（新しいタブで開きます）。 確かめられなかったこと ──【1】同じ題材の道具として 調べようとした tools.studioasari.co.jp の URLエンコードのページは、HTTP 404 で開けませんでした（404のページが返ります）。だからそこを根拠にした記述は1つも書いていません。【2】RFC 3986 の正誤表に、§2.3 の unreserved にバックスラッシュが抜けているのではという指摘 （Errata ID 9147・2026年8月27日報告）が出ていますが、まだ受理されていない（Status: Reported）ので、 この表の66種類は動かしていません。規格が変わったわけではありません。 【3】Shift_JIS の並びを確かめるのに使った WHATWG の索引データそのものは、 転載の条件が付くのでこのサイトには置いていません ── 変換は お使いのブラウザが持っている表から作っています。数（66・7・11・11・33・71・82・66・21,183）は、このページがその場で数えたもので、よそから写した数字は1つもありません。