Originally Posted by http://juicystudio.com/article/utf-byte-order-mark.php
Author: Gez Lemon
Yesterday, I stumbled across a problem when saving files in UTF format. When the script is copied to the server, I received a warning stating that the headers could not be modified as they had already been sent. I was sure that the headers hadn't already been written, but as far as PHP was concerned, they had. Having argued unsuccessfully with machines in the past, I decided to believe it, but couldn't understand how they could have been written. Saving the same file in regular ANSI solved the header problem, but the characters didn't display correctly, as they were no longer encoded correctly.
Simon Carlisle emailed me a link to a document called, Guide To Unicode , which mentions the type of problem I encountered in Part 3 of the article . The article mentions that if a UTF file is incorrectly declared as ISO-8859-1 by the HTTP response headers, a Byte Order Mark (BOM) will be interpreted as data by Apache, by which time the headers should have been written; hence the warnings I was receiving. What I couldn't understand is why the HTTP headers were incorrectly declaring ISO-8859-1.
The BOM consists of three bytes to distinguish the big endian and little endian byte order for UTF-16. As there's no requirement for UTF-8 to distinguish between big endian and little endian byte order, there's no reason to include a BOM; particularly if it's being interpreted as data on the server. Stupidly, my editor of choice is Notepad, which doesn't have an option to save as UTF without a BOM. In a desperate attempt, I wrote a simple script to remove the first three-bytes from the UTF file, to see if the BOM was definitely the problem in my case.
01-11-2013, 10:46 PM
Threaded Mode