URLエンコード・デコード
URLに置けない文字を%XXの形に変えるか、元に戻します。URL全体と値一つでは、そのまま残すべき文字が違うので、どちらを符号化するのかを選んでいただきます。
入れたものは端末から出ません。 ブラウザの中だけで処理し、どこにも送らず保存もしません。
パーセントエンコードがしていること
URL に入れられるのは ASCII の一部だけです。それ以外は UTF-8 のバイト列に変え、バイトごとに % と16進数2桁で書きます。日本語一文字は3バイトなので「あ」は %E3%81%82 の9文字になります。英数字と -・_・.・~ はどこでも変わらず、空白は %20 です。アドレスバーには日本語が見えていても、ブラウザが実際に送るのはこの形なので、コピーした URL が % だらけなのはそのためです。
`encodeURI` と `encodeURIComponent`
この画面の二つの方式は、ブラウザのこの二つの関数そのものです。URL 全体は : / ? # & = + $ , ; を残し、部分はそれらも変換します。どちらも ! ' ( ) * は残しますが、仕様上は予約文字なので厳密なサーバーは違って読むことがあります。クエリの値に & や = が入ったまま URL 全体の方式を使うと、その場所で値が切れます。値を一つ入れるときは部分を使ってください。
戻すとき `+` は空白になります
フォーム送信の方式は空白を + と書くので、戻すときは先に + を空白に変えてから解きます。値の中に本物の足し算記号があったなら、%2B と書かれていたときだけ生き残ります。%E0 のようにバイトが足りないものや %zz のように16進数でないものは、解けないとして返します。途中で切れた URL はたいていこの形です。
戻すときは方式を選びません
URL 全体と値の断片の区別は、エンコードするときにだけ使います。戻すのはいつも断片の方式なので、%2F・%3F・%26 もすべて文字に戻り、URL 全体を入れても区切り文字はもともとの文字なので、結果はそのまま URL として読めます。ただし + を空白にする規則もいつも働くので、パスに入った本物のプラス、たとえば /c++ は /c と空白二つになります。フォームの値ではない URL を戻したのにプラスが消えたなら、それが原因です。
`%` そのものも変わります
どちらの方式でも % は残す文字ではなく %25 に変わります。すでにエンコードされた %20 をもう一度入れると %2520 になり、リンクをやり取りするうちに二重に包まれるのはまさにこの道筋です。エンコードはこうして何層でも積み重なり、戻すのは一度に一層だけなので、%25 が見えたらもう一度戻してください。
よくある質問
二つの方式は何が違いますか
URL全体を符号化するときは区切りの : / ? & = をそのまま残します。値だけを符号化するときはそれらも変換します。& を含む値をURL全体として符号化すると、その & のところで値が切れてしまいます — 値には値用の方式をお使いください。
URL全体と値一つを分ける理由は何ですか
?・&・/ はURLの中で 構造としての意味 を持ちます。アドレス全体を渡すときにそれらまで変換すればアドレスが壊れ、逆に値の中でそのまま残せば、値の中の & が次のパラメータの始まりとして読まれます。だから二つに分けています。
空白は `+` になるのではありませんか
場所によります。パスの中では %20 が正しく、フォーム送信の符号化では空白が + になります。受け取る側がフォーム符号化として解釈するのに %20 を送ると、そのまま文字として残ることがあります — 相手がどちらを期待しているかをお確かめください。
二重に符号化されたものを戻すには
%2520 が見えたら、%25 の分だけ二重に包まれています。もう一度デコードしてください。リンクを渡す途中で再び符号化されると、簡単に起こります。
日本語のドメインはどうすればいいですか？
ここでは扱わないのが正解です。パーセントエンコードはパスとクエリの値の規則で、ホスト名は IDNA という別の規則で xn-- の形になります。このツールに https://한글.kr を入れるとホストまで % に変わり、その URL は開きません。アドレス欄にそのまま入れれば、ブラウザが変換します。
貼り付けたものはサーバへ送られますか
送られません。すべてブラウザの中で動き、送信も保存もしません。だからこそ、ふつうならウェブページに貼り付けない社内の設定ファイルや本番のクエリにも使えます。通信を切ったままでも動きます。