It was solved locally, but there were still blank lines when uploading to the server. After working on it all morning, it almost crashed. Finally, I decided to find a way to solve it myself. After several hours of exploration, I finally found a perfect solution.
Using the PHP display buffer display principle, successfully removed
Add a line of ob_start() at the top of PHP; then add ob_end_clean() before the template is displayed; add ob_end_flush() after the template is displayed;
This problem is solved , now give the overall structure example code:
Copy code The code is as follows:
ob_start(); //This is the php logical operation
ob_end_clean(); //This is PHP template display
ob_end_flush();
?>
Additions from other netizens:
A problem that has never been solved during development, favorite
The page uses UTF8 encoding, and the header and tail use the method of template inclusion files. As a result, there is an extra blank line of about 10px at the head and the tail for no reason, and there is nothing.
The reason is that they are all encoded in utf8. When including files, 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 carriage return, which causes A blank line, but firefox doesn't have this problem.
So if the template uses the inclusion method to contain multiple utf8 files 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, the page will be blank.
So utf8 The page should use the standard order
Copy the code The code is as follows:
< /title>
BOM header: xEFxBBxBF, PHP4 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:
http://www .w3.org/International/questions/qa-utf8-bom
The details are as follows:
There is a character called "ZERO WIDTH NO-BREAK SPACE" in UCS encoding, and its encoding is FEFF, while FFFE is not in UCS. The characters exist, so they should not appear in the actual transmission. The UCS specification recommends that we transmit the character "ZERO WIDTH NO-BREAK SPACE" before transmitting the byte stream. This way, if the receiver receives FEFF, it indicates this byte stream. It is Big-Endian; if FFFE is received, it means that the byte stream is Little-Endian. Therefore, the character "ZERO WIDTH NO-BREAK SPACE" is also called BOM
UTF-8 does not require BOM to indicate the byte. The sequence, but the BOM can be used to indicate the encoding method. The UTF-8 encoding of the character "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 this is. UTF-8 encoded.
Windows is an operating system that uses BOM to mark the encoding method of text files: WindowsXP Professional, default character set: Chinese
1) notepad: can automatically identify utf-8 encoding format files without BOM, but cannot control the saving Whether to add bom when file is saved. If the file is saved, bom will be added uniformly.
2) editplus: cannot automatically recognize files in UTF-8 encoding format without BOM. When saving the file, select UTF-8 format and will not write BOM header in the file header.
3) UltraEdit: has the best character encoding function Powerful, it can automatically identify utf-8 files with and without BOM (can be configured); when saving, you can choose whether to add BOM through configuration.
(Special note is that when saving a newly created file, you need to select Save 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.
The above has introduced the solution to the problem of empty lines in the http://www.kaqima.com/index.ht PHP template, including the content of http://www.kaqima.com/index.ht. I hope you can learn more about PHP tutorials. Interested friends help.