lucy24
msg:4326988 | 6:08 pm on Jun 16, 2011 (gmt 0) |
You have now exchanged one problem for another, because some browsers dislike the BOM [w3.org] very much and will display it as a series of unwanted letters at the very beginning of the file. Or worse.
|
srchmeister
msg:4327094 | 9:35 pm on Jun 16, 2011 (gmt 0) |
Thanks for the heads-up lucy24 and the great link you mentioned.
I've since found that many of my co-workers have their editors (Eclipse) set to use a number of character sets by default other than UTF-8 so at least this exercise will have one useful outcome.
From the article you linked to it seems that the BOM is unnecessary for UTF-8 in any case so I will probably avoid it and find another workaround... like remove the meta tag as mentioned in the original article.
|
penders
msg:4327437 | 5:22 pm on Jun 17, 2011 (gmt 0) |
Just wondering if the location of the Content-Type meta tag makes a difference? For example, if you put it as high as possible in the document, before the TITLE element, immediately after the opening HEAD tag?
Also, does the meta tag match the HTTP header sent from the server? If you aren't explicitly setting the HTTP header, then the server is likely to be sending one of its own. The HTTP header should override the meta tag in the document. However, why removing the meta tag in the document should resolve the issue is a bit odd.
As mentioned, the BOM should not be used. This is what the character encoding part of the Content-Type header is for. (However, I was a bit surprised to read in lucy24's linked article that UTF-16 and UTF-32 documents under HTML5 do require the BOM!?)
|
srchmeister
msg:4327587 | 10:54 pm on Jun 17, 2011 (gmt 0) |
I had the same thought as you and tried various combinations and placements of the META tag. I even tried changing the charset to a non-existent value like 'blubble' and the problem went away every time.
The problem only occurs if the charset value is set to 'UTF-8' and the source file is actually encoded in UTF-8 without the BOM.
I will have to double-check if the web server (Tomcat 6) is set to use UTF-8 in the response header... I'm pretty sure it is but I will need to check.
|
TenTonJim
msg:4334349 | 5:20 am on Jul 3, 2011 (gmt 0) |
Also, my experience with this was that the "with BOM" did not validate and the w3c checker page specifically pointed out that it was because of the byte order mark (BOM). Love that Notepad++ btw :~)
|
mrtonyg
msg:4337848 | 3:57 am on Jul 11, 2011 (gmt 0) |
I read this topic while just browsing and realized that it was happening to me also.
I didn't give it a second thought just because I was using "Multiple IE's" and thought it was one of the quirks.
I went ahead and deleted the meta tag with the UTF-8 encoding and realized that my server was sending the data as iso-8859-1.
Made the correction at the server to match the meta tag with the UTF-8 encoding and all is fine!
|
mrtonyg
msg:4337861 | 5:12 am on Jul 11, 2011 (gmt 0) |
I forgot to add...make sure that the meta tag includes the space after "text/html: like so:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
