符号化 sniffing における資源ヘッダー [19] encoding sniffing には資源ヘッダー という用語はありませんが、
類似の規定が各仕様にあります。
[6] HTML の文字符号化宣言 (<meta charset>) は、
HTML文書 の最初の 1024
バイト 以内に含めなければならない と規定されています
>>5
[21] これは著者 に対する要件です。[12] XHR の文書応答 における HTML の処理 (responseXML) では、
先頭 1024 バイト を使って prescan すると規定されています >>11
[8] HTML の encoding sniffing algorithm の prescan では、
利用者エージェント 依存としつつも、
先頭 1024 バイト または 500 ms 経過までのデータを使うことを勧めています
>>7
[9] 当初は 512 バイト とされていましたが、Web互換性 のため拡大されました >>16
[20] 処理速度を条件にいれることで、ネットワーク の偶然の転送の具合に依存してしまうことになりますが、
読み込みの速度が遅くていつまでも charset sniffing の結果を得られないことを防げます。
navigate
に限ってこのような規定があるのは、
incremental rendering が必要であること、
最初のレンダリング までの処理速度が利用者体験 上特に重要であることと、
符号化の変更 による修復が可能だからでしょう。[23] ただしきっちり 1024 バイト に限定することが硬い要件とされているわけではなく、
必要があればそれを超える実装も仕様に違反しません。ローカルファイル の場合など、
すぐに利用できるデータがあって、それを読むことが精度と速度のバランス上有効と思われるなら、
利用できます。
[26]
また、 <meta charset> に関する prescan の処理には
1024 バイト の推奨がありますが、その後の頻度解析等の手法 には長さの制限がなく、
現実的に 1024 バイト よりも多く読み込む必要がありそうです。
encoding sniffing algorithm
[27]
Chrome はネットワーク から最初に届いたデータに対して文字コードの判定 を行います。
>>25
[35]
Firefox は最初の 1024 バイトが届いたら prescan や chardetng
による判定を行います。本構文解析 で発見された <meta charset>
で異なる結果が得られれば符号化の変更 を行います。
すべて読みこんだら改めて chardetng による判定を行い、
異なる結果が得られれば符号化の変更 を行います。
>>24
[38]
Firefox の挙動は Chrome の挙動だとネットワーク の状況依存になってしまい結果が安定しないことへの批判です
>>24 Chrome が最初から正しい符号化 でレンダリングの開始 となることが多いのに対し、
Firefox は文字化け 状態で読み込んだ後に再読み込みとなることが多く、
Chrome の挙動に分があるように感じられます。
[24]
Webブラウザー の挙動を厳密に推定するのは難しく感覚的になってしまいますが、
Chrome と比べると Firefox は符号化の変更 が必要となって再読み込みすることが多い
(資源ヘッダー の処理で正しい判定に失敗することが多い) ように感じられます。
Chrome が <meta charset> の prescan で 1024 バイト以上読んでいるのか、
その他の要因によるのかは不明です。
2025-11-09T02:10:40.400Z [39]
HTML文書 の先頭には本文の前に文書型宣言 や head 要素 などが書かれます。
<meta charset> がそこに書かれていればいいのですが、
それが無いときの文字コードの判定 に必要な非ASCII文字 はそれほど多くありません。
title 要素 の中身が主となりますが、それすら
ASCII文字 のみで構成されることも珍しくありません。
1024バイトは意外と短いのです。
[40]
古い HTML文書 が多い Internet Archive に至っては HTML文書 の先頭部分に
Internet Archive のヘッダーのための要素 群が挿入されています。
そのために本文は先頭から非常に遠い部分に追いやられてしまいます。
[41]
非ASCII文字 があればいいというものではなく、
データが長ければ長いほど文字コードの判定 の精度は高くできます。
1024バイト中の数バイトだけでは正しい判定が難しいことも多いです。
[42]
それではデータをすべて使うのが常に正しいかというと、そうとも限りません。
例えば数ギガバイトの動画データが何らかの誤りで文字コードの判定 処理に与えられたとき、
それをどこまで処理しても意味はありません。そこまで極端な例でなくとも、
確かに数百メガバイトの ASCII文字 の後に非ASCII文字 が来るという事例が考えられないわけではありませんが、
そのようなテキストファイル の文字コードの判定 に失敗することが実装の責めに帰するとは考えにくく、
どちらかといえば無制限の長いデータの処理に伴う性能その他の悪化やセキュリティー問題のおそれを防ぐことハードウェア制限条項 の方が重要です。
[43] 推奨される実装戦略:
[44] prescan [45] 1024バイトに到達したら打ち切る[46] 500 ms に到達したら打ち切る[47] 頻度解析等の手法 [48] データが到着するたびに入力として供給する[50] prescan の方で結果が得られたら打ち切る[49] 確定的結果が得られたらそれを返して打ち切る[51] 途中の暫定結果を返しつつ判定を継続[52] 既に1024バイト以上あれば、1024バイト以上の部分も含め、それを最大まで使ったときに[53] 500 ms に到達したときに[54] 最大 (100MB程度) まで使ったら途中結果を返して打ち切る[55] データの末尾に到達したら結果を返して終了[14] CSS では、先頭 1024 バイト を使うと規定されています >>13
歴史 [10] MIME sniffing 、HTML charset sniffing も参照。
[16] [ c] (0) Change the limit for where charsets should be given to the fi…Hixie 著, 2011-02-09 09:02:05 +09:00 ) https://github.com/whatwg/html/commit/51babfe760a1dbe28c4521b2070e692ac872550a
[25]
chardetng: A More Compact Character Encoding Detector for the Legacy Web , Henri Sivonen , 2020-06-08T16:23:51.000Z , 2025-11-18T12:49:24.545Z https://hsivonen.fi/chardetng/