Solution to the blank line in front of the utf8 encoded web page when it contains files

<br />The page uses UTF8 encoding, and the header and footer use the template include file method. As a result, there is an extra blank line of about 10px in the header and footer for no reason, and there is nothing in it.
The reason is that all files are encoded in utf8. When the file is included, the final binary stream contains multiple UTF8 BOM tags. IE cannot parse the page containing multiple UTF8 BOM tags normally, and directly replaces them with the actual displayed carriage return, which results in a blank line. Firefox does not have this problem.
Therefore, if the template uses the inclusion method to include multiple utf8 files and needs to be saved using UltraEdit, select utf8 without BOM format in the Save As function.
In addition, if a Chinese page places the title tag before <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> in the html head tag, the page will be blank.
So utf8 pages should use 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. PHP4 and 5 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:
In UCS encoding, there is a character called "ZERO WIDTH NO-BREAK SPACE", and its encoding is FEFF. FFFE is a character that does not exist 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 transmitting the byte stream. In this way, if the receiver receives FEFF, it means that the byte stream is Big-Endian; if it receives FFFE, it means that the byte stream is Little-Endian. Therefore, the characters "ZERO WIDTH NO-BREAK SPACE" are also called BOM.
UTF-8 does not require BOM to indicate byte order, but can use BOM to indicate encoding. The UTF-8 encoding of the characters "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 is an operating system that uses BOM to mark the encoding of text files: WindowsXP Professional, default character set: Chinese
1) Notepad: It can automatically identify UTF-8 encoded files without BOM, but it cannot control whether to add BOM when saving files. If the file is saved, BOM will be added uniformly.
2) Editplus: It cannot automatically recognize UTF-8 encoded files without BOM. When saving the file, select UTF-8 format and the BOM header will not be written in the file header.
3) UltraEdit: It has the most powerful character encoding function. It can automatically identify UTF-8 files with and without BOM (configurable). When saving, you can choose whether to add BOM through configuration.
(It is important to note that when saving a newly created file, you need to choose to save it in 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.

<<: Detailed explanation of how tomcat calls Servlet initialization from source code analysis

>>: Use vue3 to implement a human-cat communication applet