MIME was intended to describe the single character set of a file that >, so it's not worthwhile to break interoperability. > And besides, all browser now agree on the precedence of HTTP over Unfortunately, HTTP disagreed and it's too late to change that, because it would break pages that currently work due to Ruby's Postulate not being true for them.
> Indeed, Ruby's Postulate generally holds.
I finally shuddered and turned away to something else. The encoding of the preceding page in a test.Īs if the encoding of one page influenced the encoding of the next one. I was even accused of tweaking the encoding identification by forcing I was accused of saying things that did not happen (but that some 6 I opened another bug to be able say what I meant. See Description and read below.Īlexander Sachs changed the subject to mean a problem of his. Note: I did not report this problem at all. Would that mean? it's not a language either.Īlso, (Off) could be "no encoding auto-detection" to make it very clear My guess was that it meant utf-8 but what Please note that "Universal" is not a language and that I still do not Pity there are no HTTP links on system menus. I,Īnd everybody according to the bug title, had looked for it all over the This bug and you made me discover this explanation after 5 years.
The key hint is to understand that it's a language. > How would you make the menu "say" this? > (In reply to André Pirard from comment #17) :-(Īndré Pirard added the following comment to Launchpad bug report 206884: Or when displaying an HTML file whose character encoding is specified nowhere. > example, displaying a text file of which the character set is specified > The only case where character encoding mangling is necessary is when, for
#TEXT ENCODING FIREFOX AUTODRTECT UPDATE#
> and the browser won't update the page when it's written to aįirefox is supposed to if you choose the "complete" option in Save As. Unfortunately, HTTP disagreed and it's too late to change that, because it would break pages that currently work due to Ruby's Postulate not being true for them.Īnd besides, all browser now agree on the precedence of HTTP over, so it's not worthwhile to break interoperability. Indeed, Ruby's Postulate generally holds. > the contents of the page MUST specify the encoding, it knows better than an
#TEXT ENCODING FIREFOX AUTODRTECT CODE#
> Also, picking the character code from the HTTP request is an error because > webmaster to continue to make the same errors. > Using it instead of reporting an error to a webmaster is causing the > Character Encoding Autodetect is normally not needed because a page MUST Therefore, I think activity to get rid of the Russian and Ukrainian detectors ( bug 845791) would be more productive than activity to polish the menu. Once the only autodetector we have is the Japanese one, we should probably not bother the user about its existence but couple it with choosing Japanese in Preferences: Content: Advanced: Fallback Character Encoding. Note: My current belief is that we don't actually need the Russian and Ukrainian autodetectors. It means: If the type of the document is text/html or text/plain and there is no character encoding label on the HTTP layer or inside the document (in the text/html case) and there is no BOM at the start of the document, assume the language of the page is the one selected from the Auto-Detect menu and make a guess based on the contents of the file given that language assumption. > Assuming that it means that any indication of a character set is ignored ans > I think that the first thing for Character Encoding Autodetect to be less (In reply to André Pirard from comment #17)
0 kommentar(er)
