Closed Bug 673396 Opened 13 years ago Closed 10 years ago

XHTML 1.0 with xml header, UTF-8 encoding error

Categories

(Firefox :: General, defect)

6 Branch
All
Other
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 673087

People

(Reporter: olefebvre, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.825.0 Safari/535.1

Steps to reproduce:

I use many XHTML 1.0 files with charset specified through a xml header:
Similar to this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
<head>
<title>...</title>



Actual results:

UTF-8 encoded characters are not correctly displayed nor sent to the server. Instead the usual garbage @Ã etc... is displayed or sent through POST.

I specified the charset through a meta in the header and it fixed the issue
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>...</title>


Expected results:

According to the XHTML spec the way i encode is correct, and was working perfectly in the past (opera, chrome, safari are working fine atm). The problem appeared first in the FF5 Linux branch only, but in FF6 even windows version is incorrect.
Can you attach a test file? Also some content with utf8 chars, not just headers. Thanks.
I thought I had just encountered this exact bug on http://www.defmacro.org/ramblings/fp.html and attempted to reproduce it locally, however in doing so I discovered that the actual problem is the use of the text/html MIME-type.  If the document is correctly served as application/xhtml+xml (or another xml type) Firefox will correctly take the encoding from the XML directive.  If it is served as text/html it will not, which is the mistake the linked page is making, and from the look of it the reporter is too since the meta element in the second code snippet specifies text/html.

Based on that I'd recommend closing as a duplicate of bug 673087
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.