PHP generated HTML meta and link tags have a blank line at the top of the body tag

HTML generated with the Smarty template in 1.php has a blank line at the top of the browser.

2. Use Firedebug to find meta and link tags in the body tag.

On this machine wmap run nothing, sent to the remote server is iasp service, the above bug will occur.

See the next source file, text the same. However, the encoding problem is prompted on save. It's utf-8.

Found on the Internet, is the Utf-8 BOM problem.

Workaround: Use UltraEdit32 to save Smarty template files that are referenced template files (such as include Header,footer and other files) as a non-BOM utf-8 file.

Other supplementary notes:

The page uses UTF8 encoding, the head and tail use the template contains the document method, the result of the head and the tail of the end of a few empty lines of about 10px, nothing.

The reason is that all of the UTF8 encoding, including the document, the final binary stream contains multiple UTF8 BOM tags, ie can not parse the page containing multiple UTF8 BOM, directly replaced with the actual display of the carriage return, which leads to a blank line, and Firefox does not have this problem.

Therefore, if the template contains a method containing multiple UTF8 documents need to be saved with UltraEdit Save As feature selection UTF8 no BOM format to save.

Also, 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″/> front causes the page to be blank.

So the UTF8 page should use the 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= "/> <m ETA name= "generator" content= ""/> <title></title>

BOM Header: \xef\xbb\xbf,php script 4, 5 is still ignoring the BOM, so the direct output before parsing.

There is a special description of this issue in this w3.org standard FAQ:

Www.w3.org/International/questions/qa-utf8-bom

Specific as follows:

In the UCS encoding there is a char called "ZERO WIDTH no-break SPACE", and its encoding is Feff. Fffe is not a char in UCS, so it should not appear in the actual transfer. The UCS specification recommends that we transfer char "ZERO WIDTH no-break SPACE" before transmitting the byte stream. This means that if the recipient receives Feff, the byte stream is Big-endian, and if Fffe is received, it indicates that the byte stream is Little-endian. So Char "ZERO WIDTH no-break SPACE" is also called a BOM.

The UTF-8 does not require a BOM to indicate byte order, but it can be used to indicate the encoding using a BOM. The UTF-8 encoding for char "ZERO WIDTH no-break SPACE" is EF BB BF. So if the receiver receives a byte stream beginning with the EF BB BF, it knows that this is UTF-8 encoded.

Windows is an operation that uses a BOM to mark the encoding of a text document SYSTAM:WINDOWSXP Professional, default char set: Chinese

1) Notepad: can automatically recognize the UTF-8 encoded format document without BOM, but can not control whether the BOM is added when saving the document, if the document is saved, the BOM will be added uniformly.

2) EditPlus: cannot automatically recognize the UTF-8 encoded format document without BOM, when the document is saved, select the UTF-8 format, do not write the BOM header on the document header.

3) UltraEdit: The most powerful feature for Char encoding, can be automatically identified with the BOM and without BOM Utf-8 document (can be configured), save the time can be configured to choose whether to add a BOM.
(It is important to note that when you save a newly created document, you need to select Save as Utf-8 no BOM format)

Later found Notepad + + also for Utf-8 BOM support is better, recommend everyone use.