要約

  • RFC 5147 は text/plain に対し、文字または行の位置と範囲を表す URI 断片を定義する。
  • 断片は取得後にクライアントが評価し、サーバーが表現を解決する処理には使われない。
  • 位置はゼロから数える長さゼロの境界であり、引用文そのものではない。
  • 文字は復号後に数えるため、バイト数や画面上の字形数とは一致しない場合がある。
  • CRLF、LF、CR など、認識された改行は表現方法にかかわらず一文字として数える。
  • 実体より大きい位置は末尾に丸められ、元の対象が残っている証明にはならない。
  • 逆順の範囲と構文エラーは無視し、クライアントは推測による修正をしてはならない。
  • 任意の length と md5 は、転送用符号化を除いた MIME 実体の変化を調べる。
  • 完全性検査は実装しなくてもよく、charset の相違は検査不能や不確かな変換を招く。
  • MD5 は偶発的変化の手掛かりにはなっても、署名、発行者資格、現代的な耐衝突性ではない。
  • 断片だけの表示は周辺条件や出所を隠し、正しい選択から誤った判断を作り得る。
  • 重要な引用には、版、実体、復号、文脈、発行権限、判断結果を別々に保存する必要がある。

末尾への移動は成功ではない

短縮後の文書に対して古い line=800 を開くと、位置は実体の最後へ収束する。RFC 5147 がこの挙動を定義しているため、実装は停止しない。これは相互運用のための決定性であって、参照対象の存在証明ではない。

監視が「例外が出なかった」「スクロールが起きた」だけを数えると、最も重大な欠落が正常になる。必要なのは範囲外収束を独立した状態として記録することだ。証拠や手順に使う場合、その状態は判断停止でなければならない。

開始または終了を省略する開いた範囲にも同じ原理がある。後から文書が伸びれば、選択範囲も伸びる。リンク作成者が見ていない追記まで自動的に引用へ入る可能性がある。

断片はサーバーの確認印ではない

URI の # 以降は、リソースを取得した後にクライアントが扱う。text/plain というメディア型が RFC 5147 の文法を選ぶ。オリジンサーバーは、どの行が画面で選ばれたかを承認するわけではない。

この設計は段階的導入を可能にする。未対応クライアントでもファイル全体は開ける。だが、ファイル取得成功と断片選択成功を同じログ値にしてはいけない。未対応ソフトは文書を表示しながら対象を一切示さないことがある。

また、サーバーログだけでは利用者が見た範囲を再現できない。断片評価、charset、改行処理、範囲外処理、完全性検査、表示方法はクライアント側に残る。監査には双方の受領証が要る。

文字位置は復号の結果である

char= はバイトオフセットではない。UTF-8 では一文字が複数バイトになり得る。UTF-16 には別の表現規則があり、先頭の BOM は文字として数えない。見た目が一文字でも、合成済みコードポイントと基底文字＋結合文字では数が変わる。

したがって、アーカイブの文字コード変換は文章を読めるまま位置を動かす。元の charset と実際に使った charset を残さなければ、リンクの再現性はない。

改行も復号後の座標系に入る。インターネット上では CRLF が基本だが、HTTP やローカルファイルでは LF、CR、NEL などが現れる。認識した改行は一文字として数えるという規則があっても、実装がどの規則を認識したかは環境依存だ。

同じ文章を HTTP から取得した場合と file: URI で開いた場合で、保存形式が異なることもある。論理名が同じでも、数えている MIME 実体が同じとは限らない。

エラーを推測で直してはならない

範囲の先頭が末尾より後なら、その断片は無視する。文法に合わない場合も無視し、クライアントは「たぶんこの意味だろう」と直してはいけない。

この厳格さは重要だ。自動修正は、URI に書かれていない解釈を作り、クライアントごとの差を増やす。ただし、無視した後にファイル全体だけを表示する製品は、利用者へ失敗を明示する必要がある。そうしなければ「開いた」という印象が対象選択の成功へすり替わる。

位置と範囲の違いも誤解を招く。単一の位置は長さゼロで、文字列を選んでいない。カーソルを置ける実装とハイライトを期待する業務システムでは、同じ URI が別の完了条件を持つ。

length と md5 が守る境界

RFC 5147 は断片に length または md5 を付けられる。長さは弱い検査と明記される。MD5 は内容符号化や転送符号化を取り除いた後の MIME 実体に対して計算する。

この前処理が大切だ。転送時の圧縮が違っても、復元後の実体が同じなら同じ対象として扱える。一方、どの charset で計算したかは長さとバイナリ表現の双方を変える。指定 charset と取得実体が違う場合、クライアントはその検査をそのまま使ってはならない。

変換してから検査することは許されるが、文字の欠落や正規化が起き得るため、仕様自身が不確かさを認めている。変換成功は同一性証明ではない。

さらに、完全性検査の実装は任意である。実装して変化を検出したクライアントは断片を解釈しない方がよく、利用者へ通知できる。しかし別のクライアントは検査を無視する。同じ URI に強制的な組織統制が埋め込まれているわけではない。

RFC 6151 は後に、耐衝突性が必要な用途で MD5 を使うべきでなく、デジタル署名には不適切だと整理した。RFC 5147 の MD5 は歴史的な変化検出として読むべきで、発行者や承認権限の証明に昇格させてはならない。

メディア型を推測すると契約も推測になる

RFC 5147 の文法は text/plain 専用である。メディア型を明示しないスキームや環境では、ユーザーエージェントが推測する。仕様はその利用を本質的に信頼しにくいとする。

拡張子 .txt は MIME の証明ではない。FTP 取得物、ローカルファイル、HTTP 応答は、それぞれ異なるメタデータと改行慣習を持ち得る。証拠には宣言された型、実効型、推測方法を残す必要がある。

IANA の登録は text/plain にこの仕様を結び付ける。これは割り当てと文書化の証拠であり、ブラウザー実装率や特定表示の正しさを示す運用データではない。

正しい抜粋でも誤解を作れる

安全性の核心は位置ずれだけではない。断片だけを見せる機能は、小さな注意書きや例外を隠せる。正規サイトから取った文字列を別の枠内に置けば、サイト鍵のような信頼材料にも見せられる。

原文が本物であること、選択が正しいこと、表示が誠実であることは別々の性質だ。境界を視覚化し、元文書と周辺文脈へ戻れるようにし、異なる安全領域からの埋め込みを制限する必要がある。

再現可能な証拠には、完全 URI、取得時刻、応答バリデータ、媒体型、charset、復号実体ハッシュ、改行方針、断片、クライアント版、超過処理、選択本文と前後文脈を含める。署名と発行権限は別に検証する。

出典

  1. RFC 5147 HTML
  2. RFC 5147 テキスト
  3. RFC Editor の RFC 5147 情報
  4. IETF Datatracker の RFC 5147
  5. RFC 5147 文書履歴
  6. RFC 5147 errata 検索
  7. RFC 6838：メディア型仕様
  8. RFC 2046：MIME メディア型
  9. RFC 3986：URI 一般構文
  10. RFC 3987：国際化リソース識別子
  11. RFC 3629：UTF-8
  12. RFC 1321：MD5
  13. RFC 6151：MD5 の安全性
  14. RFC 9110：HTTP Semantics
  15. RFC 8089：file URI
  16. IANA メディア型レジストリ
  17. W3C Media Fragments URI 1.0
  18. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  19. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  20. Running-Code Primacy