Msg#: 4326844 posted 12:11 pm on Jun 16, 2011 (gmt 0)
I arrived on this forum after hitting an identical issue to an old thread ([webmasterworld.com ]).
Unfortunately, that thread is too old to append a message to but I wanted to share my findings with the community to help others in the same situation.
The issue was that my application had a couple of pages which appeared fine to me but initially displayed as blank pages to my clients until refresh was pressed.
My clients were using IE6 but my copy of IE6 displayed ok.
After playing around a little I discovered that although I could see the offending pages that my client could not I couldn't click the 'View Source' command on those pages until I too refreshed the page.
I also found out that similar to the old thread if I removed the meta tag completely the problem disappeared. The meta tag looked like this:
I couldn't understand why other pages which also used this meta tag had no problems so I studied the problem some more.
The solution turned out to be the way the source files had been edited. IE6 seems to have a problem in that if you advertise the page is UTF-8 then the file your server serves must be in the format which includes the 'BOM' characters.
To fix my problem all I had to do was open the offending source files in a UTF-8 aware editor (I used Notepad++) and then save it again as UTF-8 with BOM.
Msg#: 4326844 posted 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.
Msg#: 4326844 posted 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.
Msg#: 4326844 posted 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!?)
Msg#: 4326844 posted 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.