HTMLを書くときに困らぬよう基礎知識としてまとめた。
URLとは
WEBページの場所を特定するための住所である。
ファイルシステムでいうところのファイルパスにあたる。
URL指定方法
| 方法 | 例 |
|---|---|
| 絶対URL | https://example.com:80/content/index.html |
| 相対URL | content/index.html |
相対表記
| 指定 | 値 | 説明 | 例 |
|---|---|---|---|
| ドメイン | // |
プロトコルを省略しドメインから書く | //example.com/index.html |
| ルート | / |
ドメイン名を省略しパスから書く | /index.html |
| カレント | ./ |
現在文書があるパスから書く | ./index.html |
| 親 | ../ |
現在文書があるひとつ上のパスから書く | ../index.html |
- 相対パスのうち先頭が
//、/、./、../でないならカレントと判断される - 先祖をさかのぼりたければ、その数だけ
../する- たとえば
../../../index.htmlのように
- たとえば
URLパターン
| パターン | 書式 | 例 |
|---|---|---|
| 通常 | {プロトコル}{ホスト}:{ポート}/{パス}#{ハッシュ} |
https://example.com:80/content/index.html#heading-1 |
| クエリ | {プロトコル}{ホスト}:{ポート}/{パス}?{キー}={値}&{キー}={値} |
https://example.com:80/content/index.html?query1=value1&query2=value2 |
| ベーシック認証 | {プロトコル}{ユーザ名}:{パスワード}@{ホスト}/{パス} |
https://username:password@example.com:80/index.html |
URL部位名
以下URLのとき、各部位には名称がある。
共通
https://example.com:80/content/index.html
{プロトコル}{ホスト}:{ポート}/{パス}
| 例 | URL部位名 | 詳細 |
|---|---|---|
https:// |
プロトコル（スキーム） | ほかにhttp://やfile://などがある |
example.com |
ホスト（ドメイン) | IPアドレスやそれをDNSで文字列化した部分 |
:80 |
ポート（ポート番号） | 書かないことが多い |
https://example.com:80/ |
ホスト名（ドメイン名） | ホスト名＝プロトコル＋ホスト（＋ポート） |
/content/index.html |
パス | ホスト名の末尾にある/以降から#か?まで |
後述するURLパターンすべてに共通する部分である。
- ポートはオプションである
- 必要なら付け足すが、不要ならつけなくていい
- トップページならパス不要
https://example.com/でトップページが表示される- このとき末尾の
/がなくても大抵は補完してくれる - このとき末尾が
index.htmlでなくても大抵は補完してくれる
通常
https://example.com:80/content/index.html#heading-1
{プロトコル}{ホスト}:{ポート}/{パス}#{ハッシュ}
| 例 | URL部位名 | 詳細 |
|---|---|---|
#heading-1 |
ハッシュ | 内部アンカーのこと。同一文書内にある<a id="#heading">の位置へスクロールする |
- ハッシュはオプションである
- 必要なら付け足すが、不要ならつけなくていい
通常パターンはHTML文書を指定するときのURLである。任意でハッシュを付与すると、その位置までスクロールしてくれる。
<a href="#heading-1">「見出し1」へスクロールする</a> <a id="heading-1"> <h1>見出し1</h1>
パラメータ
https://example.com:80/content/index.html?query1=value1&query2=value2
{プロトコル}{ホスト}:{ポート}/{パス}?{キー}={値}&{キー}={値}
| 例 | URL部位名 | 詳細 |
|---|---|---|
?query1=value1&query2=value2 |
引数（パラメータ） | パス直後の?から始まる引数。キーと値を=で紐付ける。キーと値のセットが複数あるときは&で区切る。キー名は大文字小文字の区別をしないため大抵[a-z]+の文字で定義される。 |
このURLパターンはJavaScriptやサーバサイド言語で引数（キーと値のセット）をうけとり処理をするときに使う。
- 引数を使ってDOM操作し動的にHTMLを生成して返す
- 引数をサーバに送信してDBに格納する
JSでURL引数を解析する
const url = new URL(location.href); const key1 = url.searchParams.get('key1') const key2 = url.searchParams.get('key2')
サーバにURL引数を送信して応答をJSONで受け取る（JavaScript）
const res = await fetch('./form-action.php', {method:'get'}) res.json()
サーバにURL引数を送信して処理をまかせHTMLを受け取る（HTML）
<form action="./form-action.php" method="get"> <input name="key1" value="value1"> <input name="key2" value="value2"> <button>送信</button> </form>
ベーシック認証
https://username:password@example.com:80/index.html
{プロトコル}{ユーザ名}:{パスワード}@{ホスト}/{パス}
| 例 | URL部位名 | 詳細 |
|---|---|---|
username |
ユーザ名 | ベーシック認証するときに入力するユーザ名。 |
password |
パスワード | ベーシック認証するときに入力するパスワード。 |
ベーシック認証は現代ではセキュリティが低すぎて使う機会が少ないと思う。それでもいい場合、簡易的な閲覧制限として使われる。
URLエンコード
URLエンコードはURLにおいて使用できない文字を、使用できる文字に置換することである。
通常URLにはASCIIコードのうち印字できる字の中からメタ文字を除いた字しか使えない。なので日本語を使いたいときは日本語の字をURLエンコードすることでURLで使える文字に変換して再現する。
じつは以下の2種類あり、半角スペースの変換結果が異なる。
| 名称 | 半角スペース | 利用場面 |
|---|---|---|
| パーセントエンコーディング | %20 |
URL |
application/x-www-form-urlencoded（URLエンコード） |
+ |
URLクエリ（引数の値） |
半角スペースは、URLに使うなら%20、<form>やURLクエリ（引数）の値にセットするなら+になる。
以下サービスで変換できる。スペースは+になったのでURLエンコードのほうだった。
日本語JPドメイン
URLに日本語は使えないといったな、あれは嘘だ。じつは極一部では使える。日本語JPドメインというらしい。
でも、基本的に日本語は使えないので、やはりURLエンコードするものだと考えたほうがいい。
URLメタ文字
| メタ文字 | 使う箇所 |
|---|---|
/ |
パスの区切り文字 |
: |
ポートの先頭またはユーザ名とパスワードの間につける |
# |
ハッシュの先頭につける |
? |
クエリの先頭につける（パスの末尾。最初の引数の先頭） |
= |
引数のキーと値の間につける |
& |
引数の値と次のキーとの間につける |
@ |
パスワードとホストの間につける |
% |
URLエンコードした字の先頭につける |
番外編
IPFS
IPFSはURLでなくハッシュキーを使う。
URLはHTTPSというプロトコルでネット通信するときに使うものである。
HTTPSに対して、IPFSという通信プロトコルがある。これはP2Pネットワークで通信するもので、コンテンツにアクセスするとき必要なのはURLでなくハッシュキーである。コンテンツは複数のマシンに存在し、そのうちオンラインになっているマシンのいずれかひとつから入手する。よってHTTPSとちがい一箇所に限定されることがない。おなじキーを使っても、実際にアクセスするマシンは複数ある。なのでサーバダウンで取得できなかったり、サービス終了によって消滅するリスクが少ない。
| プロトコル | 指向 |
|---|---|
| HTTPS | ロケーション指向 |
| IPFS | コンテンツ指向 |
URLは場所を示す識別子である。サーバのIPアドレスであり、ISPが提供するアクセスポイントによって与えられたIPアドレスだ。それをDNSで文字列化したのがURL。ようするにURLは物理的な装置と紐付いている。
URLは不便である。たとえば引っ越ししたらアドレスは変わる。これを維持するのが大変で、名付けるためにはさらにDNSサーバが必要。
これからはWeb3.0でP2Pによる分散ネットワークが流行るだろうから、これまでの常識が変わるかもしれない。
