Hector Martin

It’s not a BOM - it’s a ZWNBSP. It’s a valid character and only a BOM if it’s at the beginning. As the actual bytes. It certainly is never a BOM if & encoded or encoded in any other form than the bytes defined as BOM.

U+2060 is only the new preferred word joiner, U+FEFF is still ZWNBSP: http://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt … It’s only BOM if it’s the UTF-8/16/32 bytes at start. But since the actual bytes are in here rather than & encoded, I now agree it’s most likely a template with a BOM being concatenated.

Of course if it were a BOM used the way BOMs are intended to be used it would have to be at the beginning of the file. There's no reason to have a legacy ZWNBSP here, so the point is it's most likely a BOM that snuck into a stupid place due to bad code.

See also http://unicode.org/faq/utf_bom.html#bom6 … "In the absence of a protocol supporting its use as a BOM and when not at the beginning of a text stream, U+FEFF should normally not occur." Yes, it will be treated as ZWNBSP, but that's for backwards compatibility and most likely a mistake.

Yes, with the new information that Chrome just rendered it with & encoding, I agree it’s a BOM that snuck into a template being concatenated. I guess someone needs to reconfigure their editor ;)