URL エンコード / デコード

例：検索キーワードをクエリに入れる

?q= の後ろに検索語をつなぐ前に、検索語を「値」としてエンコードします。そのままだと空白や &、= が URL の区切りとして読まれてしまいます。

半角スペースを入れた 渋谷 ラーメン を「スペースを + に（フォームデータ）」でエンコードすると %E6%B8%8B%E8%B0%B7+%E3%83%A9%E3%83%BC%E3%83%A1%E3%83%B3 になります。漢字もカタカナも長音記号も、1文字が3組の %XX です。

全角スペースは %E3%80%80 になる

日本語入力をオンにしたままスペースキーを押すと、設定によっては全角スペースが入ります。見た目は似ていても別の文字なので、URL では違うバイト列になります。

全角スペースの 渋谷　ラーメン は、同じ設定でも %E6%B8%8B%E8%B0%B7%E3%80%80%E3%83%A9%E3%83%BC%E3%83%A1%E3%83%B3 になり、+ は現れません。サーバー側がデコード後の半角スペースで単語を分けている場合、全角スペースでは分割されません。半角に揃えてから送るか、サーバー側で U+3000 も空白として扱う必要があります。

Shift_JIS の古いリンク

HTML のフォームは、ページ自体の文字コードでクエリをエンコードします（HTML Living Standard 4.10.22.5：まず文書の文字エンコーディングを使う）。そのため Shift_JIS で作られたページから送られた「渋谷」は、UTF-8 とはまったく違う %8Fa%92J になります。a と J は Shift_JIS の2バイト目がたまたま ASCII の英字にあたる部分で、エンコードされずに残っています。

これをデコードすると、文字化けした文字は出さずに 1 文字目から：%8F は有効な UTF-8 ではありません。Shift_JIS などほかの文字コードのテキストはここではデコードできません。 と止まります。このツールは UTF-8 だけを扱います。Shift_JIS や EUC-JP は WHATWG の Encoding Standard で「レガシー」とされている文字コードで、読むには文字コードを指定できる処理が必要です。たとえば Python なら urllib.parse.unquote('%8Fa%92J', encoding='shift_jis') で 渋谷 に戻ります。

+ と %20 の読み方

デコードの初期設定では %XX だけを元に戻します。

最初の例の出力 %E6%B8%8B%E8%B0%B7+%E3%83%A9%E3%83%BC%E3%83%A1%E3%83%B3 をそのままデコードすると 渋谷+ラーメン となり、+ が残ります。フォームから送られた値だとわかっているときは「スペースを + に」を有効にして読み直してください。逆に、値の中の本物の + は、フォーム形式では %2B と書かれます。

このツールが向いている場面

• クエリの値に空白、&、=、#、日本語が入るとき。
• URL をまるごと別の URL のパラメーターにするとき（ログイン後の戻り先など）。: や / もエンコードされるので、そのまま値として渡せます。
• 開くための完全な URL を整えたいときには向きません。区切り文字までエンコードされ、リンクとして使えなくなります。その場合は URL パーサーでパラメーターを1つずつ直してください。

制限

• 対応する文字コードは UTF-8 だけで、文字コードの推測もしません。Shift_JIS や EUC-JP のパーセントエンコードはほとんどの場合エラーになりますが、バイト列がたまたま UTF-8 としても正しいときは別の文字に化けて表示され、注意も出ません。
• ISO-2022-JP はすべて7ビットのバイトなので、エラーにならずに記号の列としてデコードされます。ISO-2022-JP の「渋谷」%1B%24B%3DBC%2B%1B%28B は ␛$B=BC+␛(B になります（␛ は見えない制御文字 ESC をここで置き換えたものです）。
• デコードは最初の問題で止まり、その位置を示します。末尾の 100% のように単独の % もエラーです。
• 初期設定のエンコードでは ! ' ( ) * をそのまま残します（encodeURIComponent の仕様）。署名の計算などで %21 %27 %28 %29 %2A が必要なときは手で置き換えてください。
• encodeURI のモードはありません。
• 絵文字の途中で切れた文字列（単独のサロゲート）はエンコードできず、位置を表示します。