別の URL から返されるリソースでアダプターとして機能するカスタム URL スキームを定義する、クリーンで仕様に準拠した方法はありますか?
ローカル ファイルの復号化された表現を返すカスタム URL プロトコルを既に定義しています。たとえば、私のコードでは、
decrypted-file:///path/to/file
から取得するファイルを透過的に復号化しますfile:///path/to/file。ただし、これはローカル ファイルに対してのみ機能します。つまらない！URL 仕様が、新しい URL スキームを既存の URL の一種のアダプターとして定義することによって、これを一般化できるクリーンな方法を可能にすることを願っています。
たとえば、代わりにdecrypted:、リソースを取得する別の絶対 URL の前に付けるアダプターとして使用できるカスタム URL スキームを定義できますか? それから私はただすることができました
decrypted:file:///path/to/file
またはdecrypted:http://server/path/to/fileまたはdecrypted:ftp://server/path/to/fileまたは何でも。これにより、私のdecrypted:プロトコルは、ファイルの取得を行う既存のすべての URL スキームで構成可能になります。
jar:Java はURL スキームで同様のことを行いますが、 RFC 3986を読むと、この Java テクノロジは URL 仕様に違反しているように見えます。埋め込まれた URL は適切にバイト エンコードされていないため、埋め込まれた URL の/、?、または#区切り記号は、埋め込み URL のセグメント区切り記号として公式に扱われるべきです (それがJarURLConnectionの動作ではない場合でも)。スペック内に収まりたい。
これを行うための適切で正しい方法はありますか？それとも、埋め込まれた URL 全体をバイトエンコードする唯一のオプションですか (つまり、decrypted:file%3A%2F%2F%2Fpath%2Fto%2Ffileあまり良くありません)。
私が提案していること (URL アダプター) は他の場所で行われていますか? それとも、これが誤った方向に導かれるより深い理由がありますか?