Home > Article > Backend Development > The html meta and link tags generated by php are in the body tag and there is a blank line at the top_PHP tutorial
The html meta and link tags generated by php are in the body tag and there is a blank line at the top_PHP tutorial
- WBOYOriginal
- 2016-07-21 15:37:40759browse
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.
Run wmap on this machine It’s okay, the service sent to the remote server is an IASP service, and the above bug will appear.
Looking 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 save all the smarty template files that are referenced template files (such as included header, footer, etc. files) as UTF-8 file without BOM.
Other supplementary instructions:
The page is encoded in UTF8, and the header and tail use the method of template containing the document. As a result, the header and tail are unexplained. Out a blank line of about 10px and nothing.
The reason is that they are all encoded in utf8. 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 ones actually displayed. Enter, which results in a blank line, but Firefox does not have this problem.
Therefore, if the template uses the included method and contains multiple utf8 documents that need to be saved using ultraedit, just select utf8 and save them in no BOM format.
In addition, if the Chinese page has the title tag in the html head tag, place it in front of will result in a blank page.
So the utf8 page should use the standard order
BOM Header: xEFxBBxBF, PHP scripts 4 and 5 still ignore BOM, so they are output directly before parsing.
There is a dedicated description of this issue in the w3.org standard FAQ:
www.w3.org/International/questions/qa-utf8-bom
The details are as follows:
There is a char called "ZERO WIDTH NO-BREAK SPACE" in UCS encoding, 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 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 it is recommended for everyone to use it.