URL エンコード・デコード

URL エンコードとは？#

URL には、エスケープなしで含められる文字の小さな集合しか許されません——ASCII の字母・数字・-、_、.、~ のような一部の記号だけです。それ以外のすべて（スペース、&、中国語の文字、絵文字、さらにはデータとして意図された / でさえ）は、パーセントエンコードのエスケープとして書かなければなりません——% に続く 2 桁の 16 進数で、スペースは %20、中 の UTF-8 バイトは %E4%B8%AD になります。URL エンコードは、任意のテキストを URL の中を安全に移動できるようにする機械的な翻訳です。

いつも混同される 2 つの異なる仕事があり、このツールはオプションセレクターで両方を露出します:

• 構成要素モード（JavaScript の encodeURIComponent のパス）は、字母・数字・- _ . ! ~ * ' ( のいずれでもないものをすべてエスケープします。テキストが、クエリパラメータ、パスセグメント、フラグメントに落とし込む単一のデータである場合に使います——構造的意味を持つ文字（/ ? & = #）が無害なリテラルテキストに還元されるためです。
• 完全 URLモード（encodeURI のパス）は同じ unsafe なバイトをエスケープしつつ、URL 自身の構造文字は意図的にそのまま（: / ? # [ ] @ ! $ & ' ( ) * + , ; =）に残します。すでに正しい形の完全な URL があり、その中のリテラル文字だけをきれいにしたい場合に使います。

デコードはどちらの形式も逆転させます。入力が %GG（有効な 16 進でない）や単独の % のような不正なエスケープを含む場合、ツールは推測するのではなく、エラーを表示し、問題の位置を指し示します。

使い方#

1. 左上の切り替えでエンコードまたはデコードを選びます。
2. オプションで、URL に配置する単一の値には構成要素を、構造を保つべき完全 URL には完全 URLを選びます。
3. 左側の入力ペインに貼り付けます。
4. 右側の出力ペインから結果を読み、コピーをクリックします。
5. サンプルはデモ文字列を読み込みます。クリアはペインをリセットします。

主な特徴#

• 1 つではなく 2 つの実際のスコープ。 構成要素対完全 URL は encodeURIComponent / encodeURI の区別を正確に反映するため、ツールを切り替えずに単一の値をエスケープしたり、URL 全体を整えたりできます。
• 既定で UTF-8。 非 ASCII 文字は UTF-8 バイトシーケンスとしてエンコードされるため（RFC 3986 以降の標準）、中文 は単一エスケープの Latin-1 の塊ではなく %E4%B8%AD%E6%96%87 になります。
• エラーは位置を指す。 デコードが不正な % エスケープに hit したとき、入力全体を投げ捨てるのではなく、ステータス行がその場所を報告します。
• ローカルで動作。 すべてはブラウザ内で起こります。貼り付けたものは何もアップロードされません。

実例#

フラグメント a/b?c=d & e を構成要素モードでエンコードすると次のようになります:

a%2Fb%3Fc%3Dd%20%26%20e

/ は %2F、? は %3F、= は %3D、スペースは %20、& は %26 になることに注意してください——URL 構造として読まれうるすべての文字が中和されています。これが、文字列全体を 1 つのクエリ値に詰め込むための正しい形式です。

ここで完全 URLモードに切り替え、完全な URL をエンコードします:

https://example.com/path?q=hello world&lang=zh CN

結果はプロトコル、スラッシュ、?、& をそのままにし、リテラルのスペースだけをエスケープします:

https://example.com/path?q=hello%20world&lang=zh%20CN

これが 2 つのモードの違いをひと目で示します——構成要素はすべてをデータに平坦化し、完全 URL は URL の骨格を保ち、必要なバイトだけを清掃します。

よくある質問#

構成要素か完全 URL か、どうやって決めますか？#

クエリ文字列を組み立てていて、値の 1 つがユーザー入力由来なら、その値を構成要素でエンコードします。すでに完全に形成された URL があり、単に少数の迷子の文字（スペース、アクセント）を含んでいるなら、全体を完全 URLに通します。有用なテスト: 出力はリンクとして機能するために ?、&、/ を保つ必要があるか？ なら完全 URL を。それらの文字は実際にはデータの一部か？ なら構成要素を。

デコードした文字列に %GG が含まれ、ツールがエラーになります。なぜですか？#

% には常に 2 桁の 16 進数字が続かなければなりません。%GG は有効な 16 進ではないため、デコーダはそれを拒否し、位置を報告します——コードで URIError を投げるのと同じ入力です。送信元が %25（リテラル % のエンコード形式）を送るように修正するか、不正なエスケープを直してください。

クエリ文字列を組み立てる前と後、どちらでエンコードすべきですか？#

各値を = と & でつなぐ前にエンコードしてください。先に ?q=a & b を組み立ててから全体を構成要素モードでエンコードすると、= と & もエスケープされ、サーバーはそれらを区切り子として見なくなります。部品をエンコードしてから組み立ててください。

Unicode はブラウザと同じように扱えますか？#

はい。モダンなブラウザとサーバーはパーセントエスケープが UTF-8 バイトを運ぶことを期待し、それがこのツールが出力するものです——中 は %E4%B8%AD になります。レガシーの 1 バイトエンコード（Latin-1、GBK など）を期待する古いシステムをデバッグしているなら、バイトは異なり、エンコード固有のツールが必要になります。