我从一个我想用 FiddlerCore 解析的站点得到了一个奇怪的响应。在 chrome 开发者工具中，如果我检查它看起来完全正常的响应，在 fiddler 中则不然。代码片段如下(以前工作正常)
String html = oSession.GetResponseBodyAsString();
返回以下内容，这不是 html，请注意这是一个示例而不是完整的巨大字符串。
JRHwJNeR\0���\0\0\u0001��D\0�2�\b\0�\u0016�7]<!DOCTYPE html>\n win\">
还乱七八糟的是“\n”和这样的html
\n\n\n\n\n \n <meta name=\"treeID\" content=\"dwedxE+pgRQAWIHiFSsAAA==\">\n
响应头如下:
Cache-Control:no-cache, no-store
Connection:keep-alive
Content-Encoding:sdch, gzip
Content-Language:en-US
Content-Type:text/html;charset=UTF-8
Date:Fri, 28 Oct 2016 10:17:02 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Pragma:no-cache
Server:Apache-Coyote/1.1
Set-Cookie:lidc="b=VB87:g=518:u=60:i=1477649823:t=1477731496:s=AQG-LTdly5mcIjAtiRHIOrKE1TiRWW-l"; Expires=Sat, 29 Oct 2016 08:58:16 GMT; domain=.thedomain.com; Path=/
Set-Cookie:_lipt=deleteMe; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
Strict-Transport-Security:max-age=0
Transfer-Encoding:chunked
Vary:Accept-Encoding, Avail-Dictionary
X-Content-Type-Options:nosniff
X-Frame-Options:sameorigin
X-FS-UUID:882b3366afaa811400a04937a92b0000
X-Li-Fabric:prod-lva1
X-Li-Pop:prod-tln1-scalable
X-LI-UUID:iCszZq+qgRQAoEk3qSsAAA==
X-XSS-Protection:1; mode=block
Fiddler启动代码:
Fiddler.FiddlerApplication.AfterSessionComplete += FiddlerApplication_OnAfterSessionComplete;
Fiddler.FiddlerApplication.BeforeResponse += delegate(Fiddler.Session oS) {
oS.utilDecodeResponse();
};
Fiddler.FiddlerApplication.Startup(0, FiddlerCoreStartupFlags.Default);
}
最初我假设它是分块/压缩的，所以我添加了 utilDecodeResponse();到没有效果的 onBeforeResponse!
只是为了涵盖所有基础，我还尝试在 UTF-8、Unicode、Bigendian 等中手动解码 responseBodyBytes，只是在响应内容类型不正确并禁用 javascript 并加载页面以证明它不是一些时髦的模板东西，这也没有什么区别。
有什么想法吗？
更新:
根据下面Developer & NineBerry提供的信息，解决方案如下:
为了防止响应被 SDCH 编码，您可以像这样添加一个处理程序:
Fiddler.FiddlerApplication.BeforeRequest += delegate (Fiddler.Session oS)
{
oS.oRequest["Accept-Encoding"] = "gzip, deflate, br";
};
应该注意的是，这并不适合所有情况，因为您是手动设置 header 而不是检查 SDCH 是否存在然后将其删除，就我而言，这工作正常，但对于使用一般代理功能 fiddler 的你会想要更多的逻辑。
最佳答案
内容编码显示为SDCH - Shared Dictionary Compression；因此在这种情况下，手动解码 UTF-8、Unicode、Bigendian 等格式的 responseBodyBytes 将不起作用。
您可以在此处找到有关 SDCH 的更多详细信息 - SDCH Ref 1 & SDCH Ref 2
以上网站摘录:
Shared Dictionary Compression is a content-encoding method which was proposed back in 2008 by Google, and is implemented in Chrome and supported by a number of Google servers. The full proposal can be obtained here -https://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/att-0441/Shared_Dictionary_Compression_over_HTTP.pdf. Rather than replicate the contents of the document in this blog post, I’ll try and summarise as concisely as possible:
The whole idea of the protocol is to reduce redundancy across HTTP connections. The amount of ‘common data’ across HTTP responses is obviously significant - for example you will often see a website use common header/footers across a number of HTML pages. If the client were to store this common data locally in a ‘dictionary’, the server would only need to instruct the client how to reconstruct the page using that dictionary.
关于c# - FiddlerCore 解码 sdch 响应，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40303374/