URLエンコードとパーセントエンコーディングの仕組み
このツールができること
URLが安全に運べる文字は限られています。予約されていない英数字といくつかの記号を除いた文字はすべて、パーセントエンコーディング（%記号のあとに16進数のバイト値が続く形式）に書き換える必要があります。このツールは通常のテキストをそのエンコード形式に変換し、逆方向にも動作して、%20や%26といった並びを元の文字に戻します。
実際に出会う場面を、3つのエンコード方式でカバーします。標準エンコードはJavaScriptのencodeURIに対応し、URL全体を対象とするため、:、/、?、#といった構造上の文字はそのまま残ります。コンポーネントエンコードはencodeURIComponentに対応し、それらの構造上の文字までエスケープするので、パラメータの値のような単独の部分に向いています。フォームエンコードは、ブラウザがフォームを送信するときに使うapplication/x-www-form-urlencodedの規則に従います。
使いどころ
値をクエリ文字列の中に入れるときは、コンポーネントエンコードを選びます。検索語、メールアドレス、あるいはそれ自体に?、&、=を含むリダイレクト先などです。エンコードしておけば、これらの記号がURLの構造として読まれてリンクが壊れることを防げます。標準エンコードは、スペースやアクセント付き文字が紛れ込んだ完全なアドレスを整えたいが、スラッシュや疑問符は意味を保ちたい場合に合います。フォームエンコードは、POSTリクエストの本文や手作業で組み立てたフォームの値に対応し、スペースは%20ではなく+として書かれます。デコードも同じくらいよく使います。ログやアクセス解析レポート、リダイレクトの連鎖から拾ったエンコード済みリンクを貼り付け、実際にどこを指しているのかを読み解く場面です。
具体例
hello world & café というテキストで考えます。コンポーネントエンコードでは、スペースは%20に、アンパサンドは%26になり、café は é がUTF-8で2バイトとして格納されるため caf%C3%A9 になります。フォームエンコードでは、同じスペースが+として書かれ、hello+world となります。リアルタイムの統計は、何文字が変化し、文字列のどれくらいがエンコードされたかを示すので、すでに一度エンコード済みのテキストを見分ける手がかりになります。
注意点とエッジケース
予約文字（: / ? # [ ] @ ! $ & ' ( ) * + , ; =）はURLの中で意味を持つため、標準モードはあえてそのまま残し、コンポーネントモードはエスケープします。モードの選び方を誤ることが、クエリパラメータが壊れる典型的な原因です。エンコードはUTF-8のバイト列を基準に定義されているので、ASCII以外の文字は複数の%XXの並びに展開されます。URLを二重にエンコードしないよう注意してください。すでにエスケープの一部になっている%が単独で%25に変わると、リンクは解決しなくなります。迷ったときは、まずデコードして、テキストが素の状態か、すでにエスケープ済みかを確かめましょう。