The php generated HTML meta and link tags have a blank line at the top of the body tag
- 2020-03-31 20:50:20
- OfStack
1. HTML generated with smarty templates in PHP has empty lines at the top of the browser.
2. Use firedebug to find meta and link tags in the body tag.
This machine wmap run nothing, sent to the remote server is the service of IASP, will appear the above bug.
Look at the next source file, text is the same. But save when prompted encoding problem. Estimated to be utf-8 problem.
I found it on the Internet. It is utf-8 BOM problem.
Solution: use UltraEdit32 to save all smarty template files (including headers, footers, etc.) as utf-8 files without BOM.
Other supplementary notes:
The page is encoded in UTF8, the header and the footer use the method of the template containing the document, and the result is a blank line of about 10px at each end of the header and footer, with nothing at all.
The reason is that it all USES utf8 encoding. When the document is included, the final binary stream contains multiple utf8 BOM tags. IE cannot normally parse the page containing multiple utf8 BOM tags and directly replace it with the actual carriage return.
Therefore, if the template contains multiple utf8 documents with the included method and needs to be saved by ultraedit, save as utf8 without bom format.
In addition, if the title tag is placed in the HTML head tag of the Chinese page, < Meta content-type HTTP - equiv = "" Content =" text/HTML. Charset = utf-8 "/ > This leads to blank pages.
So utf8 pages should be in standard order
BOM header: \xEF\xBB\xBF, PHP scripts 4 and 5 ignore BOM, so output directly before parsing.
The w3.org standard FAQ has a special description of this problem:
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, which is coded FEFF. FFFE is a char that does not exist in UCS, so it should not appear in the actual transport. The UCS specification recommends that we transmit a char "ZERO WIDTH no-break SPACE" before transferring a byte stream. This indicates that the byte stream is big-endian if the recipient receives FEFF; 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.
Utf-8 does not require a BOM to indicate the byte order, but a BOM can be used to indicate the encoding. The utf-8 encoding of char "ZERO WIDTH no-break SPACE" is EF BB BF. So if the receiver receives a byte stream beginning with EF BB BF, it knows it's utf-8.
Windows is the operation Systam: Windows xp Professional, default char set: Chinese, using a BOM to mark the encoding of text documents
1) notepad: documents in utf-8 encoding format without bom can be automatically recognized, but it is not possible to control whether to add bom when saving documents. If documents are saved, bom will be added uniformly.
2) editplus: documents in utf-8 encoding format without bom cannot be automatically recognized. When documents are saved, utf-8 format is selected and bom header is not written in the document header.
3) UltraEdit: the most powerful for char encoding, it can automatically identify utf-8 documents with bom and without bom (configurable); When saving, you can choose whether to add bom by configuration.
(in particular, when saving a newly created document, choose to save it as utf-8 no bom format)
Later I found that Notepad ++ also supports utf-8 bom better, so I recommend you to use it.
2. Use firedebug to find meta and link tags in the body tag.
This machine wmap run nothing, sent to the remote server is the service of IASP, will appear the above bug.
Look at the next source file, text is the same. But save when prompted encoding problem. Estimated to be utf-8 problem.
I found it on the Internet. It is utf-8 BOM problem.
Solution: use UltraEdit32 to save all smarty template files (including headers, footers, etc.) as utf-8 files without BOM.
Other supplementary notes:
The page is encoded in UTF8, the header and the footer use the method of the template containing the document, and the result is a blank line of about 10px at each end of the header and footer, with nothing at all.
The reason is that it all USES utf8 encoding. When the document is included, the final binary stream contains multiple utf8 BOM tags. IE cannot normally parse the page containing multiple utf8 BOM tags and directly replace it with the actual carriage return.
Therefore, if the template contains multiple utf8 documents with the included method and needs to be saved by ultraedit, save as utf8 without bom format.
In addition, if the title tag is placed in the HTML head tag of the Chinese page, < Meta content-type HTTP - equiv = "" Content =" text/HTML. Charset = utf-8 "/ > This leads to blank pages.
So utf8 pages should be in 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 ignore BOM, so output directly before parsing.
The w3.org standard FAQ has a special description of this problem:
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, which is coded FEFF. FFFE is a char that does not exist in UCS, so it should not appear in the actual transport. The UCS specification recommends that we transmit a char "ZERO WIDTH no-break SPACE" before transferring a byte stream. This indicates that the byte stream is big-endian if the recipient receives FEFF; 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.
Utf-8 does not require a BOM to indicate the byte order, but a BOM can be used to indicate the encoding. The utf-8 encoding of char "ZERO WIDTH no-break SPACE" is EF BB BF. So if the receiver receives a byte stream beginning with EF BB BF, it knows it's utf-8.
Windows is the operation Systam: Windows xp Professional, default char set: Chinese, using a BOM to mark the encoding of text documents
1) notepad: documents in utf-8 encoding format without bom can be automatically recognized, but it is not possible to control whether to add bom when saving documents. If documents are saved, bom will be added uniformly.
2) editplus: documents in utf-8 encoding format without bom cannot be automatically recognized. When documents are saved, utf-8 format is selected and bom header is not written in the document header.
3) UltraEdit: the most powerful for char encoding, it can automatically identify utf-8 documents with bom and without bom (configurable); When saving, you can choose whether to add bom by configuration.
(in particular, when saving a newly created document, choose to save it as utf-8 no bom format)
Later I found that Notepad ++ also supports utf-8 bom better, so I recommend you to use it.