自定义 URL 方案作为现有 URL 方案的适配器 [英] Custom URL scheme as adapter on existing URL schemes

问题描述

是否有一种干净且符合规范的方法来定义自定义 URL 方案，该方案充当另一个 URL 返回的资源的适配器?

Is there a clean and spec-conformant way to define a custom URL scheme that acts as an adapter on the resource returned by another URL?

我已经定义了一个自定义 URL 协议，它返回本地文件的解密表示.因此，例如，在我的代码中，

I have already defined a custom URL protocol which returns a decrypted representation of a local file. So, for instance, in my code,

decrypted-file:///path/to/file

透明地解密您将从 file:///path/to/file 获得的文件.但是，这只适用于本地文件.没有乐趣！我希望 URL 规范提供一种干净的方式，我可以通过将新的 URL 方案定义为现有 URL 上的一种适配器来概括这一点.

transparently decrypts the file you would get from file:///path/to/file. However, this only works for local files. No fun! I am hoping that the URL specification allows a clean way that I could generalize this by defining a new URL scheme as a kind of adapter on existing URLs.

例如，我是否可以改为定义一个自定义 URL 方案 decrypted: ，它可以用作一个适配器，为另一个检索资源的绝对 URL 加上前缀?那我就可以了

For example, could I instead define a custom URL scheme decrypted: that could be used as an adapter that prefixes another absolute URL that retrieved a resource? Then I could just do

decrypted:file:///path/to/file

或 decrypted:http://server/path/to/file 或 decrypted:ftp://server/path/to/file 或其他.这将使我的 decrypted: 协议可以与所有进行文件检索的现有 URL 方案组合.

or decrypted:http://server/path/to/file or decrypted:ftp://server/path/to/file or whatever. This would make my decrypted: protocol composable with all existing URL schemes that do file retrieval.

Java 对 jar: URL 方案做了一些类似的事情，但根据我对 的阅读RFC 3986 似乎这种 Java 技术违反了 URL 规范.嵌入的 URL 未正确进行字节编码，因此嵌入 URL 中的任何 /、? 或 # 定界符都应正式视为段嵌入 URL 中的分隔符(即使这不是 JarURLConnection 确实).我想保持在规格范围内.

Java does something similar with the jar: URL scheme but from my reading of RFC 3986 it seems like this Java technology violates the URL spec. The embedded URL is not properly byte-encoded, so any /, ?, or # delimiters in the embedded URL should officially be treated as segment delimiters in the embedding URL (even if that's not what JarURLConnection does). I want to stay within the specs.

是否有一个很好的和正确的方法来做到这一点?或者是对整个嵌入 URL 进行字节编码的唯一选项(即，decrypted:file%3A%2F%2F%2Fpath%2Fto%2Ffile，这不太好)?

Is there a nice and correct way to do this? Or is the only option to byte-encode the entire embedded URL (i.e., decrypted:file%3A%2F%2F%2Fpath%2Fto%2Ffile, which is not so nice)?

我建议的(URL 适配器)是否在其他任何地方完成?或者是否有更深层次的原因导致这种误导?

Is what I'm suggesting (URL adapters) done anywhere else? Or is there a deeper reason why this is misguided?

推荐答案

Cocoa 中没有内置适配器，但是对于大多数用途，使用 NSURLProtocol 编写自己的适配器非常简单.给定一个任意 URL，像这样编码似乎最简单:

There's no built-in adaptor in Cocoa, but writing your own using NSURLProtocol is pretty straightforward for most uses. Given an arbitrary URL, encoding it like so seems simplest:

myscheme:<originalurl>

例如:

myscheme:http://example.com/path

最简单的说，NSURL 实际上只关心你传入的字符串是否是一个有效的 URI，如上所示.是的，基于 RFC 1808 等，有额外的 URL 支持位于顶部，但这不是必需的.

At its simplest, NSURL only actually cares if the string you pass in is a valid URI, which the above is. Yes, there is then extra URL support layered on top, based around RFC 1808 etc. but that's not essential.

成为有效 URI 所需要的只是一个指示方案的冒号，并且没有无效字符(基本上是没有空格的 ASCII).

All that's required to be a valid URI is a colon to indicate the scheme, and no invalid characters (basically, ASCII without spaces).

然后您可以使用 -resourceSpecifier 方法来检索原始 URL 并使用它.

You can then use the -resourceSpecifier method to retrieve the original URL and work with that.

这篇关于自定义 URL 方案作为现有 URL 方案的适配器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！