HttpResponseMessage.Content.Header 忽略 html 源代码中元标记中的字符集设置答案

【问题标题】：HttpResponseMessage.Content.Header ignoring charset setting in meta tag in html sourceHttpResponseMessage.Content.Header 忽略 html 源代码中元标记中的字符集设置
【发布时间】：2016-07-19 16:26:22
【问题描述】：

我刚刚发布了this 问题，答案马上就来了。反过来，它会产生以下新问题：

如果我的理解是正确的，来自HttpResponseMessage 的StreamContent 对象是在通过HttpClient.GetAsync 发出HTTP 请求时创建的。它的 Header 属性或它的一部分，将根据 HTML 源文件中包含的元标记进行设置。

例如，元标记可以告诉响应对象使用哪个字符集对文件内容进行编码。

<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />

对包含此类行的资源运行请求将使用此设置生成HttpResponseMessage.Content.Header。

在此问题顶部引用的另一个问题中，我提到了在没有正确编码的情况下创建的响应对象。由于生成此类不兼容响应的 HTML 源确实包含负责创建正确编码的响应的设置：

<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">

该站点的响应没有通过元标记中包含的字符集设置并因此以不正确的字符集呈现的原因是什么？

以下是问题的图示说明：两个站点都包含带有字符集设置的元标记，但是一个，由于某种原因，错过了它...

两个请求的 Fiddler 标头详细信息：

工作人员： （删除 cookie 标头）

请求：

GET http://www.ynet.co.il/home/0,7340,L-8,00.html HTTP/1.1
Host: www.ynet.co.il
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
If-Modified-Since: Thu, 31 Mar 2016 10:04:39 GMT

回应：

HTTP/1.1 200 OK
vg_id: 1
X-me: 06
Content-Type: text/html; charset=UTF-8
Last-Modified: Thu, 31 Mar 2016 10:38:57 GMT
Accept-Ranges: bytes
VX-Cache: HIT
WAI: 01
V-TTL: 0
backend-cache-control: 
Content-Length: 410685
Vary: Accept-Encoding
Date: Thu, 31 Mar 2016 10:38:48 GMT
Connection: keep-alive

有问题的一：

请求：

GET http://winedepot.co.il/ HTTP/1.1
Host: winedepot.co.il
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: __utma=201832727.725995063.1458660502.1459413977.1459418530.8; __utmz=201832727.1458660502.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); __utmc=201832727; ASPSESSIONIDCQTRQCAQ=FEOHEBFCBGABBKOBAHOGKBGB
Connection: keep-alive

回应：

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 118225
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Thu, 31 Mar 2016 10:36:21 GMT

【问题讨论】：

我很确定 HttpResponseMessage 类确实 not 解析响应 HTML 以读取任何元标记。不过我可能是错的。您是否非常确定您看到的行为源于这些标签，如果是，您是如何验证的？
这是一个假设，但基于分析上述摘录的结果。
是的，但是您没有显示整个 HTTP 响应，因此我们无法验证字符集实际上不是来自响应标头。
您认为哪个请求标头可以影响这里？不要忘记 Content-Type 只是一个响应头。我会将它添加到屏幕截图中，但我没有看到任何相关的内容。
我不是在谈论任何地方的请求标头。不要添加屏幕截图，将其添加为文本。使用 Fiddler 获取请求和响应标头。此外，content-type 可以用作请求头。

标签： c# dotnet-httpclient httpcontent httpresponsemessage

【解决方案1】：

从 Fiddler 屏幕截图中可以看出，HttpResponseMessage.Content.Headers.ContentType 将包含响应的 Content-type 标头中指定的内容。

HttpResponseMessage 将不解析响应 HTML 并搜索任何 <meta /> 标记。

【讨论】：

谢谢，但我看不出这是如何回答问题的。我注意到 fiddler 中响应标头的差异。当这个 parameter 是在 html 源代码的元标记中定义时，为什么一个响应标头会获得字符集设置而另一个却没有 - 并且两个 uris html 源代码都包含它？
@Veverke 我的回答回答了你的问题“为什么我看到这些内容类型的标题，而我却期待别的东西？”。你的期望是错误的。这个答案不能解决根本问题不是我可以改变的。
HttpResponseMessage 不会解析响应 HTML。很好，这意味着这些标签对响应对象的创建没有影响。仍然......这里又开始了 - 然后哪个其他设置负责使用 UTF-8 创建一个响应，而另一个没有（默认）？
对不起，伙计，但你不会告诉我我的问题是什么 :-)
我正在告诉你你所问的答案，你根本不理解它，这不是我的问题。 HttpResponseMessage.Content.Headers.ContentType 将包含服务器在其Content-type 响应标头中发送的值，我已经没有办法告诉你了。您对此没有任何影响，并且如果该内容类型标头实际上是错误的（即响应主体实际上编码不同），那么您无能为力，只能去检测或猜测实际编码。

【解决方案2】：

内容类型来自 HTTP HEADER

https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />

是内容的一部分，而不是标题的一部分。

我建议你安装应用程序 Fiddler 以更好地了解这些请求的实际作用。将 fiddler 设置为您的代理，并使用检查器查看您发出 http 请求时实际传递的内容。

更好的解释远非这里的范围

【讨论】：

没有明白你的意思，那鸿。我试图弄清楚为什么一个站点能够创建正确编码的 http 响应以及为什么其他站点不能。我举了这两种情况的例子。响应未正确编码的原因是什么？你说这与元标记无关？那是什么原因呢？
顺便说一下，我从一开始就知道 Content-Type 是 Content 标头的一部分（参见代码示例）。
为什么有些人会写出糟糕的代码？您的浏览器旨在照顾不遵循标准和编写错误代码的人。这就是网站返回的内容，您无法控制它。你必须解决它。