过时的Uri(string, bool)构造函数用于从已经转义的字符串构造URI（如果出现无效字符串，则过时可能不会破坏程序）。但是，我发现自己处于需要通过URI传递文字字节的情况，我无法想出更好的编码方式。
我正在构建一个data: URI，这是一种传递整个资源而不是其标识符的标准化方法。虽然我知道它有一个;base64说明符来标记在base64中编码的传递数据，但是有些情况下，如果没有base64，URI会更短，例如当二进制数据较少时。因为我不想担心编码，所以我只想使用HttpUtility.UrlEncode(byte[])将字节与URI一起作为URI编码的字符串传递。
因为我几乎没有其他选择，只能让.NET为我编码字符串，而不必使用过时的构造函数，并且没有Uri(byte[])构造函数（在我看来应该有），我可以选择构建URI吗？
我考虑使用Encoding.GetEncoding(1252)从字节创建字符串并使用它，因为cp1252可以解码任何字符，但似乎内部的 Uri 编码方法使用UTF-8来对字符进行编码，因此我发现根本不可能使用文本编码。
我有什么选择？如果没有别的办法，可以继续使用过时的构造函数吗？
答案 0 :(得分：0)
有些情况下，如果没有base64，URI会更短，例如当二进制数据较少时
每次都没有base64，URI会更短，因为base64会从八位字节的故意限制字符库中生成文本。
当数据是文本时，不能使用时基64。否则结果将是胡言乱语。
因为cp1252可以解码任何字符
不，它只能编码251个字符，不像UTF-8那样可以编码UCS中的每个字符。 UTF-8不能解码每个字节序列，而一些不正确的CP-1252实现填补了CP-1252中的空白（例如0x81），但即使你可以依赖它（你也不能），这不是＆＃ 39;因为你正在构建一个字符串，所以编码问题并不重要，除了任何％-escaped字符，它们将始终根据UTF-8中的编码进行转义。 （很久以前，URL [术语 URI 尚未存在]可以根据其他编码进行转义，但这不起作用，因为无法知道编码是什么已被使用，因此自1998年以来强制要求UTF-8的标准。
继续使用过时的构造函数
是否可以
不，它会产生错误的结果。
URI建立在文本之上。如果您的数据是文本的，那么只需通过Uri.EscapeDataString()的普通URI规则对其进行编码即可。如果您的数据不是文本，那么使用base-64将其编码为文本，然后从那里开始。不要尝试将某些内容放入URI中不具有意义的URI中。
答案 1 :(得分：0)
嗯，标准 Uri 构造函数接受预编码的URI，并且不替换有效的%字符，因此使用 dontReplace 参数不是从包含编码部分的有效URI字符串构造 Uri 时非常必要。它们不会被重新编码。