UTF8 encoding Web page contains files with empty lines before the resolution

The page uses the UTF8 code, the head and the tail uses the method which the template contains the file, the result head and the tail end each to have more than one 10px empty line, nothing.

The reason is all the use of UTF8 encoding, including files, the final binary stream contains a number of UTF8 BOM tags, ie can not normally resolve the page contains multiple UTF8 BOM tag, directly replace the actual display of the return, which led to a blank line, and Firefox does not have this problem.

Therefore, if the template contains a method containing multiple UTF8 files need to save with UltraEdit saved as a feature selection UTF8 no BOM format saved.

In addition, if the Chinese page is in the HTML head tag, place the title tag in the <meta http-equiv= "Content-type" content= text/html; Charset=utf-8″/> will cause the page to be blank before.

So UTF8 pages should use standard order

<meta http-equiv= "Content-type" content= "text/html; Charset=utf-8″/>
<meta http-equiv= "Content-language" content= "ZH-CN"/>
<meta name= "Robots" content= "Index,follow"/>
<meta name= "keywords" content= ""/>
<meta name= "description" content= ""/>
<meta name= "rating" content= "General"/>
<meta name= "Author" content= ""/>
<meta name= "Copyright" content= ""/>
<meta name= "generator" content= ""/>
<title></title>

BOM Header: \XEF\XBB\XBF,PHP4, 5 still ignore the BOM, so the direct output before parsing. There is a specific description of this issue in this w3.org standard FAQ:

Http://www.w3.org/International/questions/qa-utf8-bom

Specifically as follows:

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 is the operating system that uses a BOM to mark the encoding of a text file: XP Professional, default character set: Chinese

1) Notepad: You can automatically identify the Utf-8 code format file without a BOM, but you can not control whether to add a BOM when you save the file, if you save the file, you will add a unified BOM.

2) EditPlus: Can not automatically identify the UTF-8 coding format file without a BOM, file save, select UTF-8 format, will not be in the file header write BOM header.

3) UltraEdit: For character encoding is the most powerful, you can automatically identify with the BOM and without the BOM Utf-8 file (can be configured), save the time can be configured to choose whether to add a BOM.

(Notably, you need to choose to save as Utf-8 no BOM format when saving a newly created file)

Later found that Notepad + + also for Utf-8 BOM support is better, recommended that you use.