文件 IRI 的标准 ( https://www.rfc-editor.org/rfc/rfc8089 ) 区分了没有权限的文件 IRI [1] 和没有权限的文件 IRI [2]。
现代网络浏览器（在 Firefox 和 Chrome 上测试）会自动将 [1] 更改为 [2]。例如，当 [1] 出现在链接标签中时，所遵循的有效链接是 [2]。（RFC 文档中没有解释这样的重写规则。）
[1] file:/C:/Program%20Files/Protege_2.1/2211#created_for
[2] file:///C:/Program%20Files/Protege_2.1/2211#created_for
有谁知道为什么浏览器会这样做以及这是否符合标准？
这会导致关联数据设置中的实际问题，其中 [1] 和 [2] 表示不同的资源。
当您在浏览器中输入示例 URI 或单击它们作为 Web 文档中的链接时，浏览器必须将 URI（以字符串形式给出）解释为 URL 以定位资源。正是在这个从输入字符串（表示有效 URI）到有效 URL 的解释/翻译步骤中，一个被更改为另一个。为了检查给定字符串是否确实包含有效的 URL，该字符串由状态机解释并转换为 URL 的内存表示。此状态机处理两个示例的 URI 表示的差异，但导致 URL 的内存中表示相同。也就是说，没有权限的情况和空权限的情况之间的内存表示中没有表示差异。下一个，URL 的内存表示被序列化回一个字符串，这是输入后在浏览器中看到的实际 URL 字符串。如果内存中表示的方案是“文件”，则此序列化总是将冒号双斜杠 :// 附加到输出字符串。
此行为在 WHATWG URL 标准 [1] 中进行了概述，请参阅 URL-Parsing (file-state) [2] 和 URL-Serializing [3]。
这个序列化问题是否是对 URL 的更严格要求的结果，这是我（也）想知道的，但是 RFC 8089 的附录 A 指出：
'根据 [RFC1738] 中的定义，文件 URL 始终以标记“file://”开头，后跟（可选空白）主机名和“/”。第 2 节中给出的语法使整个权限组件，包括双斜杠“//”，都是可选的。
由于该评论明确提到了 URL，我将其解释为通过 RFC 8089 的第 2 节中的语法，授权组件对于 URL（不仅仅是更广泛的 URI 定义）是可选的。WHATWG URL 标准似乎在这方面遵循 RFC1738。当解析和重新序列化的输出形式都相等时，它实际上认为两个 URL 是等效的，您的示例就是这种情况。因此，该行为似乎不符合最新标准，RFC 8089 也对此发出警告。
[1] https://url.spec.whatwg.org