Loading article…
パーセントエンコーディング（ URLエンコーディングとも呼ばれる）は、URI内で使用可能なUS-ASCII文字のみを使用して、任意のデータをURIにエンコードする方法です。パーセントエンコーディングは、特殊文字がURIの構造や解釈に影響を与えないようにするために使用されます。特殊文字は、パーセント記号（%）とその文字のバイト値を表す2桁の16進数に置き換えられます。たとえば、スペースは一般的に次のようにエンコードされます。%20
http://example.com/my file.txthttp://example.com/my%20file.txtURLエンコーディングとして知られていますが、Uniform Resource Identifier (URI) セット（Uniform Resource Locator (URL) とUniform Resource Name (URN) の両方を含む）の中でもより一般的に使用されています。そのため、 HTTPリクエストでHTMLフォームデータを送信する際などによく使用されるapplication/x-www-form-urlencodedメディアタイプのデータの準備にも使用されます。パーセントエンコーディングでは大文字と小文字は区別されません。
URI で使用できる文字は、予約文字と非予約文字（またはパーセントエンコーディングの一部としてのパーセント文字）に分けられます。予約文字とは、特別な意味を持つ文字のことです。例えば、スラッシュ文字は URL（より一般的には URI）の異なる部分を区切るために使用されます。非予約文字には、そのような意味はありません。パーセントエンコーディングでは、予約文字は特殊な文字シーケンスで表現されます。予約文字と非予約文字のセット、および特定の予約文字が特別な意味を持つ状況は、URI および URI スキームを規定する仕様が改訂されるたびに、わずかに変更されています。
URI内のその他の文字はパーセントエンコードする必要があります。
予約文字セットに含まれる文字（「予約文字」）が特定のコンテキストで特別な意味（「予約目的」）を持ち、URI スキームでその文字を別の目的で使用する必要があると規定されている場合、その文字はパーセントエンコードする必要があります。予約文字のパーセントエンコードとは、文字を対応するASCIIバイト値に変換し、その値を16 進数の 2 桁で表すことを意味します（16 進数が 1 桁の場合は、先頭にゼロが追加されます）。これらの数字は、エスケープ文字としてパーセント記号( %)を付けて、URI 内で予約文字の代わりに使用されます。（非 ASCII 文字は通常、UTF-8バイトシーケンスに変換され、各バイト値は上記のように表されます。）
予約文字は/、たとえばURIの「パス」コンポーネントで使用される場合、パスセグメント間の区切り文字 として特別な意味を持ちます。特定の URI スキームに従って、パスセグメント内にが必要な場合は、生の の代わりに、3 つの文字または をセグメント内で使用する必要があります。/%2F%2f/
特定の文脈において予約された目的を持たない予約文字もパーセントエンコードされることがありますが、意味的にはそうでない文字と違いはありません。
URIの「クエリ」コンポーネント（文字の後の部分）では?、例えば、/は予約文字とみなされますが、特定のURIスキームで別途規定されていない限り、通常は予約目的はありません。予約目的がない場合、この文字をパーセントエンコードする必要はありません。
予約文字がパーセントエンコードされているか、そのまま表示されているかのみが異なるURIは、通常、同等（同じリソースを示す）とはみなされません。ただし、当該予約文字に予約目的がないと判断できる場合はこの限りではありません。この判断は、個々のURIスキームによって定められた予約文字に関する規則に依存します。
予約されていない文字セットの文字は、パーセントエンコードする必要は一切ありません。
予約されていない文字がパーセントエンコードされているか、文字がそのまま表示されるかのみが異なるURIは、定義上は同等ですが、実際にはURIプロセッサがこの同等性を常に認識するとは限りません。たとえば、URIコンシューマーは、とを区別して扱うべきではありませんし、とを区別して扱う場合もありますが、そうする人もいます。相互運用性を最大限に高めるため、URIプロデューサーは予約されていない文字をパーセントエンコードしないことが推奨されます。%41A%7E~
パーセント記号（%）はパーセントエンコードされたオクテットを示す役割を果たすため、%25URI 内のデータとして使用するには、パーセントエンコードされている必要があります。
ほとんどのURIスキームでは、IPアドレスやファイルシステムパスなどの任意のデータをURIの構成要素として表現します。URIスキームの仕様では、URI文字と、それらの文字によって表現される可能性のあるすべてのデータ値との間の明示的なマッピングが規定されるべきですが、実際には規定されていない場合がほとんどです。
1994 年に RFC 1738 が公開されて以来、URI でバイナリ データの表現を提供するスキームでは、データを 8 ビット バイトに分割し、上記と同じ方法で各バイトをパーセント エンコードする必要があると規定されています。 [ 1 ] [ 2 ] [ 3 ]例えば、バイト値 0x0F は で表現する必要がありますが、バイト値 0x41 は、または%0Fで表現できます。英数字やその他の予約されていない文字にはエンコードされていない文字を使用することが、URL が短くなるため、一般的に推奨されます。A%41
バイナリデータのパーセントエンコードの手順は、文字ベースのデータにも適用されるよう拡張されることが多く、その拡張方法は不適切であったり、十分に規定されていなかったりする場合がある。ワールドワイドウェブの黎明期には、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に従ってバイトに変換し、それらの値をパーセントエンコードすることを推奨しています。この提案は、RFC 3986の公開に伴い、2005年1月に導入されました。この日付より前に導入されたURIスキームは影響を受けません。
現在の仕様では、エンコードされた文字データの扱いについては規定されていません。例えば、コンピュータでは、文字データは何らかのレベルでエンコードされた形式で現れるため、URI文字にマッピングする際にバイナリデータまたは文字データとして扱われる可能性があります。おそらく、URIスキームの仕様でこの可能性を考慮し、どちらか一方を要求するのが一般的ですが、実際には、そうしている仕様はほとんどありません。
Unicode文字には、非標準のエンコーディングが存在します。、ここでxxxxは 4 つの 16 進数で表されるUTF-16コード単位です。たとえば、ECMA-262の第 13 版には、この構文を使用する関数が含まれています。[ 4 ]ただし、この動作はどの RFC でも規定されておらず、W3C によって却下されています。[ 5 ]%uxxxxescape
HTMLフォームに入力されたデータが送信されると、フォームのフィールド名と値がエンコードされ、GETまたはPOSTメソッドを使用した HTTP リクエスト メッセージでサーバーに送信されます。または、従来は電子メールで送信されていました。[注 1 ]デフォルトで使用されるエンコードは、一般的な URI パーセント エンコード ルールの初期バージョンに基づいています。[ 6 ]改行の正規化やスペースを の+代わりにに置き換えるなど、いくつかの変更が加えられています%20。このようにエンコードされたデータのメディア タイプapplication/x-www-form-urlencodedは であり、これは現在 HTML およびXForms仕様で定義されています。さらに、CGI仕様には、Web サーバーがこのタイプのデータをデコードしてアプリケーションで使用できるようにする方法に関するルールが含まれています。
HTTP GETリクエストでHTMLフォームデータが送信される場合、上記と同じ構文を使用してリクエストURIのクエリコンポーネントに含まれます。HTTP POSTリクエストまたは電子メールで送信される場合、データはメッセージ本文に配置され、application/x-www-form-urlencodedメッセージのContent-Typeヘッダーに含まれます。
以下の仕様書はすべて、何らかの形で予約文字、非予約文字、およびパーセントエンコーディングについて説明し、定義しています。