3 ms·
That requires scanning the whole file before guessing the encoding, which browsers don’t do for performance reasons (and also because an HTML document may never
by wolfgang42 5y ago
That requires scanning the whole file before guessing the encoding, which browsers don’t do for performance reasons (and also because an HTML document may never end, it’s perfectly valid for the server to keep appending to the document indefinitely). The HTML5 spec does recommend doing this on the first 1024 bytes, though.
- magicalhippo 5y agoBrowsers are quite happy on re-rendering the whole document multiple times though, so it could just switch and re-decode when UTF-8 fails. Sure it wouldn't be the fast path, but sure beats looking at hieroglyphs. And yeah, add some sensible limits to this logic of course. Most web pages aren't never-ending nor multi-GB of text.
- colejohnson66 5y agoThe “sensible limit” is 1024. That’s what the standard is saying.
- magicalhippo 5y agoNot really. I can write a lot of Norwegian text, especially with HTML overhead of scripts, inline CSS and whatnot, before needing a non-ASCII Norwegian character. Also the only reference I find to this 1024 limit is for the charset meta element[1] in HTML5, which also seems highly redundant given that the very same page states UTF-8 must be used regardless. Limits are good, but 1k is way to low. [1]: https://html.spec.whatwg.org/multipage/semantics.html#charset https://html.spec.whatwg.org/multipage/semantics.html#charse...