[Noeol] and Feff problems in Linux under VI

"uptime.py" [Noeol] 69L, 2311C
"system/uptime.py" 69L, 2312C

' Noeol ' is ' no end-of-line ', that is, ' no end of line Terminator '

use the cat-a command to see how the two files differ in that the last line has a newline character

Cat-a uptime.py
if __name__ = = ' __main__ ': $
Uptime = Uptime () $
Print (uptime) $
[Email protected]:~/hanhuakai/pro_07/git_0709/ssapi#

Cat-a system/uptime.py
if __name__ = = ' __main__ ': $
Uptime = Uptime () $
Print (uptime) [Email protected]:~/hanhuakai/pro_07/git_0709/ssapi#

Problems with Linux under Feff

Because the Linux under VI can not directly write the Chinese comments, so only in Windows will write the code of the comments to the Linux server, but the problem also appears, I use in Windows notepad++ this editor (it feels pretty good, Syntax highlighting) Edit the source code, add comments after uploading to Linux no matter what language environment (LANG) is garbled, and then looked at the notepad++ settings, the default is ANSI format, and then converted to UTF-8 format encoding (because Linux has this format ), and then uploaded to the Linux server, Linux is also set to UTF-8 language environment, you can see the Chinese comments! However, it is found that the first line of each file will have a string of "<feff>". Google is the place to find the problem.

It turns out that this is an invisible character called the BOM (Byte Order Mark), which is Unicode used to identify the arrangement of internal encodings, which is required in UTF-16, UTF-32 encoding, and is optional in UTF-8. As a result, there is an editor that adds a BOM to the header of the file, and the syntax parser does not handle the confusion. The so-called BOM, full name is the byte order Mark, it is a Unicode character, usually appears at the beginning of the text, used to identify the byte order (Big/little Endian), in addition to identify the encoding (UTF-8/16/32), if it appears in the middle of the text, is interpreted as zero width no-break space.

This BOM can be set when you edit text, but you can only set it to bomb or nobomb the first time you edit it, and you can't change the encoding format after you've finished editing and saving it. About the Bomb command:

#设置UTF-8 encoding
: Set Fileencoding=utf-8
#添加BOM
: Set Bomb
#删除BOM
: Set Nobomb
#查询BOM
: Set bomb?

Here's an example:

Edit a Test text with VI test.txt

[Plain]View Plaincopy

1. Test bomb or Nobomb
2. ~
3. ~
4. ~
5. ~
6. ~
7. ~
8. ~
9. ~
10. ~

Query BOM results: (Set bomb?)

[Plain]View Plaincopy

1. ~
2. ~
3. ~
4. ~
5. ~
6. Nobomb

Change BOM Result: (Set bomb)

[Plain]View Plaincopy

1. ~
2. ~
3. ~
4. ~
5. ~
6. ~
7. Bomb

After saving it again, you will see the following:

And we do not have to upload the source code can not be modified, some people on the internet said it is possible to delete the BOM (grep-i-r-l $ ' \xef\xbb\xbf ' * | Xargs sed-i ' s/^\xef\xbb\xbf//; ' I tried not to, I do not know which Daniel pointing? The command to check if a BOM is included in the file is:

[Plain]View Plaincopy

1. Grep-i-r-l $ ' \xef\xbb\xbf ' *

This command is valid.

Since there is no way to rely on Linux under what command to delete the BOM, we can only process from the source, the code changed to a non-BOM UTF-8 encoding format. notepad++ has the option to convert this format:

After the conversion is saved and then uploaded to the Linux server, the problem is solved!!

Another: This problem in the Sun environment and HP Environment does not have this problem, I do not know if you ignore this problem at compile time or when the program is running to produce an exception, there are some people on the internet, so it is recommended to trouble do not ignore this problem, who knows it will cause trouble?

--Transfer from http://blog.csdn.net/lyn_bigdream/article/details/8746241