2016-03-31 6 views
0

私はちょうどthisという質問を投稿しました。 それは、順番に、以下の新しい質問を作成:HttpResponseMessageからHttpResponseMessage.Content.Header htmlソースのメタタグの文字セット設定を無視しています

私の理解が正しければ、StreamContentオブジェクトは、HttpClient.GetAsyncを経由してHTTPリクエストを作成するときに作成されます。ヘッダープロパティーの一部またはその一部は、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"> 

正しくない文字セットでレンダリングされていますか?

enter image description here


フィドラーズ・ヘッダの詳細... 両方のサイトは、文字セットの設定とメタタグが含まれていますが、1、何らかの理由で、それをミス:

ここで質問を絵で説明があります

一作業: (除去クッキーヘッダ)

要求の両方のために

要求:

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 

問題の1:

要求:

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 
+0

'HttpResponseMessage'クラスがレスポンスHTMLを解析してメタタグを読み取っていないことはかなり確信しています。私は間違っているかもしれません。表示されている動作がこれらのタグに由来していることを確認していますか?その場合、どのように確認しましたか? – CodeCaster

+0

これは上記の抜粋の結果を分析することを前提にしています。 – Veverke

+0

ええ、あなたはHTTPレスポンス全体を表示しないので、キャラクタセットが実際にレスポンスヘッダから来ていないことを確認する方法はありません。 – CodeCaster

答えて

-1

コンテンツタイプは、HTTPヘッダー

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

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

から来ている内容ではなくヘッダの一部の一部です。

これらのリクエストが実際に行うことをよりよく理解するために、アプリケーションFiddler をインストールすることをお勧めします。 をfiddlerをプロキシとして設定し、インスペクタを使用してHTTPリクエストを行うときに実際に渡される内容を確認します。

より良い説明は、あなたのフィドラーのスクリーンショットからわかるように、HttpResponseMessage.Content.Headers.ContentTypeはレスポンスのContent-typeヘッダで指定された正確に何が含まれます、ここまでのところ範囲から

+0

あなたの意見は分からなかった、Nahum。私は、あるサイトが正しくエンコードされたHTTP応答を作成できる理由と、他の人がなぜそうでないのかを理解しようとしています。私は両方の場合の例を挙げました。応答が正しくエンコードされない理由は何ですか?あなたはこれがメタタグとは何の関係もないと言いますか?その理由は何ですか? – Veverke

+0

ところで、私は最初からContent-TypeがContentヘッダーの一部であることを知っていました(コードサンプルを参照)。 – Veverke

+0

なぜ、悪いコードを作成する人がいますか?あなたのブラウザはスタンドアーツに従わず、悪いコードを書いていない人の世話をするように作られています。単にサイトがあなたに返すものはそれを支配していません。 あなたはそれを回避する必要があります。 – Nahum

0

です。

HttpResponseMessage応答HTMLを解析し、<meta />タグを検索します。

+0

ありがとうございますが、私はこの回答に疑問があります。私は、フィドラーの応答ヘッダーの違いに気づいた。なぜこの*パラメータ*がHTMLソースのメタタグに定義されていて、両方のurlのHTMLソースにそれが含まれていると、1つのレスポンスヘッダがcharset設定を取得するのでしょうか? – Veverke

+0

@Veverke私の答えはあなたの質問に答えます_ "私は何か他のことを期待しているのに、なぜこれらのコンテンツタイプのヘッダを見ますか?"あなたの期待は間違っています。この答えが根本的な問題を解決しないということは、私が変えることのできるものではないということです。 – CodeCaster

+0

* HttpResponseMessageは応答HTML *を解析しません。これは、これらのタグが応答オブジェクトの作成に影響を与えないことを意味します。 Stil ...もう一度やり直してください。他の設定は、UTF-8で作成された1つの応答と、none(デフォルト)で作成された1つの応答を担当していますか? – Veverke

関連する問題