Vim Chinese garbled in Centos 7

Reference: http://www.myexception.cn/operating-system/1534005.html

One. Sudo vim/etc/vimrc

Add the following lines to the file:

Set fileencodings= Ucs-bom, utf-8,gbk,gb2312,cp936,gb18030,big5,latin-1

Set Encoding=utf-8

Set Termencoding=utf-8

Set Fileencoding=utf-8

In Vim, there are four encoding-related options, which are: Fileencodings, fileencoding, encoding, and termencoding. In actual use, any one of the options error, will cause garbled. Therefore, each Vim user should be clear about the meaning of these four options. Let's take a look at the meanings and effects of these four options in detail.

1, encoding

Encoding is the character encoding used within Vim. After we set up the encoding, all of the buffer, registers, strings in the script, etc. in Vim all use this encoding. When Vim is working, if the encoding is inconsistent with its internal code, it will first convert the encoding to internal encoding. If the code in the work contains characters that cannot be converted to internal encoding, the characters will be lost. Therefore, when choosing the internal code of Vim, be sure to use a code that is strong enough to avoid affecting normal work.

Since the encoding option involves the internal representation of all the characters in Vim, it can only be set once when Vim is started. modifying encoding during VIM work can cause a lot of problems. If there is no specific reason, always set encoding to Utf-8. To avoid garbled menus and system prompts in non-UTF-8 systems such as Windows, you can do these settings at the same time:

Set Encoding=utf-8

Set LANGMENU=ZH_CN. UTF-8

Language message ZH_CN. UTF-8

2, termencoding

Termencoding is the encoding that Vim uses for screen display, and when displayed, VIM converts the internal code to screen encoding and then to the output. When an internal encoding contains a character that cannot be converted to a screen encoding, the character becomes a question mark, but does not affect the editing operation on it. If termencoding is not set, direct use of encoding does not convert.

For example, when you log in to a Linux workstation via telnet under Windows, because Windows Telnet is GBK encoded, and Linux uses UTF-8 encoding, you will be garbled in Vim under Telnet. At this time there are two ways to eliminate garbled: first, the encoding of Vim to GBK, the other way is to keep encoding for Utf-8, termencoding to GBK, so that vim in the display of transcoding. Obviously, when you use the previous method, these characters are lost if you encounter characters that are not represented by GBK in the edited file. However, if you use the latter method, these characters cannot be displayed due to terminal restrictions, but these characters are not lost during editing.

For GVim under the graphical interface, its display is not dependent on term, so termencoding has no meaning for it. In the GVim under GTK2, termencoding is always utf-8 and cannot be modified. GVim under Windows ignores the existence of termencoding.

3, fileencoding

When Vim reads a file from a disk, it detects the encoding of the file. If the file is encoded in a different way from the internal encoding of vim, VIM converts the encoding. When the conversion is complete, Vim sets the fileencoding option to the encoding of the file. When Vim is saved, if encoding and fileencoding are different, Vim will encode and convert. Therefore, by setting fileencoding after opening the file, we can convert the file from one encoding to another. However, as can be seen from the previous introduction, fileencoding is automatically set when the file is opened and detected by Vim. Therefore, if garbled, we cannot correct garbled characters by re-setting fileencoding after opening the file.

4, Fileencodings

The automatic identification of the encoding is implemented by setting fileencodings, and attention is to the plural form. Fileencodings is a comma-delimited list in which each item in the list is an encoded name. When we open the file, VIM attempts to decode it in sequence using the encoding in fileencodings, and if it succeeds, decodes it using that encoding, sets the fileencoding to this value, and, if it fails, continues to experiment with the next encoding.

Therefore, when we set up the fileencodings, we must put the strict requirements, when the file is not the code is more prone to decoding the failure of the encoding method put in front, the loose encoding method is put in the back.

For example, Latin1 is a very loose encoding, any encoding of the resulting text, with latin1 decoding, will not occur decoding failure--of course, the result of decoding is naturally the "garbled". Therefore, if you put latin1 in the first place of the fileencodings, open any Chinese file is garbled is also taken for granted.

The following is a recommended fileencodings setting:

Set Fileencodings=ucs-bom,utf-8,cp936,gb18030,big5,euc-jp,euc-kr,latin1

Among them, Ucs-bom is a very strict encoding, non-encoded files are almost impossible to be misjudged as Ucs-bom, so put in the first place.

Utf-8 is also quite strict, except for very short documents (for example, many people relish the GBK encoded "Unicom" is misjudged as UTF-8 Coding Classic error), in real life the general document is almost impossible to be misjudged, so put in the second place.

Next is cp936 and GB18030, these two kinds of coding is relatively loose, if put in front, there will be a lot of miscarriage, so let them lean back some. CP936 's coding space is smaller than GB18030, so put cp936 in front of the GB18030.

As for Big5, EUC-JP and EUC-KR, they are as strict as cp936, putting them behind, there must be a lot of miscalculation when editing these encoded files, but this is the Vim built-in code detection mechanism can not solve. Since Chinese users rarely have the opportunity to edit these encoded files, we have decided to use the cp936 and GB18030 prerequisites to ensure that these codes are identified.

The last is latin1. It's a very loose code, so we have to put it on the last one. Unfortunately, when you encounter a real latin1 encoded file, most of the time, it does not have the opportunity to fall-back to latin1, often in the previous code is misjudged. However, as previously mentioned, Chinese users do not have much access to such documents.

If the code is misjudged, the decoded result cannot be recognized by humans, so we say that this file is garbled. At this point, if you know the correct encoding of the file, you can open the file by using the ++enc=encoding method of opening the file, such as:

: E ++enc=utf-8 myfile.txt

Vim Chinese garbled in Centos 7