我的抓取工具引擎似乎对特定客户的网站有问题。
在该网站上，有一些重定向到如下所示的 URL:
http://example.com/dir/aaa$0081 aaa.php
(将 URL 显示为未编码，$0081 是使用十六进制表示的两个字节。)
现在，这是在检查使用 WinInet Windows API 调用 HttpQueryInfo 后返回的缓冲区时的情况，因此此时这两个字节实际上表示一个 WideChar。
现在，我可以看到，例如$0081 是一个非视觉控制字符: Latin-1 Supplement (Unicode block)
问题是，如果我“按原样”使用 URL(URL 编码)用于将来向服务器发出的请求，它会以 400 或 404 响应。(另一方面，如果它被完全删除，它可以工作并且服务器提供正确的页面和响应...)
我怀疑FireFox/IE/等。在发出 HTTP 请求之前剥离 URL 中的不可见控制字符...(至少 IEHTTPHeaders 和 FF Live HTTP Headers 插件不会显示任何不可见字符。)
我想知道是否有人可以指出一个标准？据我所知，不可见字符不应在 URL 中找到，因此我认为解决方案可能是(在这种情况和将来的情况下)删除这些字符。但这似乎并不是网络上广泛讨论的话题。
最佳答案
在给出的示例中，$0081 只是五个 Ascii 字符。但是，如果您的意思是这就是它的样子，并且您(以某种方式)推断出实际的 URL 包含 U+0081，那么应该发生的情况(至少在 Firefox 上确实发生了)是:它被%编码(“URL编码”)为%C2%81(通过对U+0081的UTF-8编码形式的两个字节进行%编码而形成。Firefox在其地址栏中将其显示为空，因为U+ 0081 是控制字符，但服务器实际上获取 %C2%81 并且必须从那里获取它。
我不知道空格从何而来，但 URL 不得包含空格，% 编码 (%20) 除外。
相关标准为互联网标准STD 66 ，URI 通用语法。 (当前为 RFC 3986。请注意:在本期中，人们仍然经常将旧的 RFC 称为“标准”。)
关于URL 包含非视觉字符，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12453353/