Bug 14338 – Safari 3.0.2 beta for windows detects wrong encoding

• Status: RESOLVED
• Resolution: INVALID
• Component: DOM

[Tore B. Krudtaa]

Why does Safari 3.0.2 beta for windows detect wrong encoding:

I'm using this in the head section of the page:
<meta http-equiv="Content-Type" content="text/html" charset="UTF-8">

But Safari chooses to use "Default" text encoding.. (whatever that is)....
and the some of the letters are wrong.

If I do:
View -> Text Encoding -> Unicode (UTF-8)

Then the text gets okay, but why does the safari browser not detect it automatically?

It (the page) works in browsers like Firefox, IE, Opera, Netscape.

[David Kilzer (:ddkilzer)]

(In reply to comment #0)
> I'm using this in the head section of the page:
> <meta http-equiv="Content-Type" content="text/html" charset="UTF-8">

This is incorrect.  It should read:

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

> It (the page) works in browsers like Firefox, IE, Opera, Netscape.

Do these other browsers support the "charset" attribute, or does this simply work "by chance" because they use a different default charset?

[Mark Rowe (bdash)]

Can you please provide a URL which demonstrates this issue?

The HTML snippet you provided:
<meta http-equiv="Content-Type" content="text/html" charset="UTF-8">

is not the correct syntax for what you are trying to accomplish.

Try:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

If you can provide a link that demonstrates the issue as well we may be able to handle the incorrect code snippet you provided.

[Alexey Proskuryakov]

(In reply to comment #0)
> I'm using this in the head section of the page:
> <meta http-equiv="Content-Type" content="text/html" charset="UTF-8">
> 
> But Safari chooses to use "Default" text encoding.. (whatever that is)....

  This is kinda sorta OK - Safari doesn't display the detected encoding. I think it's really unfortunate, but that's the current design. I think I filed a Radar for it, but I cannot find the number right now.

> and the some of the letters are wrong.

  This would be a bug, but I couldn't reproduce it. WebKit is supposed to honor the charset declaration, even if it's written this way.

  Please provide an URL of a page where this fails, or attach a test case.

[Tore B. Krudtaa]

(In reply to comment #1)
> (In reply to comment #0)
> > I'm using this in the head section of the page:
> > <meta http-equiv="Content-Type" content="text/html" charset="UTF-8">
> 
> This is incorrect.  It should read:
> 
> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> 
> > It (the page) works in browsers like Firefox, IE, Opera, Netscape.
> 
> Do these other browsers support the "charset" attribute, or does this simply
> work "by chance" because they use a different default charset?
> 

Hi there.

Sorry, my fault but found another difference between Safari and the rest
of the browsers.

Have now changed the line to:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

So now safari is using the correct encoding.

BUT.... I originally had forgot to remove an ECHO line in my PHP script before
the doctype part in the page.

And that echo line still causes Safari to use wrong encoding and wrong characters, also with the corrected meta line.
The other browsers still show the page with correct encoding even with the ECHO line before the doctype line.

Anyway thanks for the meta line correction.

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> BUT.... I originally had forgot to remove an ECHO line in my PHP script before
> the doctype part in the page.
> 
> And that echo line still causes Safari to use wrong encoding and wrong
> characters, also with the corrected meta line.
> The other browsers still show the page with correct encoding even with the ECHO
> line before the doctype line.

Please attach a test case (just the HTML output from the script) that demonstrates the issue.  Thanks!

[Nicholas Shanks]

More importantly, what Content‐Type header is your web server sending out?
the http‐equiv tag is ignored if the transport is HTTP and a Content‐Type header is provided. Perhaps you are not specifying the charset at all there?

[Alexey Proskuryakov]

(In reply to comment #6)
> the http‐equiv tag is ignored if the transport is HTTP and a Content‐Type
> header is provided. Perhaps you are not specifying the charset at all there?

This is not true. A charset specified in Content-Type HTTP header overrides one from a META, but a plain "Content-Type: text/html" doesn't disable META checking.

[Alexey Proskuryakov]

No reply to a request for additional information in three months, closing.