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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

URIでのパーセントエンコード

URI文字の種類

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

RFC 3986セクション2.2予約文字(2005年1月)
! # $ & ' ( ) * + , / : ; = ? @ [ ]
RFC 3986セクション2.3予約されていない文字(2005年1月)
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

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

予約文字

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

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

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

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

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

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

予約されていない文字

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

予約されていない文字がパーセントエンコードされているか、文字通り表示されるかによってのみ異なるURIは、定義上同等ですが、実際には、URIプロセッサは常にこの同等性を認識するとは限りません。たとえば、URIコンシューマーはとは異なる方法で処理するべきではありませんが、一部のコンシューマーは同様に処理する必要があります。相互運用性を最大化するために、URIプロデューサーは予約されていない文字をパーセントエンコードすることをお勧めしません。 %41A%7E~

パーセント文字

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

任意のデータ

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

バイナリデータ

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

文字データ

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

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

パーセントエンコード後の一般文字(ASCIIまたはUTF-8ベース)
newline space " % - . < > \ ^ _ ` { | } ~ £
%0A または %0D または %0D%0A %20 %22 %25 %2D %2E %3C %3E %5C %5E %5F %60 %7B %7C %7D %7E %C2%A3 %E5%86%86

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

現在の標準

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

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

非標準の実装

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

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

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

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

も参照してください

参考文献

  1. ^ RFC1738§2.2; RFC2396§2.4; RFC3986§1.2.1、2.1、2.5
  2. ^ 「ECMAScript2017言語仕様(ECMA-262、第8版、2017年6月)」Ecmaインターナショナル。
  3. ^ フォームアクションとして「mailto」 URLを使用する電子メールベースのHTMLフォーム送信のユーザーエージェントサポートは、HTML3.2の時代にRFC1867セクション5.6で提案されました。さまざまなWebブラウザが、別の電子メールプログラムを呼び出すか、独自の基本的なSMTP機能を使用して実装しました。信頼できない場合もありますが、WebサーバーやCGIスクリプトを使用せずにフォームデータを送信する簡単な方法として一時的に人気がありました
  4. ^ Berners-Lee、T。(1994年6月)。「RFC1630」IETFツールIETF 2016年6月29日取得

外部リンク

次の仕様はすべて、何らかの形式で予約文字、予約されていない文字、およびパーセントエンコードについて説明および定義しています。

  • RFC  3986 / STD 66(および正誤表)、現在の汎用URI構文仕様。
  • RFC  2396(廃止されたプラスエラッタ)とRFC 2732(プラスエラッタ)は一緒になって、以前のバージョンの汎用URI構文仕様を構成していました。
  • URLエンコーダーオンライン-ファイルまたはテキストをURLエンコード形式に変換するためのさまざまなオプションを備えたWebサイト。
  • URLデコーダーオンライン-ファイルまたはテキストをURLデコード形式に変換するためのさまざまなオプションを備えたWebサイト。