1. The html generated using the smarty template in php has a blank line at the top of the browser.
2. Use firedebug to find that the meta and link tags are in the body tag.
This machine It runs fine on wmap, but the service sent to the remote server is IASP, and the above bug will appear.
Looked at the source file, the text is the same. But when saving, it prompts an encoding problem. It is probably a utf-8 problem. .
I searched online and found that it is a utf-8 BOM problem.
Solution: Use UltraEdit32 to edit the smarty template file that is the referenced template file (such as include header, footer and other files) Save it all as a utf-8 file without BOM.
Other supplementary instructions:
The page is encoded in UTF8, and the header and tail use the method of the template containing the document. As a result, the header and tail are gratuitous. There is an extra blank line of about 10px on each side, and nothing.
The reason is that all UTF8 encoding is used. When including documents, the final binary stream contains multiple UTF8 BOM tags. IE cannot parse pages containing multiple UTF8 BOM tags normally and directly replaces them with the actual displayed ones. Enter, which results in a blank line, but Firefox does not have this problem.
Therefore, if the template uses the included method to contain multiple utf8 documents and needs to be saved with ultraedit, just select utf8 and save it in no BOM format.
In addition, if the Chinese page puts the title tag in front of in the html head tag will result in a blank page.
Therefore, utf8 pages 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=”" /> <meta name=”generator” Content=”" /> <title></title>
BOM header: \xEF\xBB\xBF. PHP scripts 4 and 5 still ignore BOM, so they are output directly before parsing.
There is a special description of this issue in the w3.org standard FAQ:
www.w3.org/International/questions/qa-utf8-bom
The details are as follows:
In the UCS encoding, there is a char called "ZERO WIDTH NO-BREAK SPACE", and its encoding is FEFF. FFFE is a char that does not exist in UCS, so it should not appear in the actual transmission. The UCS specification recommends that we transmit char "ZERO WIDTH NO-BREAK SPACE" before transmitting the byte stream. In this way, if the receiver receives FEFF, it indicates that the byte stream is Big-Endian; if it receives FFFE, it indicates that the byte stream is Little-Endian. Therefore char "ZERO WIDTH NO-BREAK SPACE" is also called BOM.
UTF-8 does not require a BOM to indicate the byte order, but you can use the BOM to indicate the encoding method. The UTF-8 encoding of char "ZERO WIDTH NO-BREAK SPACE" is EF BB BF. So if the receiver receives a byte stream starting with EF BB BF, it knows that it is UTF-8 encoded.
Windows uses BOM to mark the encoding method of text documents. Systam: WindowsXP Professional, default char set: Chinese
1) notepad: can automatically identify utf- without BOM. 8 encoding format document, but you cannot control whether to add BOM when saving the document. If you save the document, BOM will be added uniformly.
2) editplus: cannot automatically recognize documents in UTF-8 encoding format without BOM. When saving the document, select UTF-8 format and will not write BOM header in the document header.
3) UltraEdit: The most powerful function for char encoding, it can automatically identify UTF-8 documents with BOM and without BOM (can be configured); when saving, you can choose whether to add BOM through configuration.
(Special attention should be paid to Yes, when saving a newly created document, you need to choose to save it as utf-8 no bom format)
Later I found that Notepad ++ also has better support for utf-8 bom, and I recommend everyone to use it.
More The html meta and link tags generated by php are in the body tag. There is a blank line at the top. For related articles, please pay attention to the PHP Chinese website!