開発者ツール · URL エンコーダとデコーダ
encodeURI と encodeURIComponent: それぞれどの文字をそのままにするか
· 仕組み
URLエンコーディング JavaScript 開発者のワークフロー
2 つの JavaScript 関数にはちょうど 11 文字の違いがあり、間違った関数を選択すると URL が壊れるか、値のエスケープに失敗します。この投稿ではセットについて詳しく説明し、覚えておくとよいルールを示します。
「R&D」の & がクエリを分割したため、すべてが返された検索 - 間違った関数による具体的なバグ
コードが手作業で ?q=R&D を構築している場合、R&D を検索すると誤って R の結果が返されることがあります。アンパサンドはクエリ パラメータ間の区切り文字です。値をエンコードしない限り、q の一部として保持されません。その小さな部分に対して encodeURI を選択すると、サーバーのバグではなくエラーになります。多くの場合、アプリケーション コードで最も安全なオプションは URLSearchParams ですが、2 つの JavaScript プリミティブを理解すると、既存のコードのデバッグがはるかに簡単になります。
両方の関数が共有するもの - 決して触れない予約されていないセットと、両方が適用する UTF-8 パーセント エンコーディング
どちらの方法でも、ASCII 文字、数字、および予約されていない句読点 (_ ) はそのまま残ります。 ！ ~ * ' ( ) は JavaScript のエンコード規則では変更されません。パーセント トリプレットを書き込む前に、非 ASCII 文字を UTF-8 bytes に変換します。é は単一の Latin-1 byte ではなく、%C3%A9 になります。また、スペースも %20 としてエンコードされます。パーセントエンコーディングは、URI の構造を維持することです。これは、HTML エスケープ、入力検証、または受信ページ上の悪意のあるスクリプトに対する保護ではありません。
encodeURI で保持される 11 文字のみ — ; 、/? : @ & = + $ # そして、それぞれが URL 内で構造的な意味を持つ理由
encodeURI は、encodeURIComponent がエンコードする 11 個の構造文字をさらに保持します。 、/? : @ & = + $ #。完全なアドレスの場合、スラッシュと疑問符をそのままにしておくと、そのパスとクエリ構文が保持されます。クエリ値の場合、& または = を使用するとパラメーター リストが変更されますが、エスケープされていない # はフラグメントを開始できます。関数が異なるのは、1 つはアドレス全体を対象とし、もう 1 つはそのアドレス内のコンポーネントを対象とするためです。
当てはまるルール: 値は encodeURIComponent を取得し、完全な URL は encodeURI を取得 — そして「完全な URL」が思っているよりも珍しい理由
ほとんどの場合、値は encodeURIComponent を取得します。完全ですでに構造化されたアドレスは、encodeURI ではあまり一般的ではありません。プログラムで構築している URL の場合、エンコードされた部分と生の部分を組み合わせて連結するのではなく、URL API を使用してパスと検索パラメータを処理します。 encodeURIComponent を使用して URL 全体をエンコードし、その後スラッシュとコロンが区切り文字として動作し続けることを期待しないでください。逆に、encodeURI を通じてユーザーのクエリ用語をフィードせず、アンパサンドをアクティブのままにしておきます。
実用的な例: 両方の関数を使用した同じ文字列 — スペース、&、/、およびアクセントを含む値の出力の表
R&D / カフェを 1 つのクエリ値として取り上げます。 encodeURIComponent は R%26D%20%2F%20caf%C3%A9 を返し、アンパサンドとスラッシュを保護します。 encodeURI は、構造的な句読点を保持して R&D%20/%20caf%C3%A9 を返します。単純な ?q= 接頭辞により、意図しない区切り文字が作成される可能性があります。どちらもスペースとアクセントをエンコードするため、「hello world」のみを使用したテストでは重要な違いが見逃されます。 ToolAcre で生成された文字列を比較し、URL パーサーに貼り付けて、表示されるクエリ パラメーターの数を確認します。
よくある間違い — encodeURIComponent を使用して完全な URL をエンコードし、間違った対応物を使用してデコードする
完全な URL を 1 つのコンポーネントとしてエンコードすると、消費者が :// を期待するところに %3A%2F%2F が生成されます。検証する前にアドレス全体をデコードすると、新しい意味を持つ予約された区切り文字が再導入される可能性があります。また、既に %26 を含む値を二重エンコードすることも避けてください。パーセント記号自体が %25 になる可能性があるため、2 番目のデコード層の意味が再び変わる可能性があります。コンポーネントの encodeURIComponent と decodeURIComponent をペアにして、不正なパーセント エスケープを入力エラーとして処理します。
これでカバーされないもの — + を使用したフォーム エンコーディング、および URLSearchParams を使用した URL の構築
HTML フォーム クエリのエンコードでは、application/x-www-form-urlencoded 内のスペースにプラス記号が使用されます。これは、これら 2 つの関数の %20 出力とは異なります。 URLSearchParams はこれらのフォーム ルールを処理します。この記事では、パスの正規化、Unicode ホスト名の変換、またはデコードされた URL が安全にリクエストできるかどうかの判断については説明しません。 URL エンコードは表現ステップであり、認可ポリシーではありません。
要点: 全体ではなく部分をエンコードする — URL エンコーダーとデコーダーが両方のモードを表示して、独自の入力で違いを確認できるようにする方法
覚えやすい境界は部分と全体です。パラメータ値は部分であるため、encodeURIComponent または URLSearchParams を使用します。 URL エンコーダとデコーダは、同じ文字列に対する両方のブラウザ関数を表示し、実験をローカルに保ちます。 2 つのエンコーダが交換可能であると判断する前に、&、=、#、スラッシュ、およびアクセントを含む入力をテストします。