我正在使用 here 找到的 Java URL 构造函数“URL(URL context, String spec)”，但构造的 URL 不是我所期望的 - 它遗漏了上下文参数中提供的路径段。
例如，这段代码
new URL(new URL("http://asdf.com/z"), "a/b/c");
产生一个带有值的 URL
所以它已经离开了“z”路径段。
我有两个问题：
谢谢！
【问题讨论】：
http://asdf.com/z 是浏览器中的网页，那么指向a/b/c 的链接将转到http://asdf.com/a/b/c。 rfc2396 的非常抽象的文字我不会弄明白的。
java doc这里第一个参数“context”是什么意思？
类似于spec 参数的“基本 URL”。如果context 是https://example.com，而spec 是/foo，则构造函数将创建https://example.com/foo。它类似于（但不完全相同，我们稍后会看到）询问“我目前在 https://example.com，我想去 /foo，我的最终 URL 是什么？”
是否遗漏了“z”的预期行为？
是的。如果您按照 RFC 2396 中关于此案例的 rules of resolving a relative URL against an base URL 进行操作，您将到达此步骤：
(6) 如果达到这一步，那么我们正在解析一个相对路径 参考。相对路径需要和base合并 URI 的路径。虽然有很多方法可以做到这一点，但我们将 描述一个使用单独的字符串缓冲区的简单方法。
(a) 除了基 URI 的路径组件的最后一段之外，所有的都是 复制到缓冲区。换句话说，后面的任何字符 最后一个（最右边的）斜杠字符（如果有）被排除在外。
(b) 引用的路径组件附加到缓冲区 字符串。
这里的“最后一段”是指z，也就是没有添加到缓冲区中。在那之后，路径a/b/c“被附加到缓冲区”。之后的步骤 (c) 处理删除 . 和 ..，这在此处无关紧要。
请注意，RFC 2386 并没有说您必须以这种方式实现算法，但无论您的实现是什么，您的输出都必须与该算法的输出相匹配：
上述算法旨在提供一个示例，通过该示例 可以测试实现的输出—— 算法本身不是必需的。
所以是的，这是意料之中的。要保留/z，您应该在z 之后添加另一个/：
new URL(new URL("http://asdf.com/z/"), "a/b/c")
这样“最后一段”就变成了空字符串。
【讨论】：
您可以将上下文视为文件系统中的当前目录。
使用上下文“http://asdf.com/z”，当前目录为“http://asdf.com/”，使用“a/b/c”作为规范将产生完整路径“http:// /asdf.com/a/b/c”。
【讨论】：