URLエンコード・デコード

URL Encoder & Decoder

URLとクエリの値をパーセント符号化・復号し、URL全体と構成要素のどちらとして扱うかを切り替えられます。

URLをパーセント符号化し、また元に戻します。どれも「URLエンコード」と呼ばれてしまう4つの規則——`encodeURIComponent`、`encodeURI`、厳密なRFC 3986、そして空白が`+`になるフォームの符号化——を分けて扱います。選び違えると、誰かが`&`を入力するまでは動くリンクができあがります。

🔒 ブラウザの中だけで動きますurlencodedecodepercent

ルール

向き

適用範囲

クエリの値ひとつ、パスの一片ひとつ、フラグメントひとつに使います。`encodeURIComponent` は `/ ? : @ & = + $ , #` をエスケープし、`A-Za-z0-9 - _ . ! ~ * ' ( )` はそのまま残します。

テキスト

符号化された値

入力

0文字

出力

0文字

エスケープした文字

クエリ文字列として編集

使い方

適用する範囲を先に選びます
クエリの値1つ、あるいはパスの一片ならComponentです。ほとんどはこちらです。URL全体は、すでにできあがっているURLを整えたいときにだけ使い、`?`・`&`・`/`は意図的にそのままにします。
貼り付けて結果を読みます
パネルの下のカウンタに、何文字がエスケープされたかが出ます。何も起きない範囲を選んでしまったことに早く気づく方法です。
古いURLをデコードするときはバイトの符号化を変えます
十数年前の日本のサイトのリンクは、UTF-8ではなくShift_JISのバイト列をパーセント符号化していました。UTF-8として解くと文字化けします。デコードのモードの選択欄には、Shift_JIS、EUC-KR、GB18030とLatin-1系があります。
パラメータが多いときは項目ごとに編集します
「クエリ文字列として編集」を切り替えると、URLが名前と値の行に分かれます。値はデコードして表示し、書き戻すときに符号化し直すので、`next=`の中に丸ごと入ったURLも編集に耐えます。

よくある質問

ComponentとURL全体は何が違いますか

Componentは区切り文字の`/ ? : @ & = +`まで符号化します。値の中にそうした文字があると、URLがそこで分かれてしまうからです。URL全体は、それらが構造そのものなので手を付けません。値にURL全体の規則を使うのが、値にアンパサンドが入った瞬間に壊れるリンクを作る定番の方法です。

署名の検証が通らないのはなぜですか

`encodeURIComponent`が`! ' ( ) *`をそのままにするのに対し、RFC 3986はそうしないから、という可能性が高いです。OAuth 1.0やAWS SigV4をはじめ、ほとんどの署名方式は厳密な規則で正規化するので、アポストロフィを含む値はハッシュが変わります。厳密の範囲があるのはそのためです。

「二重に符号化されています」という注記はどういう意味ですか

結果をもう一度デコードすると別のものが出てくる、という意味です。`%20`であるべきところに`%2520`がある場合です。多くは、クライアントで一度、プロキシやフレームワークでもう一度符号化されたということです。元の値を得るには2回デコードし、そのうえでパイプラインを直してください。

空白が`+`になったり`%20`になったりするのはなぜですか

`+`は`application/x-www-form-urlencoded`のものです。フォームのPOSTの本文と、`URLSearchParams`が作る形式がそれにあたります。URLのそれ以外の場所では空白は`%20`で、`+`はプラス記号そのものを意味します。混ぜると`a+b`が`a b`になったり、その逆になったりします。