URL エンコーダー

パーセントエンコーディングについて

パーセントエンコーディング（URL エンコーディング）は、空白、&、?、# や非 ASCII 文字など、URL 内で安全でない文字を % とその 16 進バイト値に置き換えます。これにより、クエリ文字列やパス部分が URL 自体の構文を壊さずに任意のテキストを運べます。

すべての文字がエンコードを必要とするわけではなく、そのままにされる文字の集合は文脈によって変わります。RFC 3986 では、文字・数字・- _ . ~ は常に安全と定められています。それ以外の「予約」文字集合（/ ? # & など）は、すでに構文上の役割を果たしていない場所でのみ安全です。フォーム特有の癖もあります。ブラウザが HTML フォームを送信する形式である application/x-www-form-urlencoded では、スペースを %20 ではなく + としてエンコードします。これはこの特定のコンテンツタイプに限った慣習であり、URL 全般の話ではありません。

使われる場面

• 空白、記号、非ラテン文字を含むクエリ文字列の値
• application/x-www-form-urlencoded で送信されるフォーム送信
• URL パラメータとして渡されるリダイレクト URL やトークンのエンコード
• ファイルパスや検索語をリンクに安全に含める

よくある質問

パーセントエンコーディングは Base64 と同じですか？
いいえ、解決する問題が異なります。パーセントエンコーディングは、それ以外は読める状態のテキスト内で特定の安全でない文字だけをエスケープします。Base64 はバイナリデータ全体を固定の文字集合に再エンコードします。

一部の文字が変化しないのはなぜですか？
英数字と一部の記号（- _ . ~）は URL 内で常に安全と定義されているため、そのまま残されます。

これは URL 全体をエンコードしますか、それとも一部だけですか？
値として貼り付けたテキストだけです。URL 全体をエンコードすると、そのまま残すべきスラッシュやコロンもエスケープされてしまうため、アドレス全体ではなく個々のクエリ値に適用してください。

スペースが + になるときと %20 になるときがあるのはなぜですか？
どちらも有効ですが、場所が異なります。URL のパスやクエリ文字列では、スペースは正しくは %20 としてエンコードされます。+ という省略記法は、HTML フォームが送信に使う application/x-www-form-urlencoded 形式に固有のもので、そこでは文字としての + 自体を曖昧さ回避のため %2B にエンコードする必要があります。このツールは常に正しい %20 を生成します。フォームエンコードされた本文を手作業で組み立てる場合は、エンコード済みのスペースを + に置き換えてください。