要約

  • URL末尾の#以降は取得先のアドレスから切り分けられ、受け取った表現に合わせて利用者側のソフトが解釈する。
  • HTMLの名前付きアンカーからプレーンテキストの行・文字範囲まで、フラグメントは文書の入口より細かな参照を可能にした。

長い資料へのリンクを渡され、「大事なところは中にある」とだけ言われたら、宝探しの始まりだ。末尾に#と目印があれば、リンクはしおり付きになる。サーバーは資料そのものを送り、ブラウザーは届いた資料の中で目印を探す。どこを読んでほしいかは、そのリンクを書いた人も決められる。

この分担は1995年6月のRFC 1808にすでに見える。相対URLを解釈する際、#以下を先に取り分け、残りをURLとして処理する。同じ年に出たHTML 2.0のRFC 1866は、#fragmentを同一文書のアンカーへの参照として記した。当時のHTMLなら、値の一致するNAME属性を持つA要素が目標になる。一冊の本が届き、最後のページめくりを閲覧ソフトが受け持つ。

Tim Berners-Leeは1997年4月のW3C建築メモで、その受け渡しをさらに明確にした。クライアントが文書の表現を受け取り、そのメディアタイプを扱うソフトにフラグメントを渡す。HTTPサーバーはその部分を受け取らない。メモは「fragment」という名前の狭さにも触れる。指せるのは文字通りの断片だけとは限らず、形式が定める眺め方や対象にもなり得る。しおりは比喩として便利だが、仕組みはもっと広い。

2005年のRFC 3986は、主たる資源を通じて別の対象を間接的に識別する、と一般化した。意味は受け取った表現のメディアタイプにより、利用者側のエージェントが解決する。ここには参照する側の自由がある。公開者が段落ごとに新しいサーバーURLを用意していなくても、リンクを書く人が既存の文書の中を選んで示せる。公開する人が本を作り、引用する人がしおりを挟む。

仕組みはHTMLのアンカーで止まらなかった。2008年のRFC 5147は、text/plainのフラグメントとして文字位置・文字範囲・行位置・行範囲を定義する。プレーンテキストにはHTML要素のIDがないが、行と文字は数えられる。内容の型に合わせて指し方を変えられることが、ひとつの記号に残された余地だった。

HTTPのRFC 9110でも、フラグメントは送信されるリクエストの目標URIに含まれない。元のサーバーは文書を渡し、閲覧側がその中の位置を解釈する。目標のアンカーが変更されれば古いしおりは外れる。深いリンクの使い勝手は、文書の中の名前を安定して保つことにも支えられている。

#はキーボード上では目立たない。それでもウェブの会話をずいぶん具体的にした。「この文書を読んで」から「この箇所を見て」へ。説明したい人が自分で指差せるし、読む人は膨大な前置きを歩かずに済む。サーバーが本を届けたあと、その本のどこを開くかに別の人の意思が入る。小さなしるしが、その余白を確保した。