URLエンコーディング:知っておくべきすべてのこと
· 12分で読めます
目次
URLエンコーディングの理解
URLエンコーディングは、パーセントエンコーディングとも呼ばれ、インターネット上で信頼性の高いデータ転送を保証するための基本的なメカニズムです。これは、URLで許可されていない文字を、Webブラウザ、サーバー、その他のインターネットインフラストラクチャによって安全に送信および解釈できる形式に変換します。
その核心において、URLエンコーディングはシンプルな問題に対処します。URLには、ASCII文字セットからの限られた文字セットのみを含めることができます。このセット外の文字(特殊記号、スペース、非ラテン文字など)を含める必要がある場合、それらは普遍的に認識される形式にエンコードする必要があります。
エンコーディングプロセスは、問題のある文字をパーセント記号(%)とそれに続く文字のASCIIまたはUTF-8コードを表す2桁の16進数に置き換えます。これにより、URLのすべてのコンポーネントが、誤解釈やデータ損失なしに意図したとおりに正確に送信されることが保証されます。
クイックヒント: コードを書かずに任意のURL文字列を即座にエンコードまたはデコードするには、URLエンコーダー&デコーダーツールを使用してください。
URLエンコーディングが必要な理由
URLエンコーディングの必要性は、インターネットの元の設計上の制約と、RFC 3986で定義されたURL仕様に由来します。URLは、異なるシステム、プロトコル、地理的地域間での互換性を確保するために、限られた文字セットで動作するように設計されました。
URLエンコーディングがなければ、いくつかの重大な問題が発生します:
- URL構造の曖昧さ:
?、&、#などの特殊文字は、URLで特定の意味を持ちます。これらの文字がエンコードなしでデータに表示されると、コンテンツではなくURL区切り文字として解釈されます。 - 文字セットの非互換性: 異なるシステムが同じバイトシーケンスを異なる方法で解釈する可能性があり、データの破損やリクエストの失敗につながります。
- プロトコル違反: HTTPおよびその他のインターネットプロトコルは、URLが特定のフォーマットルールに準拠することを期待しています。エンコードされていない文字は、プロトコルエラーを引き起こす可能性があります。
- セキュリティの脆弱性: エンコードされていない特殊文字は、インジェクション攻撃に悪用されたり、セキュリティフィルターをバイパスするために使用されたりする可能性があります。
URL内の「cats & dogs」の検索クエリを考えてみましょう。エンコーディングがなければ、アンパサンドはパラメータ区切り文字として解釈され、クエリが2つの別々のパラメータに分割される可能性があります。URLエンコーディングは、これをcats%20%26%20dogsに変換し、意図した意味を保持します。
ASCIIの制限
URLはASCII文字セット上に構築されており、128文字のみが含まれます。これらのうち、「予約されていない文字」として知られるサブセットのみが、エンコーディングなしでURLに表示できます。これらの予約されていない文字には次のものが含まれます:
- 大文字と小文字(A-Z、a-z)
- 10進数の数字(0-9)
- ハイフン(
-)、ピリオド(.)、アンダースコア(_)、チルダ(~)
それ以外のすべては、インターネット全体で適切な送信と解釈を保証するためにエンコーディングが必要です。
URLエンコーディングの仕組み
URLエンコーディングプロセスは、文字をパーセントエンコードされた同等物に変換する簡単なアルゴリズムに従います。このプロセスを理解することで、エンコーディングの問題をトラブルシューティングし、より堅牢なWebアプリケーションを作成できます。
エンコーディングアルゴリズム
文字をエンコードする必要がある場合、プロセスは次のように機能します:
- 文字を識別する: URLコンポーネントとエンコーディングルールに基づいて、エンコードが必要な文字を決定します。
- バイト値を取得する: UTF-8エンコーディング(または基本文字の場合はASCII)を使用して、文字をバイト表現に変換します。
- 16進数に変換する: 各バイトを2桁の16進数として表現します。
- パーセントプレフィックスを追加する: 各16進数のペアの前にパーセント記号(
%)を付けます。
たとえば、スペース文字のASCII値は32(10進数)または20(16進数)です。エンコードされると、%20になります。アットマーク(@)のASCII値は64(10進数)または40(16進数)なので、%40にエンコードされます。
UTF-8マルチバイトエンコーディング
ASCII範囲外の文字の場合、UTF-8エンコーディングは複数のバイトを生成し、それぞれがパーセントエンコードされます。絵文字「😀」(にっこり顔)は、UTF-8で4バイトとしてエンコードされます:F0 9F 98 80。URLでは、これは%F0%9F%98%80になります。
このマルチバイトエンコーディングにより、あらゆる言語またはシンボルセットの文字をURLで安全に送信できるようになり、Webが真に国際的になります。
プロのヒント: URLエンコーディングの問題をデバッグする場合は、ブラウザの開発者ツールを使用して、送信される実際のエンコードされたURLを検査します。ネットワークタブには、生のエンコードされたリクエストが表示され、エンコーディングの問題を明らかにすることができます。
エンコードが必要な文字
すべての文字がすべてのコンテキストでエンコーディングを必要とするわけではありませんが、どの文字がいつエンコーディングを必要とするかを理解することは、信頼性の高いWebアプリケーションを構築するために不可欠です。エンコーディング要件は、作業しているURLの部分によって異なります。
予約文字
予約文字はURL構文で特別な意味を持ち、区切り文字ではなくデータとして使用される場合はエンコードする必要があります。これらの文字には次のものが含まれます:
| 文字 | URLでの目的 | エンコード形式 |
|---|---|---|
: |
スキームとホストの区切り、ポート区切り文字 | %3A |
/ |
パスセグメント区切り文字 | %2F |
? |
クエリ文字列の開始をマーク | %3F |
# |
フラグメント識別子の開始をマーク | %23 |
[ ] |
IPv6アドレス区切り文字 | %5B %5D |
@ |
認証情報とホストの区切り | %40 |
! $ & ' ( ) * + , ; = |
さまざまな目的のサブ区切り文字 | %21 %24 %26 %27 %28 %29 %2A %2B %2C %3B %3D |
安全でない文字
特定の文字は、送信中に変更または誤解釈される可能性があるため、安全でないと見なされます。これらは常にエンコーディングが必要です:
| 文字 | 安全でない理由 | エンコード形式 |
|---|---|---|
| スペース | 削除されるか、+に変換される可能性があります |
%20 |
" |
HTMLでURLを区切るために使用されます | %22 |
< > |
HTMLタグで使用され、フィルタリングされる可能性があります | %3C %3E |
% |
エンコーディング区切り文字自体 | %25 |
\ |
一部のシステムでのパス区切り文字 | %5C |
^ ` { } | |
普遍的にサポートされていません | %5E %60 %7B %7D %7C |
コンテキスト依存のエンコーディング
エンコーディング要件は、作業しているURLコンポーネントによって異なります。あるコンテキストで安全な文字が、別のコンテキストではエンコーディングを必要とする場合があります:
- パスセグメント: スラッシュはパスセグメントを区切るため、セグメント名自体の一部でない限り、エンコードすべきではありません。
- クエリパラメータ: アンパサンドと等号は特別な意味を持つため、パラメータ値に表示される場合はエンコードする必要があります。
- フラグメント識別子: ほとんどの文字が許可されていますが、一貫性のためにエンコーディングが推奨されます。
URLエンコーディングの一般的な使用例
URLエンコーディングは、多数の実際のシナリオで表示されます。これらの使用例を理解することで、独自のプロジェクトでエンコーディングをいつどのように適用するかを認識できます。
検索クエリ
検索エンジンは、ユーザークエリを処理するためにURLエンコーディングに大きく依存しています。Googleで「how to bake a cake?」を検索すると、URLは次のようになります:
https://www.google.com/search?q=how+to+bake+a+cake%3Fスペースがプラス記号(クエリ文字列内のスペースの代替エンコーディング)としてエンコードされ、疑問符が%3Fとしてエンコードされて、クエリ文字列区切り文字と区別されることに注意してください。
フォーム送信
HTMLフォームがGETメソッドを使用して送信されると、フォームデータがエンコードされてURLに追加されます。ユーザー名とパスワードフィールドを持つログインフォームを考えてみましょう:
https://example.com/login?username=john.doe%40example.com&password=P%40ssw0rd%21メールアドレスとパスワードの特殊文字が適切にエンコードされ、解釈の問題を防ぎます。
セキュリティ注意: パスワードなどの機密データをURLパラメータで送信しないでください。この例は説明のみを目的としています。認証には常にHTTPSでPOSTリクエストを使用してください。
APIリクエスト
RESTful APIには、エンコーディングが必要なパラメータがURLに含まれることがよくあります。結果をフィルタリングしたり、複雑なデータ構造を渡したりする場合、適切なエンコーディングにより、APIが意図したとおりに正確に受信されます:
https://api.example.com/users?filter=created_at>2024-01-01&sort=-nameフィルターパラメータの大なり記号は、HTMLエンティティやその他の解釈との混同を防ぐために、%3Eとしてエンコードする必要があります。
ファイルのダウンロード
非ASCII名のファイルを提供する場合、URLエンコーディングによりファイル名が正しく送信されます:
https://example.com/downloads/Pr%C3%A9sentation%202024.pdf「Présentation」のアクセント付き「é」は%C3%A9(そのUTF-8表現)としてエンコードされ、システムの文字エンコーディングに関係なく、世界中のユーザーがファイルをダウンロードできるようになります。
ソーシャルメディア共有
ソーシャルメディアプラットフォームは、事前入力されたテキストでリンクを共有する際にURLエンコーディングを使用します。Twitter共有リンクは次のようになります:
https://twitter.com/intent/tweet?text=Check%20out%20this%20article%21&url=https%3A%2F%2Fexample.com%2Farticleツイートテキストと共有されるURLの両方がエンコードされ、