A blank line solution appears in the PHP template
- 2020-03-31 21:35:06
- OfStack
In the local also solved, but uploaded to the server is still free line, made a morning, almost crashed, finally decided to find a way to solve, after several hours of groping finally have a perfect solution.
Using PHP display buffer display principle, successfully removed
Add a line ob_start() to the top of PHP; Then add ob_end_clean() before the template display; Add ob_end_flush() after the template is displayed.
So the problem is solved, now give the overall structure of the example code:
Other comments:
Development has been unable to solve a problem, collection
The page is encoded in UTF8, and the header and the tail of the page use the method of template containing files. As a result, the header and the tail end each have an extra blank line of about 10px, with nothing at all.
The reason is that they all use utf8 encoding. When the file 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 files by means of inclusion and needs to be saved by ultraedit, then 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 head: \xEF\xBB\xBF, PHP4, 5 still ignore BOM, so output directly before parsing.
The w3.org standard FAQ has a special description of this problem:
http://www.w3.org/International/questions/qa-utf8-bom
The details are as follows:
In UCS encoding there is a character called "ZERO WIDTH no-break SPACE", which is encoded as FEFF. FFFE is a nonexistent character in UCS, so it should not appear in actual transmission. The UCS specification recommends that we transmit the character "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. Therefore, the character "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 the character "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 operating system that USES a BOM to mark the encoding of text files: Windows xp Professional. The default character set is Chinese
1) notepad: it can automatically identify files in utf-8 encoding format without bom, but it cannot control whether to add bom when saving the files. If the files are saved, bom will be added uniformly.
2) editplus: the utf-8 encoding format file without bom cannot be automatically recognized. When saving the file, select utf-8 format, and the bom header will not be written in the header of the file.
3) UltraEdit: the most powerful for character encoding, it can automatically identify utf-8 files with bom and without bom (configurable); When saving, you can choose whether to add bom by configuration.
(in particular, when saving a newly created file, 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.
Using PHP display buffer display principle, successfully removed
Add a line ob_start() to the top of PHP; Then add ob_end_clean() before the template display; Add ob_end_flush() after the template is displayed.
So the problem is solved, now give the overall structure of the example code:
<?php
ob_start(); //This is a PHP logical operation
ob_end_clean(); //This is shown as a PHP template
ob_end_flush();
?>
Other comments:
Development has been unable to solve a problem, collection
The page is encoded in UTF8, and the header and the tail of the page use the method of template containing files. As a result, the header and the tail end each have an extra blank line of about 10px, with nothing at all.
The reason is that they all use utf8 encoding. When the file 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 files by means of inclusion and needs to be saved by ultraedit, then 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 head: \xEF\xBB\xBF, PHP4, 5 still ignore BOM, so output directly before parsing.
The w3.org standard FAQ has a special description of this problem:
http://www.w3.org/International/questions/qa-utf8-bom
The details are as follows:
In UCS encoding there is a character called "ZERO WIDTH no-break SPACE", which is encoded as FEFF. FFFE is a nonexistent character in UCS, so it should not appear in actual transmission. The UCS specification recommends that we transmit the character "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. Therefore, the character "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 the character "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 operating system that USES a BOM to mark the encoding of text files: Windows xp Professional. The default character set is Chinese
1) notepad: it can automatically identify files in utf-8 encoding format without bom, but it cannot control whether to add bom when saving the files. If the files are saved, bom will be added uniformly.
2) editplus: the utf-8 encoding format file without bom cannot be automatically recognized. When saving the file, select utf-8 format, and the bom header will not be written in the header of the file.
3) UltraEdit: the most powerful for character encoding, it can automatically identify utf-8 files with bom and without bom (configurable); When saving, you can choose whether to add bom by configuration.
(in particular, when saving a newly created file, 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.