パーセントエンコーディング

URL エンコーディングは、正式にはパーセントエンコーディングと呼ばれ、 URI 内で有効なUS-ASCII文字のみを使用して、 URI 内の任意のデータをエンコードする方法です。URLエンコーディングとして知られていますが、 Uniform Resource Locator (URL) とUniform Resource Name (URN) の両方を含む主要なUniform Resource Identifier (URI) セット内でもより一般的に使用されています。したがって、 HTTP要求 でHTMLフォームデータを送信する際によく使用されるように、メディア タイプのデータの準備にも使用されます。application/x-www-form-urlencoded

URI で使用できる文字は、予約文字または非予約文字(またはパーセント エンコーディングの一部であるパー​​セント文字) のいずれかです。予約文字は、特別な意味を持つことがある文字です。たとえば、スラッシュ文字は、URL (またはより一般的には URI) のさまざまな部分を区切るために使用されます。非予約文字にはそのような意味はありません。パーセント エンコーディングを使用すると、予約文字は特別な文字シーケンスを使用して表されます。予約文字と非予約文字のセット、および特定の予約文字が特別な意味を持つ状況は、URI と URI スキームを管理する仕様が改訂されるたびに少しずつ変化しています。

URI 内の他の文字はパーセントエンコードする必要があります。

予約セットの文字 (「予約文字」) が特定のコンテキストで特別な意味 (「予約目的」) を持ち、URI スキームでその文字を他の目的に使用する必要があると指定されている場合、その文字はパーセントエンコードされる必要があります。予約文字をパーセントエンコードするには、文字をASCIIの対応するバイト値に変換し、その値を16 進数のペアとして表します(16 進数が 1 つの場合は、先頭にゼロが追加されます)。パーセント記号( %)がエスケープ文字として先頭に付いた数字は、URI で予約文字の代わりに使用されます (非 ASCII 文字は通常、 UTF-8のバイト シーケンスに変換され、各バイト値が上記のように表されます)。

/たとえば、予約文字は、 URIの「パス」コンポーネントで使用される場合、パス セグメント間の区切り文字 という特別な意味を持ちます。 特定の URI スキームに従って がパスセグメント内にある必要がある場合、そのセグメントでは、生の ではなくまたはの3 つの文字を使用する必要があります。 /%2F%2f/

特定のコンテキストで予約目的を持たない予約文字もパーセントエンコードされる場合がありますが、意味的にはパーセントエンコードされていない文字と変わりません。

たとえば、 URI の「query」コンポーネント (文字の後の部分) では、 は依然として予約文字と見なされますが、特定の URI スキームで特に指定がない限り、通常は予約目的はありません。予約目的がない場合は、文字をパーセントエンコードする必要はありません。 ?/

予約文字がパーセントエンコードされているか、文字どおりに表示されているかのみが異なる URI は、問題の予約文字に予約目的がないと判断されない限り、通常は同等ではない (同じリソースを示す) と見なされます。この判断は、個々の URI スキームによって予約文字に対して確立されたルールに依存します。

予約されていないセットの文字はパーセントエンコードする必要はありません。

非予約文字がパーセントエンコードされているか、文字どおりに表示されているかだけが異なる URI は、定義上は同等ですが、実際には URI プロセッサがこの同等性を常に認識するとは限りません。たとえば、URI コンシューマはまたはを と異なるものとして扱うべきではありませんが、そうするものもあります。相互運用性を最大限に高めるため、URI プロデューサーは、非予約文字をパーセントエンコードしないことをお勧めします。 %41A%7E~

パーセント文字 ( %) はパーセントエンコードされたオクテットを示すために使用されるため、%25URI 内のデータとして使用するには、パーセント文字自体もパーセントエンコードされている必要があります。

ほとんどの URI スキームでは、 IP アドレスやファイル システムパスなどの任意のデータがURI のコンポーネントとして表現されます。URI スキーム仕様では、URI 文字とそれらの文字によって表現されるすべての可能なデータ値との間の明示的なマッピングが提供されるはずですが、多くの場合は提供されません。

1994 年に RFC 1738 が発行されて以来、URI でバイナリ データを表すスキームでは、データを 8 ビット バイトに分割し、各バイトを上記と同じ方法でパーセントエンコードする必要があることが規定されています。 ^[1]たとえば、バイト値 0x0F は で表す必要がありますが、バイト値 0x41 は、 または%0Fで表すことができます。英数字やその他の予約されていない文字には、エンコードされていない文字を使用することが通常推奨されます。これにより、URL が短くなります。 A%41

バイナリ データをパーセント エンコーディングする手順は、しばしば、時には不適切に、または完全に指定されないまま、文字ベースのデータに適用するために推測されてきました。World Wide Webの形成期には、ASCII レパートリーのデータ文字を扱い、パーセント エンコードされたシーケンスを決定するための基礎として ASCII の対応するバイトを使用していたため、この方法は比較的無害でした。文字とバイトは 1 対 1 でマッピングされ、互換性があると想定されていただけです。しかし、ASCII 範囲外の文字を表す必要性が急速に高まり、URI スキームとプロトコルは、URI に含める文字データを準備するための標準ルールを提供できないことがよくありました。その結果、Web アプリケーションは、パーセント エンコーディングの基礎として、さまざまなマルチバイト、ステートフル、およびその他の非 ASCII 互換のエンコーディングを使用するようになり、URI を確実に解釈することがあいまいになり、困難になりました。

たとえば、RFC 1738 および 2396 に基づく多くの URI スキームおよびプロトコルでは、データ文字が、未予約文字またはパーセントエンコードされたバイトによって URI で表現される前に、何らかの未指定の文字エンコードに従ってバイトに変換されることが前提となっています。スキームが、使用されたエンコードについて URI がヒントを提供することを許可していない場合、またはエンコードが ASCII を使用して予約文字と未予約文字をパーセントエンコードすることと競合する場合、URI は確実に解釈できません。一部のスキームではエンコードがまったく考慮されず、データ文字が URI 文字に直接マップされることが提案されています。この場合、予約セットにも未予約セットにも属さないデータ文字をパーセントエンコードするかどうか、またどのようにエンコードするかは実装に委ねられます。

任意の文字データはパーセントエンコードされ、パスワード難読化プログラムやその他のシステム固有の変換プロトコルなど、URI 以外の状況で使用されることがあります。

汎用 URI 構文では、URI 内の文字データの表現を提供する新しい URI スキームは、事実上、非予約セットの文字を変換せずに表現し、他のすべての文字をUTF-8に従ってバイトに変換してから、それらの値をパーセントエンコードすることを推奨しています。この提案は、2005 年 1 月に RFC 3986 の公開とともに導入されました。この日付より前に導入された URI スキームは影響を受けません。

現在の仕様では、エンコードされた文字データの扱いについては触れられていません。たとえば、コンピューターでは、文字データは何らかのレベルでエンコードされた形式で表現されるため、URI 文字にマッピングされるときにバイナリ データまたは文字データとして扱われる可能性があります。おそらく、この可能性を考慮してどちらか一方を要求するのは URI スキーム仕様次第ですが、実際には、実際にそうしている仕様はほとんどありません。

Unicode文字には非標準のエンコーディングが存在します。ここで、xxxxは4桁の16進数で表されるUTF-16コード単位です。この動作はRFCで指定されておらず、W3Cによって拒否されています。ECMA -262の第13版には、この構文を使用する関数がまだ含まれており、文字列にUTF-8エンコーディングを適用し、結果のバイトをパーセントエスケープします。^[2]%uxxxxescape

HTMLフォームに入力されたデータが送信されると、フォームのフィールド名と値がエンコードされ、GETまたはPOSTメソッドを使用してHTTPリクエストメッセージでサーバーに送信されるか、歴史的には電子メールで送信されます。^[3]デフォルトで使用されるエンコードは、一般的なURIパーセントエンコード規則の初期バージョンに基づいていますが、^[4]改行の正規化や、スペースを+ではなくに置き換えるなど、いくつかの変更が加えられています%20。このようにエンコードされたデータのメディアタイプapplication/x-www-form-urlencodedは であり、現在HTMLおよびXForms仕様で定義されています。さらに、CGI仕様には、Webサーバーがこのタイプのデータをデコードしてアプリケーションで使用できるようにする方法のルールが含まれています。

HTML フォーム データが HTTP GET リクエストで送信される場合、上記と同じ構文を使用して、リクエスト URI のクエリ コンポーネントに含められます。HTTP POSTリクエストまたは電子メールで送信される場合、データはメッセージの本文に配置され、application/x-www-form-urlencodedメッセージの Content-Type ヘッダーに含められます。

Wikifunctions にはURI パーセントエンコード機能があります。

Wikifunctions にはURI パーセントデコード関数があります。

• 国際化リソース識別子
• プニコード
• さまざまなエンコードアルゴリズムを比較するためのバイナリからテキストへのエンコード
• シェルコード
• ベース64

以下の仕様はすべて、予約文字、非予約文字、およびパーセントエンコーディングについて何らかの形で説明および定義しています。

• RFC 3986 / STD 66 (および正誤表)、現在の汎用 URI 構文仕様。
• RFC 2396 (廃止、および正誤表) と RFC 2732 (および正誤表) は、汎用 URI 構文仕様の以前のバージョンを構成していました。
• URLを定義する RFC 1738 (ほとんど廃止) および RFC 1808 (廃止) 。
• RFC 1630 (廃止)、最初の汎用 URI 構文仕様。
• 命名とアドレス指定に関する W3C ガイドライン: URI、URL、...
• URI における UTF-8 に関する W3C の説明
• W3C HTML フォームコンテンツタイプ