開発者ツール · URL エンコーダーとデコーダー
RFC 1738 から URL 標準へ: パーセント エンコーディング ルールはどのように進化したか
· 背景
URLエンコーディング rfc-history ウェブ標準
URL 内の文字をエスケープするためのルールは、1994 以降、何度か書き直されました。この投稿は、RFC 1738、RFC 2396、RFC 3986、および WHATWG URL Standard に従い、毎回の変更点について説明します。
RFC 1738 から URL 標準へ — パーセント エンコーディング ルールはどのように進化したか
チルダ (~) は、標準の世代や展開によってエンコード ルールがどのように変化するかを示しています。 RFC 1738 (1994) はどこでも %7E が必要です。 RFC 2396 (1998) はチルダを非予約に移動し、エンコードを解除できるようにしました。 RFC 3986 (2005) は予約されていないステータスを確認しました。 %7E を含む古い URL は引き続き有効です。新しいビルダーは ~ を出力します。進化は、Web の成熟とインフラストラクチャの標準化に伴う展開の教訓を反映しています。初期のインフラストラクチャは異種混合で多様だったため、RFC 1738 は保守的でした。
RFC 1738 は、1994 ブラウザーの動作を成文化しました。導入は UTF-8 で標準化されています。制限は不必要であることが判明した。後の標準では文字制限が緩和されました。 RFC 3986 では、予約されていない文字を安全にデコードできます。
RFC 1738 (1994): 「安全でない」文字と最初のエスケープ規則 - 危険とみなされたものとその理由
RFC 1738 では、「安全でない」文字を、URI 構文 (スペース、スラッシュ) と競合する文字、歴史的にプロトコルで使用されていた文字 (制御文字)、またはシステムが安全に送信できない文字として定義しました。保守的なリストは、現代のインターネットに必要な量をはるかに超えてパーセントでエンコードされています。初期のシステムの多くは RFC よりも前に存在しました。それは彼らの行動を体系化しました。プロトコルでは制御文字は本当に危険でした。スペースは、コマンド ラインから読み取る HTTP クライアントの送信上の問題でした。最新のシステムは、明示的なエンコードを通じてこれらのケースをより適切に処理します。
RFC 1738 に対してテストすると、古いシステムが期待していたことが明らかになります。 1990 年代の URL 仕様の文字をエンコードし、最新の RFC 3986 と比較します。違いは何がリラックスしたかを示しています。予約されていないセットは時間の経過とともに拡大しました。ハイフン、ピリオド、アンダースコアは常に安全でした。チルダを安全にするためには RFC 2396 が必要でした。保守的なアプローチは下位互換性を意味しました。 RFC 1738 ルールに基づいて構築された古い URL は、現在も有効です。 RFC 3986 セクション 6 の正規化により、不必要にパーセントエンコードされた予約されていない文字を安全にデコードできるようになります。
RFC 2396 (1998) — 予約済みと未予約、一般的な構文、およびチルダの修復
RFC 2396 (1998) は、RFC 1738 よりも厳密に文字セットを明確にしました。これは、URI 構造を提供する予約文字と、予約されていない文字をリテラル データとして形式化しました。ハイフン、ピリオド、アンダースコア、チルダを含む未予約の展開。スキーム固有のルールとは別に、一般的な URI 構文を認めました。 RFC 2396 では、gen-delims (:, /, ?, #, [, ], @) と sub-delims (!, $, &, ', (, ), *, +, ,, ;, =) の区別が導入されました。名前付けにより、予約文字が異なる構造的役割を持つ 2 つのグループに分けられることが明確になります。
RFC 2396 では、意味を変えずにデコードできるパーセントエンコード文字を指定する正規化ガイダンスが導入されました。予約されていない文字のデコードが正規化されます。予約された文字エンコーディング スティック。 RFC 3986 では表記がさらに簡略化されました。標準は下位互換性を徹底的に維持します。
RFC 3986 (2005) — ! * ' ( ) はサブデリムに移動し、ゲンデリムに名前が付けられ、正規化ガイダンスが到着します
RFC 3986 (2005) は、パーセント エンコーディングの最新の参照標準です。予約済み/unreserved の区別は維持されましたが、表記が簡略化され、正規化ガイダンスが追加されました。ティルダは明白に遠慮なく動いた。標準で明確化されたパーセントエンコードの未予約文字は、意味を変えることなくデコードできます。 RFC 3986 セクション 3 では、URI 構文が正確に説明されています。セクション 2 では、文字カテゴリを定義します。セクション 6 では、構文正規化に関する正式なルールを説明します。比較ベースの正規化では、正規化された形式が一致する場合、URI は同一であると見なされます。パスからドットセグメントを削除すると、意味が変わることなく正規化されます。
正規化は、分析、キャッシュ、リンク追跡にとって重要です。 16 進数の大文字と小文字のみが異なる URL (RFC 3986 では大文字が推奨されます) は、実際には同一である必要があります。正規化により、ログ エントリの重複やキャッシュ ミスが防止されます。正規化された URL をキーとしたキャッシュは、リクエスタのエンコード設定に関係なくコンテンツを提供します。 RFC 3986 正規化ガイダンスにより、システムは一貫した決定を行うことができます。しかし、厳格に施行すると、現在のインターネットで正常に機能する URL が壊れてしまいます。
WHATWG URL 標準: ブラウザーが実際に受信する内容の解析 — エンコード セット、特別なスキーム、およびエラー許容度
WHATWG URL 標準 (2016 – 現在) は、RFC 3986 に完全に従っていない URL のブラウザー エクスペリエンスから生まれました。ブラウザーは、エンコードされていないスペース、混合エンコード、癖に直面していました。 WHATWG では、理論的な文法ではなく、実際のブラウザーの解析について説明します。現実世界のブラウザは、スペースの許容、エスケープ文字の処理、不正な入力からの回復に関する実用的なルールを開発していました。 RFC 3986 は 2005 に到達し、正式な文法を定義しましたが、実際のブラウザーはすでにわずかに分岐していました。
WHATWG は、コンテキスト固有のルールを持つ 9 つのエンコード セットを定義します。パス内のスペースは %20 になります。ユーザー情報のスラッシュは %2F になります。ブラウザは、より狭い範囲の Web 標準を適用します。 RFC 3986 はベースラインを提供します。 WHATWG はそれに基づいて構築されます。
実用的な例: チルダ、スペース、および非 ASCII 文字を含む 1 つの URL — 各世代のルールがそれをエンコードする方法
国際化ドメインは Punycode エンコーディングを使用します (München は xn--mnchen-3ya になります)。パスとクエリでは引き続きパーセント エンコーディングが使用されます。ドメイン部分は Punycode を使用します。パスとクエリ部分ではパーセント エンコーディングが使用されます。レイヤーが混ざり合ったり、干渉したりすることはありません。
IDNA (アプリケーションにおける国際化ドメイン名) はホスト名の問題を解決します。 Punycode は、DNS との互換性を確保するために、非 ASCII を ASCII にエンコードします。 xn_ プレフィックスは、punycode エンコーディングを示します。アルゴリズムは決定的です。münchen は常に xn--mnchen-3ya になります。非 ASCII 文字は、DNS 解決の前に変換する必要があります。 DNS の制約とラベルの制限により、パーセント エンコーディングはホスト名に対しては機能しません。それぞれのアプローチは異なる問題を正しく解決します。標準は正当な理由で個別に進化しました。
これでカバーされないもの — IRI および独自の歴史を持つ国際化ドメイン名
標準の選択はコンテキストによって異なります。ブラウザ用の URL を構築しますか? RFC 3986 に従います。ブラウザはWHATWGを適用します。古いシステムですか？テスト実装。進化を理解すれば混乱を防ぐことができます。
最新のビルダーは、状況に応じて RFC 3986 または WHATWG に従う必要があります。古い URL と新しい URL が共存するため、互換性については慎重に考慮する必要があります。 URL エンコーダーとデコーダーは RFC 3986 に従っており、ブラウザーの動作とは別に固定参照を提供します。 WHATWG は、RFC の基本を超えてコンポーネント固有のエンコーディング セットを追加します。何がいつ変更されたのかを知ることは、システムが一致しない理由を理解するのに役立ちます。両方の標準を使用して URL をテストすると、環境内でどの標準が制御しているかがわかります。どちらの基準も正しいです。
要点: コードがどのルールブックに従っているかを知る — URL エンコーダーとデコーダーが固定参照点として RFC 3986 の動作をどのように提供するか
RFC 3986 正規化により、不必要にパーセントエンコードされた予約されていない文字を安全にデコードできるようになります。 %41 は A に正規化されます。%2F のようなエンコードされた予約文字はデコードされません。意味を変えると構造が壊れる。標準化団体は下位互換性を熱心に維持しています。修正には世界規模の調整が必要で、数十年経っても不可能だ。標準書籍は遡ってウェブを破壊するものではありません。エンコーディングの決定を変更すると、数十億の既存システムが同時に破壊されます。
パーセント エンコーディングは、RFC 1738 から RFC 2396 および RFC 3986 を経て、最新の WHATWG URL Standard に至るまで、30 年にわたる慎重な進化を経てきました。最新のコードは、RFC 3986 ベースラインに従う必要があります。以前のエンコードを使用した古い URL は引き続き有効です。ラウンドトリップをテストすることで、正確性と互換性が保証されます。