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

URL エンコーディング(正式にはパーセントエンコーディングとして知られています) は、 URI 内で有効な限られたUS-ASCII文字のみを使用して、 Uniform Resource Identifier (URI)内の任意のデータをエンコードする方法です。これはURL エンコーディングとして知られていますが、より一般的には、 Uniform Resource Locator (URL) とUniform Resource Name (URN)の両方を含むメインのURI (Uniform Resource Identifier ) セット内でも使用されます。そのため、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進数のペアとして表現します(16 進数が 1 つある場合は、先頭にゼロが追加されます)。数字の前にエスケープ文字としてパーセント記号( %)が付いている、予約文字の代わりに URI で使用されます。(非 ASCII 文字の場合、通常はUTF-8のバイト シーケンスに変換され、各バイト値は上記のように表されます。)

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

パーセントエンコーディング後の予約文字
! " # $ % & ' ( ) * + , / : ; = ? @ [ ]
%20 %21 %22 %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 スキームには、 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 文字に直接マッピングされることを示唆しているだけです。そのため、予約セットにも予約されていないセットにも含まれていないデータ文字をパーセント エンコードするかどうか、およびその方法を決定するのは実装に任されています。

パーセントエンコード後の一般的な文字 (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に従ってバイトに変換し、その後パーセントに変換する必要があることを推奨しています。 -それらの値をエンコードします。この提案は、RFC 3986 の発行に伴い 2005 年 1 月に導入されました。この日より前に導入された URI スキームは影響を受けません。

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

非標準の実装

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

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

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

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

こちらも参照

参考文献

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

外部リンク

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

  • 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 フォームのコンテンツ タイプ

さまざまな実装:

  • DevPal URL エンコーダ – URL エンコードをサポートするオンライン開発者ツール。
  • オンライン URL エンコーダおよびデコーダ – ブラウザ内で URL をエンコードまたはデコードします。
  • URL エンコーダー オンライン – ファイルやテキストを URL エンコード形式に変換するためのさまざまなオプションを備えた Web サイト。
  • URL エンコードとデコード - オンライン – ファイルやテキストを URL エンコード形式に変換するためのさまざまなオプションを備えた Web サイト。