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

URLエンコーディング（パーセントエンコーディングとも呼ばれる）は、URI（Uniform Resource Identifier）内で有効なUS-ASCII文字のみを使用して、任意のデータをURI（ Uniform Resource Identifier）にエンコードする手法です。パーセントエンコーディングは、特殊文字がURIの構造や解釈に影響を与えないようにするために使用されます。特殊文字は、パーセント記号（%）に、その文字のバイト値を表す2桁の16進数で置き換えられます。例えば、スペースは通常、次のようにエンコードされます。 %20

  • オリジナル: http://example.com/my file.txt
  • エンコード: http://example.com/my%20file.txt

URLエンコーディングとして知られていますが、より一般的には、 Uniform Resource Identifier (URI)セット（Uniform Resource Locator (URL)とUniform Resource Name (URN)の両方を含む）内でも使用されます。したがって、application/x-www-form-urlencodedメディアタイプのデータの準備にも使用され、 HTTPリクエストでHTMLフォームデータを送信する場合によく使用されます。パーセントエンコーディングでは、大文字と小文字は区別されません。

種類

URIにおけるパーセントエンコーディング

URI文字の種類

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

RFC 3986 セクション 2.2予約文字(2005 年 1 月)
!#$&'()*+,/:;=?@[]
RFC 3986 セクション 2.3非予約文字(2005 年 1 月)
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789-_~.

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

予約文字

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

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

パーセントエンコード後の予約文字
!#$&'()*+,/:;=?@[]
%21%23%24%26%27%28%29%2A%2B%2C%2F%3A%3B%3D%3F%40%5B%5D

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

例えば、 URIの「query」コンポーネント（文字の後ろの部分）では、は依然として予約文字とみなされますが、特定の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 文字に直接マップされることが示されるだけであり、予約セットにも未予約セットにも含まれないデータ文字をパーセントエンコードするかどうか、またどのようにパーセントエンコードするかは実装に委ねられています。

パーセントエンコード後の一般的な文字（ASCII または UTF-8 ベース）
␣"%-.<>\^_`{|}~£€
%20%22%25%2D%2E%3C%3E%5C%5E%5F%60%7B%7C%7D%7E%C2%A3%E2%82%AC

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

現在の標準

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

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

非標準実装

Unicode文字には非標準のエンコーディングが存在します。ここで、xxxxは4桁の16進数で表されるUTF-16コード単位です。例えば、ECMA-262の第13版には、この構文を使用する関数が含まれています。[ 4 ]しかし、この動作はどのRFCでも規定されておらず、W3Cによって拒否されています。[ 5 ]%uxxxxescape

application/x-www-form-urlencoded タイプ

HTMLフォームに入力されたデータが送信されると、フォーム フィールドの名前と値がエンコードされ、GETまたはPOSTメソッドを使用して HTTP 要求メッセージでサーバーに送信されるか、歴史的には電子メールで送信されます。[注 1 ]デフォルトで使用されるエンコードは、一般的な URI パーセントエンコード規則の初期バージョンに基づいていますが、[ 6 ]改行の正規化や、スペース+を ではなくに置き換えるなどの変更が加えられています%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 パーセント デコード関数があります。

注記

  1. ^ HTML 3.2時代のRFC 1867セクション5.6で、フォームアクションとして「mailto」 URLを使用するメールベースのHTMLフォーム送信のためのユーザーエージェントサポートが提案されました。様々なウェブブラウザが、別のメールプログラムを起動するか、独自の基本的なSMTP機能を使用することでこれを実装しました。信頼性が低い場合もありましたが、ウェブサーバーやCGIスクリプトを介さずにフォームデータを送信できる簡単な方法として、一時的に人気を博しました。 

参考文献

  1. ^ T. Berners-Lee ; L. Masinter ; M. McCahill (1994年12月). Uniform Resource Locators (URL) . Network Working Group. doi : 10.17487/RFC1738 . RFC 1738 .廃止。セクション2.2。RFC 4248 および4266により廃止。RFC 1808、2368、2396、3986、6196、6270 および8089により更新。​​​​​​
  2. ^ T. Berners-Lee ; R. Fielding ; L. Masinter (1998年8月). Uniform Resource Identifiers (URI): Generic Syntax . Network Working Group. doi : 10.17487/RFC2396 . RFC 2396 .廃止。2.4節。RFC 3986により廃止。RFC  2732 により更新。RFC 1808 および1738を更新。
  3. ^ T. Berners-Lee ; R. Fielding ; L. Masinter (2005年1月). Uniform Resource Identifier (URI): Generic Syntax . Network Working Group. doi : 10.17487/RFC3986 . STD 66. RFC 3986 .インターネット標準66。セクション1.2.1、2.1、2.5。RFC 2732、2396、1808は 廃止。RFC 6874、7320、8820 により更新。RFC 1738 を更新。​​
  4. ^ 「ECMAScript 2017 言語仕様 (ECMA-262、第8版、2017年6月)」。Ecma International。2018年7月2日時点のオリジナルよりアーカイブ。 2018年6月20日閲覧。
  5. ^デュアスト、マーティン;ミシェル・シュイニャール（2004年11月30日）。「国際化リソース識別子 (IRI)」。w3.org 。2025 年9 月 17 日に取得。
  6. ^ Berners-Lee, Tim (1994年6月). 「WWWにおけるユニバーサルリソース識別子：ワールドワイドウェブで使用されるネットワーク上のオブジェクトの名前とアドレスを表現するための統一構文」 . ネットワークワーキンググループ. doi : 10.17487/RFC1630 . RFC 1630 .情報提供。

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

「 https://en.wikipedia.org/w/index.php?title=Percent-encoding&oldid=1332571559」から取得