はじめに
URL(Uniform Resource Locators)とは、ウェブページ等のリソースの場所と通信方法を表したものです。誤解を恐れず簡単にまとめると、インターネット上での住所、というところでしょうか。
URLは、RFC（Request for Comments）と呼ばれるインターネット上の技術に関する仕様書の、1738番目(RFC1738, 日本語訳)で定義されました。
普段何気なく目にするURLですが、「インターネット上における住所」というふわっとした理解のままだったので、今回の記事ではこのURLの構造について、簡単に整理してみました。
シンプルなURLの構造
一般的によく見るシンプルな作りのウェブページのURLは次の形式のようになっています。
(URL例:爆速表示で知られる俳優・阿部寛のウェブページのURL)
http://abehiroshi.la.coocan.jp/index.html
URLの記述にはルールがあり、そのルールに沿って先ほどのURLを分解すると、以下のような要素に分かれます。
スキーム | ホスト名 | パス
では、それぞれの項目について順に見ていきます。
スキーム
http://abehiroshi.la.coocan.jp/index.html
スキームには、そのリソースにたどり着くまでの手段(通信プロトコル)が含まれています。
よく見るものとしてはhttp、TLS/SSLによって通信経路が暗号化されるhttpsなどがあります。
Chromeなどのブラウザはこのスキームを見て、適切な接続方法を選択します。
ホスト名
http://abehiroshi.la.coocan.jp/index.html
ホスト名には、リクエスト先のサーバの名前が入ります。ホスト名はドメイン名とも呼ばれ、ネットワーク上での識別のために使われます。
パス
http://abehiroshi.la.coocan.jp/index.html
パスには、ホスト名で指定されたサーバーのリソースへのパスが入ります。
今回の例では、/index.htmlというように、明示的にリクエスト先のサーバーの物理的なファイルを指定しました（トップがindex.htmlだとわかっていたため）。
現在ほとんどのサーバーが一番上の階層にリクエストがきた場合、何らかのリソースを返す処理を実装しているため、別に/index.htmlと書かなくても、
http://abehiroshi.la.coocan.jp/
と書くだけで、上記の例と同じリソースにアクセスできます。
最近では、パスは物理的なディレクトリ構造とは関係のない、サーバーによって返される抽象的なパスになっていることがほとんどのため、直接ファイル名を指定する方法はあまりないかもしれません。
クエリーを含んだURLの構造
クエリー
クエリーを含んだウェブページのURLは次の形式のようになっています。
(URL例:Qiitaで@sho-hataが書いた記事を検索した結果)
https://qiita.com/search?q=user%3Asho-hata
クエリーは検索用語を指定したり、表示したいウェブページに対して何らかのパラメータを付与するのに使います(Real World HTTPより)。
**?の後ろに、[キー]=[値]**という形で渡します。[キー]=[値]のペアが複数になる場合は&記号を使います。
エンコーディング
キーと値に使える文字種は限定されており、URLエンコーディングで変換されています( : → %3A)。
URLを構成する文字はASCII文字列とされていたため、日本語などは扱うことができませんでした。
しかし、RFC2718ではUTF-8で日本語をURLエンコーディングすることで、日本語を扱えるようになっています。
凡例：
http://example.com/書誌情報
↓
http://example.com/%E6%9B%B8%E8%AA%8C%E6%83%85%E5%A0%B1
これらは最近ではデコードされて、日本語がそのまま表示されるようになっています。
例：amazonで「リアルフォース」を検索した結果
https://www.amazon.co.jp/s?k=%E3%83%AA%E3%82%A2%E3%83%AB%E3%83%95%E3%82%A9%E3%83%BC%E3%82%B9&__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&ref=nb_sb_noss_1
↓
まとめ
URLの構造について、簡単に整理してみました。
改めてURLについて勉強すると、Webが抽象化の一途を辿ってきたことがとてもわかります。
今でこそ当たり前になっていますが、リクエストする側がリクエスト先の物理的なディレクトリ構造や、拡張子のことを意識せずにアクセスできることは、抽象化による恩恵だったんですね（すごい）
RFCを読んでみるなど、ネットワークの歴史についてたまにはゆっくり勉強するのも楽しいですね。