開発者ツール · URL エンコーダーとデコーダー
RFC 3986 予約文字と予約されていない文字: URI 標準の規定
· 背景
URLエンコーディング rfc3986 パーセントエンコーディング
RFC 3986 は文字を予約済み、未予約、その他すべてに分割しており、その分割によって、これまでに満たしたすべてのパーセント エンコーディング ルールが説明されています。この投稿では、関連するセクションをわかりやすく説明します。
RFC 3986 予約文字と予約されていない文字 - URL を構築するときに重要なこと
RFC 3986 は、文字を 3 つのカテゴリ (未予約、予約、およびエンコードする必要があるその他すべて) に分類します。予約されていない文字 (文字、数字、ハイフン、ピリオド、アンダースコア、チルダ) はエンコードする必要がありません。 RFC はこれらをセクション 2.3 に明示的にリストし、どの URI コンテキストでもエンコードしないままにしても安全であると述べています。これらの文字を URL エンコーダとデコーダでテストすると、変更されずに通過することがわかります。予約文字は gen-delims (: / ? # [ ] @) と sub-delims (! $ & ' ( ) * + , ; =) に細分され、それぞれが異なる URL コンポーネントで構造的な意味を持ちます。
文字のエンコードが必要になるのはどのような場合ですか?予約文字は、あいまいさが生じる場合にのみパーセント エンコードする必要があります。スラッシュはパス セグメントを示します。クエリ値では %2F である必要があります。アンパサンドはパラメータを区切ります。値の & には %26 が必要です。予約されていない文字はエンコードする必要がありません。ハイフンはハイフンのままです。 URL 標準により、正しい解析が保証されます。 URL エンコーダとデコーダを使用したテスト: encodeURIComponent で「hello/world"」と入力すると、「hello%2Fworld」が生成されますが、encodeURI ではスラッシュが保持されます。
未予約: 文字、数字、ハイフン、ピリオド、アンダースコア、チルダ - エンコードを必要とせず、エンコードすべきでない文字
パーセント エンコードでは %HH が使用されます。HH は 16 進表記です。 ASCII 文字 A (コード 65) は %41 になります。非 ASCII é には UTF-8 エンコードが必要です: é (U+00E9) は %C3%A9 になります。最新の標準では、ブラウザ間で一律に UTF-8 を指定しています。
完全な URL には構造構文がそのままである必要があります。クエリ値には無害な内部予約文字が必要です。クエリ パラメータ ?q=R&D は、手動の場合は & を %26 としてエンコードする必要があります。それ以外の場合は、アンパサンドが区切り文字になります。スラッシュを含む値は、コンポーネント モードでは %2F になります。コンポーネントのエンコード (encodeURIComponent) は、予約されていない文字、数字、および - _ を除くすべてをエンコードすることでこれを処理します。 ！ ～ * ' ( )。テストでは、メソッド間の違いが明確に示されます。
予約済み: gen-delims と sub-delims — 2 つのグループ、そのメンバー、および構造的役割
クエリ文字列は、予約文字が重要である理由を示しています。アンパサンドは key=value ペアを区切ります。 ?utm_source=email&utm_campaign=sale は 2 つのパラメータを意味します。値内では、エスケープされていないアンパサンドがペアを終了します。 「等号」はキーと値を区切ります。解析は複数のレイヤーで行われます。それぞれに同じルールが適用されます。
クエリ値でエンコードが必要な文字には、アンパサンド、等号、ハッシュ、疑問符、スペース、非 ASCII 文字が含まれます。ハッシュは最も卑劣です。#anything はフラグメント識別子になり、サーバーに送信されることはありません。ハッシュで終わるキャンペーン名は、リクエストがブラウザを離れる前に、ハッシュ以降のすべてを失います。スペースは %20 になる必要があります。 URL エンコーダとデコーダを使用してテストすると、コンポーネント モードとフォーム モードが表示されます。位置を理解することでエンコードの必要性が決まります。
予約文字をエンコードする必要がある場合 - コンポーネントごとに、区切り文字と間違われる可能性がある場合のみ
パーセントエンコーディングは RFC 3986 に存続します。予約されていないセットは小さいままなので、持ち運びが容易です。パーセントエンコードされた予約されていない文字は、意味を変更せずにデコードできます。 A は予約されていないため、%41 を A にデコードすることは正しいです。スラッシュが区切り文字ではなくデータである場合、%2F を / にデコードすると意味が変わります。 RFC 3986 正規化セクション 6 では、構文的なアプローチについて説明します。
異なる位置にある予約文字には異なる役割があります。スキーム内のコロンは、スキーム:権限境界をマークします。 userinfo のコロンはデータです。疑問符はクエリ セクションを開きます。クエリ値のスラッシュはリテラルです。ハッシュ マークのフラグメントの開始。位置によってエンコードの必要性が決まります。クエリ文字列には、それ自体が URI である値が含まれます。 https://example.com/page?param=value のようなリダイレクト URL をパラメーターとしてエンコードするには、スラッシュとコロンを %2F および %3A にエンコードする必要があります。コンテキストは常に安全な文字を定義します。
作業例: 実際の URL のすべての文字の分類 — 未予約、区切り文字として予約、データとして予約
RFC 1738 (1994) では、多くの文字が安全ではないとみなされました。 UTF-8 で展開が標準化されると、その後の標準では制限が緩和されました。チルダ (~) は進化の例です。RFC 1738 は %7E が必要で、RFC 2396 (1998) はチルダを未予約に移動し、RFC 3986 は未予約ステータスを確認しました。進化は展開の教訓を反映しています。標準は下位互換性を維持します。
RFC 正規化により、不必要にパーセントでエンコードされた予約されていない文字のデコードが許可されます。 %41 は安全に A に正規化されます。%2F のようなエンコードされた予約文字はデコードされません。意味を変えると構造が壊れる。最新のコンセンサスでは、RFC 3986 を参照ベースラインとして使用します。 URL エンコーダーとデコーダーは RFC 3986 に従い、ブラウザーの動作とは別に固定参照を提供します。 WHATWG URL Standard は、RFC を超えてコンポーネント固有のエンコーディング セットを追加します。一般的な URL 解析には RFC 3986、Web ブラウザには WHATWG という標準が共存しています。図書館は異なります。ドキュメントを確認してください。
セクション 6 の正規化ガイダンス — 16 進数のケース、予約されていないデコードおよびパス セグメントのルール
RFC 3986 に対するテストにより、URL が数十年にわたるソフトウェア全体で動作することが保証されます。 URL エンコーダとデコーダは、構築されたコンポーネントに適用する RFC 3986 エンコード ベースラインを提供します。 URL ライブラリにおけるすべてのエンコーディングの決定について説明した標準ドキュメントを読んでください。 WHATWG URL は、RFC 3986 を完全に置き換えるのではなく、それに基づいて構築されています。一般的なブラウザ用の URL を構築しますか? RFC 3986 に従ってください。ブラウザは WHATWG ルールを最上位に適用します。古いシステムですか？実際の実装をテストします。保存のために正規化していますか? RFC 3986 を一貫して適用します。予約済み/unreserved の区別を理解することで、安全な文字がわかります。
URL エンコードはセキュリティサニタイズではありません。 SQL、HTML、JavaScript、URI などの各コンテキストには、独自の出力エンコーディングが必要です。パーセントエンコーディングは URL 構造のみを保護します。適切なレイヤーで適切なディフェンスを適用します。
これでカバーされないもの — WHATWG URL 標準のさまざまなエンコード セットと IRI の処理
RFC 2396 (1998) は、RFC 1738 よりも厳密に文字セットを明確にしました。 URI 構造を提供する予約文字と、予約されていない文字をリテラル データとして形式化しました。元の定義にハイフン、ピリオド、アンダースコア、チルダを含む未予約の拡張。 RFC 2396 では、gen-delims (:, /, ?, #, [, ], @) と sub-delims (!, $, &, ', (, ), *, +, ,, ;, =) の区別が導入されました。各グループは URL 内で異なる構造的役割を持っています。名前付けにより、予約文字が 2 つのグループに分けられることが明確になります。名前を知っておくと、技術的な議論に役立ちます。
RFC 3986 (2005) は最新のリファレンスです。予約済み/unreserved の区別は維持しましたが、表記は簡素化されました。標準化団体は遡ってウェブを破壊することはありません。標準を意識してエンコードしてください。 URL エンコーダとデコーダは、RFC 3986 リファレンスを提供します。
要点: 標準は短くて正確です — URL エンコーダーとデコーダーの 2 つのモードがデータのエンコードと区切り文字の保持にどのように対応するか
標準の選択はコンテキストによって異なります。一般的なブラウザ用の URL を構築しますか? RFC 3986 に従います。ブラウザは WHATWG ルールを適用します。古いシステムですか？実際の実装をテストします。保存のために正規化していますか? RFC 3986 を一貫して適用します。パーセント エンコーディング ルールは、保守的な RFC 1738 から、明確化された RFC 2396 および RFC 3986 を経て、階層化された WHATWG URL Standard に進化しました。各世代には経験が反映されています。最新のビルダーは、状況に応じて RFC 3986 または WHATWG に従っています。古い URL と新しい URL が共存するには、互換性を考慮する必要があります。カテゴリを理解することで、エンコードミスを防ぐことができます。
導入前に URL が正しくエンコードされていることを確認します。 URL エンコーダとデコーダは、RFC 3986 ルールをエンドツーエンドで実証します。正確な 16 進値を確認し、どの文字がエンコードされているかを理解します。このツールは、部分を連結して URL を構築する場合に使用します。 RFC 3986 予約済みカテゴリと予約されていないカテゴリは、一貫した URI 解析のために文字セットを分割します。