摘要

  • RFC 5147 为 text/plain 定义了字符位置、字符范围、行位置和行范围四类 URI 片段。
  • 片段在资源取得之后由客户端解释，不参与服务器端的 URI 解析与表示获取。
  • 位置从零计数，表示两个字符或两行之间的零长度边界，并不等于一段引文。
  • 字符必须在解码后计数；字节数、代码点数与人眼看到的字形数可能不同。
  • 无论 CRLF、LF、CR 或其他受支持形式，每个换行都只计为一个字符。
  • 超出实体长度的位置会落到末尾，这种确定行为并不证明原目标仍存在。
  • 倒序范围与语法错误必须被忽略，客户端不得擅自修正或猜测。
  • 可选的 length 与 md5 针对去除传输编码后的 MIME 实体，而非发布者身份。
  • 客户端可以完全忽略完整性检查；字符集不一致还会使检查失效或转码不可靠。
  • MD5 在这里可帮助发现偶然变化，却不是签名、发布权限或现代抗碰撞证明。
  • 只显示片段可能隐藏法律小字、例外条件或安全域来源，正确定位也可能误导。
  • 重大决策需要分别保存修订、实体、解码、上下文、发布者、授权与结果凭据。

风险来自正确裁剪

很多证据事故并不是链接漂移。链接可以精确地选中创建者指定的三行；问题是创建者没有把第四行纳入片段，或者界面故意只展示狭窄范围。RFC 5147 的安全章节直接指出：局部显示可能隐藏法律小字，也可能把类似站点密钥的材料放进误导性画面。

因此，“片段正确”与“陈述完整”不是同一个检查。一个真实文件、一个合法 URI、一个符合语法的范围，完全可以组合成错误结论。协议层没有能力判断哪一行是例外、定义或限制条件。

这正是证据系统必须保存上下文的原因。仅存片段 URI，会把选择范围的权力交给链接创建者；仅存截图，又无法重建原始实体、字符集和客户端处理过程。

# 后面的内容没有送到源站裁决

RFC 5147 沿用 URI 的分层方式：先解析并取得资源表示，再根据媒体类型在客户端解释片段。源站并不会收到片段并替读者核准“这几行就是有效条款”。

这种本地处理允许渐进部署。不支持 RFC 5147 的客户端仍能打开整个文件，只是不能定位子资源。对可用性而言，这是优点；对审计而言，它要求区分“文件打开”和“片段命中”。如果产品只记录 HTTP 成功，旧客户端的无选择展示也会被算作证据成功。

服务器日志同样不能单独证明用户看到了哪一段。服务器可以证明某个表示被请求，却通常不知道本地片段解释是否成功、范围是否超界、完整性参数是否检查、界面是否隐藏上下文。

位置从解码后的实体开始

RFC 5147 的字符位置不是字节偏移。多字节编码会让一个字符占用多个字节；UTF-16 还可能有不计入字符位置的字节序标记。Unicode 预组字符与基字符加组合附加符在视觉上近似，代码点数量却可能不同。

这意味着转换系统能在“文字看起来没变”的同时改变 char= 指向。文档归档、邮件网关、浏览器默认字符集与本地编辑器都可能参与。若原响应没有明确字符集，历史上 text/plain 的默认规则也不能被现代软件随意替换成未经记录的假设。

行位置还受换行约定影响。互联网文本通常使用 CRLF，本地系统可能使用 LF、CR、NEL 或其他序列。标准要求每个被识别的换行只算一个字符，但实现仍要知道当前协议和存储环境的约定。一个 HTTP 副本和一个 file: 副本可能显示相同段落，却并非同一计数实体。

落到文件末尾不是找到原文

标准规定，超过实际长度的位置指向实体的最后位置。这样可以让处理结果确定，但它不提供目标仍然存在的证明。

假设操作手册由 800 行缩减成 60 行。旧链接 line=700 仍可能把阅读器带到末尾。如果监控只看“片段处理无异常”，内容删除反而变成绿色状态。系统必须把超界收束单独记录，并在证据用途上视为失败。

开放范围也会随实体增长而扩张。省略起点表示从开头开始，省略终点表示一直到末尾。后来附加的内容可能自动进入选区，而链接创建者从未审阅它。

另一些错误处理更严格：倒序范围必须忽略；语法错误也必须忽略，不能猜测修复。这个规则保护可重复性，但界面如果默默显示整份文件，用户依然可能误以为目标成功定位。

完整性参数只回答有限问题

片段可以附带 length 或 md5。长度被标准明确称为很弱的检查。MD5 在去除内容编码和传输编码后，对 MIME 实体的二进制表示计算。两者都不是针对发布机构的身份证明。

客户端并非必须实现这些检查，可以全部忽略。若实现并发现实体变化，客户端应当不再解释片段，并可以提示用户。这种措辞意味着不同客户端可能给出不同处置；组织不能把“URI 内含 digest”误报为强制阻断。

检查还可能包含字符集。声明字符集与取得实体不同时，客户端不得直接使用检查。它可以先转码，但 RFC 5147 明说这种做法存在字符丢失或规范化风险。

RFC 6151 后来说明 MD5 不适合需要抗碰撞的用途，也不能用于数字签名。即使不考虑恶意碰撞，一个无密钥哈希也不回答“谁发布”“谁批准”“哪一版生效”。匹配值最多支持“在规定预处理下，这个实体与预期相同”这一层。

媒体类型决定片段语义

line= 与 char= 不是所有 URI 的通用解释。RFC 5147 只适用于 text/plain。某些协议或本地环境没有可靠媒体类型，客户端只能推断；标准将这种情况称为内在不可靠。

文件扩展名不是 MIME 证明。FTP 取得物、本地 file: URI 与 HTTP 响应可能提供不同元数据，也可能采用不同换行和字符集。证据记录应保存声明类型、有效类型与推断理由。

IANA 将 RFC 5147 记录到 text/plain 注册信息中。这证明协调对象存在，不证明具体浏览器已经实现、具体用户看到了告警，也不证明某个片段对应权威内容。注册表不是运行遥测。

建立可复核的引文凭据

高风险引用至少要保存：完整 URI、取得时间、响应验证器、媒体类型、字符集、解码实体哈希、换行策略、片段字符串、客户端版本、是否超界、所选文字及前后上下文。若需要证明发布者，还要另存签名、归档修订或机构来源链。

这组记录允许调查者区分失败位置。资源不可达属于取得层；哈希变化属于实体层；字符集分歧属于解码层；范围移动属于定位层；裁剪误导属于呈现层；无权发布属于治理层。把它们压成“链接有效”会把每个问题派给错误团队。

来源

  1. RFC 5147 HTML
  2. RFC 5147 文本
  3. RFC Editor 条目
  4. IETF Datatracker 条目
  5. RFC 5147 文档历史
  6. RFC 5147 勘误查询
  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 语义
  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