Occasionally garbled utf8php files with bom ..

Has anyone ever encountered a similar situation? Because it does not always appear, and the simplest code has a problem, I don't want to think about the code. I 've been wondering if php expansion is a problem. Later, my colleagues removed the bom, And the surprise was even more depressing... It's too embarrassing, though... has anyone ever encountered a similar situation?

Because it does not always appear, and the simplest code has a problem, I don't want to think about the code. I 've been wondering if php expansion is a problem.

Later, my colleagues removed the bom, And the surprise was even more depressing... Too shameful

Although the problem has been solved, What is the specific reason?

Reply content:

Has anyone ever encountered a similar situation?

Because it does not always appear, and the simplest code has a problem, I don't want to think about the code. I 've been wondering if php expansion is a problem.

Later, my colleagues removed the bom, And the surprise was even more depressing... Too shameful

Although the problem has been solved, What is the specific reason?

Unicode is unique, but the Unicode encoding method is not unique. The encoding method may be unique, but the large and small ends are not necessarily unique. It is not easy to open a "Unicode" file.

BOM is to encode a Unicode reserved character U + FEFF according to the encoding method of the file storage, and then insert it to the front edge of the file content. In this way, different Unicode codes are used to parse the file header, so that you can know the file encoding method and the large and small order. The result is that the file header contains two or three more bytes.

With BOMAll programs must be modified for BOM.This is undoubtedly a "big toss" behavior. Therefore, BOM is generally not considered a good idea. I can think of two issues caused by BOM:

• PHP cannot specify the header (because BOM is equivalent to enabling output)
• The Shabang flag of UNIX executable scripts (#!) Cannot read

Always useUnicode for UTF-8 encoding without BOMIs definitely the most practical strategy that causes the least trouble. UTF-8 is one of the best practices for Unicode.

It must be pointed out that Microsoft often does not need DOM, and the most typical example is the notepad ). So never be lazy at any time using notepad to edit PHP. Chinese pride Notepad ++ is the best choice for Windows.

Never forget:Microsoft is a technology lagging behind and will only sneer at the open-source world that surpasses itself, never truly correct the industry's cancer. However, even if it doesn't reach this level, it will not be much worse. Keep yourself away from Microsoft from 1.1 drops, making life easier.

BOM: Byte Order Mark

UTF-8 BOM is also called UTF-8 signature, in fact, the BOM of the UTF-8 has no effect on the UFT-8, is to support the UTF-16, The UTF-32 is added to the BOM, BOM signature is to tell the weak Editor (Notepad) the encoding used by the current file for easy identification by the editor.

At the beginning of the design, PHP did not take into account the BOM header issue, so it is easy to cause strange issues due to the BOM header, such as encoding conversion failure and style disorder, and this issue is quite hidden, it is difficult to determine the file where the problem occurs (imagine which file contains the BOM header from tens of thousands of engineering files without tools ).

The BOM header is a hidden character, non-editable character, just like a common empty file. When we write

{BOM header}
  

When file. php is contained by other files, the BOM header is output to the browser as the output content outside the php tag, causing problems.

Young, cherish life, stay away from BOM.

The General Editor cannot detect utf8 + bom, such as Notepad and wordpad. You must use editplus, ultraedit, and other text editors for detection, and save it as utf8 no bom format.

The cause of the problem may be that you have used a weak text editor in the notepad class to edit it.