If you're interested in what was going on,
http://www.w3.org/International/questions/qa-utf8-bom explains it well.
On Fri, Jan 15, 2010 at 9:40 AM, Tennille Herron <[log in to unmask]> wrote:
> Hi Steve, thanks for the feedback. The value was declared in the content
> type header and BOM was tried without success (after UTF-8 displayed the
> characters). I was able to use David's advise in regards to the hex editor.
> Using the hex editor, with the charset = UTF-8 did the trick. Thanks again,
> Steve Clay wrote:
>> The old template was set to a charset of "ISO-8859-1" while the new
>>> template is set to a charset of "UTF-8". The server is still reading
>>> the encoding as: "ISO-8859-1" even though the pages have been saved
>>> using UTF-8.
>> Saving as UTF-8 doesn't mean browsers can guess that you did*. You should
>> always declare explicitly--ideally in the Content-Type header--the encoding
>> of the file.
>> Browsers do try to guess, but it's frequently an error-prone process.
>> Here's what most browsers currently do:
>> *If you include the UTF-8 BOM browsers can guess, but BOMs can cause
>> problems in CGI scripts, notably PHP.