处理加密的 HttpUtility.UrlEncode 参数
我在应用 HttpUtility.UrlEncode 或 UrlDecode 时处理加密的 URL 参数时遇到问题。
对于给定的网址字符串：?fid=7kqguwhYMNw=&uid=YCRSGG71+58= 作为 uid 加密数据一部分的加号被删除并替换为空格，因此我尝试解密它失败。
好的，所以我知道 + 是 QUERYSTRING(RFC 1630) 中空间的保留简写，但由于我对加密返回的值没有太多控制权，我该如何解决这个问题。
编辑： 好的，提出了很好的观点。忽略问题的 UrlEncode/UrlDecode 部分。当我将 Request.QueryString(["uid"]) 传递给解密方法时，加号仍然会被删除。
I have a problem dealing with encrypted URL parameters when applying HttpUtility.UrlEncode or UrlDecode.
for a given url string: ?fid=7kqguwhYMNw=&uid=YCRSGG71+58=
the PLUS sign which is part of the encrypted data of uid is stripped out and replaced with a space so my attempts to decrypt it fail.
OK, so I know that the + is a reserved shorthand for space in QUERYSTRING(RFC 1630) but since I don't have too much control over the value that is returned from encryption how can I get around this.
EDIT:
OK, so good point brought up. Ignore the UrlEncode/UrlDecode part of the question. Request.QueryString(["uid"]) will still have the plus sign stripped out of it when I pass it to my decryption method.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我建议添加代码来删除 = 字符，将 + 替换为 -，并将 / 替换为 。
如果您需要处理结果字符串，则可以执行相反的操作：（
没有理由放回 = 字符......它们只是填充）。
这样您就不需要担心 URL 编码和解码，并且可以避免不必要的字符串扩展。如果用户最终看到 URL，它对用户来说也会看起来更专业……URL 中的百分号很丑陋，而且几乎总是不必要的……每当我看到它们时，它都会尖叫“业余”。
I would suggest adding code to remove the = characters, replace + with -, and replace / with .
If you need to process the resulting string, you can do the reverse:
(there is no reason to put back the = characters... they are merely padding).
That way you don't need to worry about URL encoding and decoding and it avoids unnecessary expansion of your string. It also looks more professional to users if they end up seeing the URL... percent signs in URL are ugly and almost always unnecessary... it screams "amateur" whenever I see them.
Base-64 编码值在放入 URL 之前需要进行 URL 编码。如果我这样做
HttpUtility.UrlEncode("YCRSGG71+58=")然后我得到YCRSGG71%2b58%3d- 它没有加号，并且可以正确解码。换句话说，在 URL 上放置 base-64 值而不首先对其进行编码的代码是错误的。如果您控制该代码，则应该更改它。如果您无法控制该代码，那么就不要尝试解码一开始就没有进行 url 编码的内容。
The Base-64 encoded value needs to be URL-encoded before it is put in the URL. If I do
HttpUtility.UrlEncode("YCRSGG71+58=")then I getYCRSGG71%2b58%3d- which has no plus signs, and can be correctly decoded.In other words, the code that is putting a base-64 value on the URL without encoding it first is wrong. If you control that code, you should change it. If you don't control that code, then don't try to decode something that wasn't url-encoded in the first place.
附带说明一下，您应该使用 HttpUtility.UrlEncode 和 HttpUtility.UrlDecode 来完成此类工作。然而，即使这些也无法帮助您，因为 URL 无论如何都是格式错误的。
所以，根本不要使用任何东西！既然没有编码，为什么要解码呢？
As a side remark, you should use
HttpUtility.UrlEncodeandHttpUtility.UrlDecodefor this kind of work. However, even these wont help you since the URL is malformed anyway.So, don't use anything at all! Since it's not encoded, why decode it?