文件IRI（https://tools.ietf.org/html/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]表示不同的资源。
答案 0 :(得分：0)
当您在浏览器中输入示例URI或单击它们作为Web文档中的链接时，浏览器必须将URI（以字符串形式给出）解释为URL，以便找到资源。从输入字符串（表示有效URI）到有效URL的解释/转换步骤就是将其中一个更改为另一个。为了检查给定的字符串是否确实包含有效的URL，该字符串由状态机解释并转换为URL的内存中表示形式。此状态机处理两个示例的URI表示形式的差异，但导致URL的内存中表示形式相同。即，在无权限的情况和空权限的情况之间的内存表示中没有区别。接下来，URL的内存中表示形式被序列化回字符串，这是输入URL后在浏览器中看到的实际URL字符串。如果内存中表示的方案是'file'，则此序列化总是总是将冒号双斜杠：//附加到输出字符串。
WHATWG URL标准[1]中概述了此行为，请参阅URL解析（文件状态）[2]和URL序列化[3]。
这个序列化问题是否是对URL和URI的更严格要求的结果，这也是我（也是）想知道的，但是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