2016-03-19 16 views
0

私はHttpClientを使っていくつかのファイルを取得しています。私はバイト配列(バイト)に内容を入れました。今私はエンコーディングを検出する必要があります。 contenttypeは、html、css、JavaScriptまたはXML contenttypeのいずれかになります。HttpClient:エンコードを検出する正しい順序

現在、私はヘッダーから文字セットをチェックし、最後にcharsetメタタグのファイルの最初の部分をチェックする前にBOM(バイトオーダーマーク)をチェックします。 通常、競合がないため、正常に動作します。

しかし、この順番は正しいですか(競合の場合)?

Iはcorrently使用コード:

Encoding encoding; 
 
try 
 
{ 
 
    encoding = Encoding.GetEncoding(responseMessage.Content.Headers.ContentType.CharSet); 
 
} 
 
catch 
 
{ 
 
    using (MemoryStream ms = new MemoryStream(bytes)) 
 
    { 
 
     using (StreamReader sr = new StreamReader(ms, Encoding.Default, true)) 
 
     { 
 
      char[] chars = new char[1024]; 
 
      sr.Read(chars, 0, 1024); 
 
      string textDefault = new string(chars); 
 
      if (sr.CurrentEncoding == Encoding.Default) 
 
      { 
 
       encoding = Global.EncodingFraContentType(textDefault); 
 
      } 
 
      else 
 
      { 
 
       encoding = sr.CurrentEncoding; 
 
      } 
 
     } 
 
    } 
 
} 
 
responseInfo.Text = encoding.GetString(bytes);
Global.EncodingFraContentTypeは、XML宣言で、またはメタタグのいずれかで定義された文字セットを見つける正規表現です。

文字セット/エンコーディングを検出する正しい順序は何ですか?あなたはファイルの先頭にUTF-8バイトオーダーマーク(BOM)をお持ちの場合

答えて

1

W3C Faq

によると、その後のInternet Explorer 10または11以外の最新のブラウザーのバージョンが決定するためにそれを使用しますあなたのページのエンコーディングがUTF-8であること。 HTTPヘッダーを含む他の宣言よりも高い優先順位を持ちます。

httpのヘッダーとメタの間では、BOMが優先されます。ただし、メタが最初の1024以内であれば、それに厳しいルールはありませんが優先されます。

+1

あなたの答えはちょっと混乱しているようです。文は開始されますが、終了しません。一部の引用符で囲まれていない部分は、リンク先のページから来ているようです。 –

+0

@フレデリック - フィードバックありがとうございます。 – Anastasiosyal

2

正しい答えは注文ではなく実際に正しい結果をもたらします。ここには完全な答えはありません。

競合が発生した場合、サーバーはあなたに何か誤りを与えています。誤っている正しい方法がないため、正しいものではないため、正しい順序にすることはできません。ヘッダーと埋め込みメタデータの両方が間違っている可能性があります。

BMPがUTF-8やUTF-16のように見えるようなものはほとんどありませんが、あなたが言及しているコンテンツタイプの有効な例です。その後BOMが勝ちます。

(例外的に、ドキュメントが途中でエンコードを切り替えるほどひどく編集されていますが、これはまったく予期しないことですが、バグのあるコンテンツは本当に意味がないためバグが多いです)。

コンテンツに0x7Fより大きい八重奏が含まれていない場合、それは重要ではなく、ヘッダーとメタデータはUS-ASCII、UTF-8、ISO-8859のエンコーディングファミリ、またはそれらのオクテットがすべて同じコードポイントにマップされている他のエンコーディングのいずれかであれば、nettの結果が同じであるため、それを考慮する必要はありません。それが正しく一致するように書き直す必要はないので、メタデータが何を言っているかを考えてください。

BOMのないUTF-16の場合は、これらのフォーマットのすべてがU + 0000〜U + 00FFの範囲で特殊な意味を持つ多くの文字を持っているので、一般的にはU + 0020からU + 007Fまでです)、1文字おきに0バイトの範囲がたくさんあります。

0x7F以上の八重奏を持ち、有効なUTF-8であれば、ほぼ確実にUTF-8です。 (もしUTF-8でなく、0x7F以上のオクテットを持っていれば、UTF-8と誤解することはほとんどありません)。

最も厄介な合理的なケースは、0x80-0xFFの範囲の1オクテットの文字エンコーディングとオクテットの両方である2つの異なるエンコーディングであるという相反する主張がある場合です。これはあなたが確かめることができない場合です。あるエンコーディングが他のエンコーディングの一部である場合(特にC1コントロールが除外されている場合)、スーパーセットに行くことができますが、エンコーディングに関する知識とかなりの量の作業を保存する必要があります。ほとんどの場合、例外をスローする傾向があります。ログに見つかったときに、バグを修正するためのソースを得ることができますか、それとも特別な場合はそのソースを取得できますか?あなたとは関係がないかもしれない非常に多数の異種のソースを取り扱っています。ああ、完璧な答えはここにありません。

ヘッダーと埋め込みメタデータの両方が間違って一致することもあります。一般的なケースはCP-1252の内容ですが、ISO-8859-1にあると主張しています。

関連する問題