URLエンコードとは:%E3%81%82 のような文字列が生まれる理由
更新日:2026-09-17
URLをコピーすると %E3%81%82 のような文字列が並んでいることがあります。これはパーセントエンコーディング(URLエンコード)と呼ばれる変換です。仕組みを整理します。
なぜ変換が必要なのか
URLで安全に使える文字は、仕様で限られています。英数字と一部の記号だけで、日本語はそのままでは扱えません。また、? や & や = のようにURLの中で意味を持つ記号も、データとして使うには区別が必要です。
そこで、使えない文字をバイトごとに % + 16進数2桁に置き換えます。これがパーセントエンコーディングです。
「あ」が %E3%81%82 になるまで
変換の流れ
① 文字「あ」を文字コードでバイト列にする
UTF-8 では E3 81 82 の3バイト
② 各バイトを % + 16進数2桁にする
→ %E3%81%82
バイト数がそのまま %XX の個数になります。UTF-8 の日本語は1文字3バイトが多いので、1文字が9文字分のURLになります。
「テスト」の場合
UTF-8のバイト列 … E3 83 86 E3 82 B9 E3 83 88
URLエンコード … %E3%83%86%E3%82%B9%E3%83%88
文字コードが違うと結果も変わる
変換のもとになるのはバイト列なので、どの文字コードでバイトにするかで結果が変わります。
| 文字コード | 「あ」のバイト列 | URLエンコード |
|---|---|---|
| UTF-8 | E3 81 82 | %E3%81%82 |
| Shift_JIS | 82 A0 | %82%A0 |
| EUC-JP | A4 A2 | %A4%A2 |
同じ「あ」でも3通りになります。デコードするときも同じ文字コードを使わないと、別の文字になったり読めなくなったりします。現在のWebでは UTF-8 が標準ですが、古いシステムでは Shift_JIS が使われていることがあります。
エスケープされない文字
次の文字はそのまま残せる文字(非予約文字)とされています。
- 英数字
A-Z a-z 0-9 - ハイフン
-、ピリオド.、アンダースコア_、チルダ~
それ以外の記号は、用途によってエスケープが必要になります。/ や ? はURLの構造を表す文字なので、データとして使う場合はエスケープします。
このツールでは全バイトをエスケープしている
日本語を変換するとき、2バイト目がたまたま英数字に当たる文字があります。たとえば Shift_JIS の「テ」は 83 65 で、65 は文字 e のコードです。
この場合 %83e と書いても読み取れますが、当サイトのツールは全バイトをエスケープして %83%65 と書き出します。2バイト目が % や + に当たる文字だと、素のまま出すと壊れるためです。読み取る側は %83e の形にも対応しています。
デコードするとき
%XX を見つけたら16進数として読み、バイトに戻します。バイト列がそろったところで、文字コードを指定して文字に戻します。
文字コードを間違えると文字化けします。%82%A0(Shift_JIS の「あ」)を UTF-8 として読もうとすると、UTF-8 として成立しないバイト列なので読めません。
よくある場面
- 検索結果のURLに日本語のキーワードが入っている
- メールで送られてきたURLが長大な
%の羅列になっている - ファイル名に日本語が入ったリンクをコピーした
- APIに渡すパラメータをログで確認している
いずれも、デコードすれば元の文字列が読めます。テキスト変換では、貼り付けた文字列の形式を自動で判定して戻せます。
まとめ
- URLで使える文字が限られているため、使えない文字を
%+16進数2桁に置き換える - 置き換えの単位は文字ではなくバイト
- 文字コードが違えば同じ文字でも結果が変わる
- 英数字と
- . _ ~はそのまま残せる - デコードには、エンコードに使ったのと同じ文字コードが必要
この記事の位置づけ
仕様と一般的な動作を整理したものです。実際の挙動はブラウザやアプリの実装、受け取り側のシステムによって変わることがあります。業務で使う場合は、実際のデータで往復して確かめておくと安全です。
参考・出典
- RFC 3986: Uniform Resource Identifier (URI)
- RFC 4648: The Base16, Base32, and Base64 Data Encodings
- WHATWG Encoding Standard
※2026年9月時点の仕様と、主要なブラウザでの動作にもとづいています。