UTF-8 BOM may lead to style-disordered solutions _ Related Tips

When you use UTF-8 encoding to write a Web page, it is often the problem with the BOM (Byte order Mark) that some unknown blank lines or garbled characters often appear in the Web page. These are all because the UTF-8 encoding is not mandatory for the BOM. As a result, utf-8 encoding can be handled differently when saving files. For example, some browsers (FireFox) can automatically filter out all Utf-8 BOM, and some (IE) can only filter out a BOM (why is it once?) This problem occurs when you Include multiple files.


Use EditPlus or another editor to delete the BOM signature in the file, refresh the page again, the style is normal.

Find a description of the BOM here that may help you understand:

In the UCS code there is a character called ZERO WIDTH No-break Space, and its encoding is Feff. Fffe is not present in UCS, so it should not appear in the actual transmission. UCS specification recommended that we transfer the byte stream before the transmission of the character "ZERO WIDTH no-break space." This means that if the recipient receives the Feff, the byte stream is Big-endian, and if Fffe is received, it indicates that the byte stream is Little-endian. Therefore, the character "ZERO WIDTH No-break Space" is also called the BOM.

UTF-8 does not require a BOM to indicate byte order, but you can use a BOM to indicate how the encoding is encoded. The character "ZERO WIDTH no-break Space" UTF-8 code is the EF BB BF. So if the receiver receives the byte stream at the beginning of the EF BB BF, it will know that this is UTF-8 code.

Windows uses a BOM to mark the encoding of a text file.

...

In UTF-8 encoded files, the BOM accounts for three bytes. If you use Notepad to save a text file as UTF-8 encoding, open the file with UE, switch to hexadecimal edit state to see the beginning of the Fffe. This is a good way to identify UTF-8 encoded files, the software through the BOM to identify whether the file is UTF-8 code, many software also requires that the document must be read into the BOM. However, there are still a lot of software can not identify the BOM. When I studied Firefox, I knew that in the early versions of Firefox, there was no BOM for extensions, but the Firefox 1.5 version has already started supporting the BOM. It is now found that PHP does not support BOM.

PHP does not consider the issue of the BOM at design time, that is, he will not ignore the three characters of the BOM at the beginning of the UTF-8 encoded file. The three characters will be output directly because the code that must be followed by or <?php will be executed as PHP code. If the plugin file has this problem, will cause in the background page to activate or not activate the plugin after the display screen, if the template file has this problem, will cause these three characters direct output, resulting in a small empty line above the page. Foreign English plug-ins and templates are generally used in the encoding of ASCII code, there will be no BOM, only the domestic plug-ins and templates will be due to the author's ignorance caused problems. Also, when you modify the template, because the output page using UTF-8 encoding, then modify the template if you have to add Chinese characters, the file must be converted into UTF-8 encoding to normal display, this time if the editor used automatically added a BOM, will result in the output of these three characters on the page , the display effect will see the browser, is generally a blank line or a garbled.