latin1 latin1是什么编码

各位老铁们，大家好，今天由我来为大家分享latin1，以及latin1是什么编码的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！

怎么显示latin1 的文件 linux

录执行make install命令，之后用convmv命令测试是否安装成功，若显示一些命令提示则表示成功了。

安装。

下面看一下convmv的具体用法：

convmv-f源编码-t新编码 [选项]文件名

常用参数：

-r递归处理子文件夹

--notest真正进行操作，请注意在默认情况下是不对文件进行真实操作的，而只是试验。

--list显示所有支持的编码

--unescap可以做一下转义，比如把%20变成空格

比如我们有一个utf8编码的文件名，转换成GBK编码，命令如下：

convmv-f UTF-8-t GBK--notest utf8编码的文件名

这样转换以后"utf8编码的文件名"会被转换成GBK编码（只是文件名编码的转换，文件内容不会发生变化）

vim编码方式的设置

和所有的流行文本编辑器一样，Vim可以很好的编辑各种字符编码的文件，这当然包括UCS-2、UTF-8等流行的 Unicode编码方式。然而不幸的是，和很多来自 Linux世界的软件一样，这需要你自己动手设置。

Vim有四个跟字符编码方式有关的选项，encoding、fileencoding、fileencodings、termencoding(这些选项可能的取值请参考 Vim在线帮助:help encoding-names)，它们的意义如下:

* encoding: Vim内部使用的字符编码方式，包括 Vim的 buffer(缓冲区)、菜单文本、消息文本等。默认是根据你的locale选择.用户手册上建议只在.vimrc中改变它的值，事实上似乎也只有在.vimrc中改变它的值才有意义。你可以用另外一种编码来编辑和保存文件，如你的vim的encoding为utf-8,所编辑的文件采用cp936编码,vim会自动将读入的文件转成utf-8(vim的能读懂的方式），而当你写入文件时,又会自动转回成cp936（文件的保存编码).

* fileencoding: Vim中当前编辑的文件的字符编码方式，Vim保存文件时也会将文件保存为这种字符编码方式(不管是否新文件都如此)。

* fileencodings: Vim自动探测fileencoding的顺序列表，启动时会按照它所列出的字符编码方式逐一探测即将打开的文件的字符编码方式，并且将 fileencoding设置为最终探测到的字符编码方式。因此最好将Unicode编码方式放到这个列表的最前面，将拉丁语系编码方式 latin1放到最后面。

* termencoding: Vim所工作的终端(或者 Windows的 Console窗口)的字符编码方式。如果vim所在的term与vim编码相同，则无需设置。如其不然，你可以用vim的termencoding选项将自动转换成term的编码.这个选项在 Windows下对我们常用的 GUI模式的 gVim无效，而对 Console模式的Vim而言就是 Windows控制台的代码页，并且通常我们不需要改变它。

好了，解释完了这一堆容易让新手犯糊涂的参数，我们来看看 Vim的多字符编码方式支持是如何工作的。

1. Vim启动，根据.vimrc中设置的 encoding的值来设置 buffer、菜单文本、消息文的字符编码方式。

2.读取需要编辑的文件，根据 fileencodings中列出的字符编码方式逐一探测该文件编码方式。并设置 fileencoding为探测到的，看起来是正确的(注1)字符编码方式。

3.对比 fileencoding和 encoding的值，若不同则调用 iconv将文件内容转换为encoding所描述的字符编码方式，并且把转换后的内容放到为此文件开辟的 buffer里，此时我们就可以开始编辑这个文件了。注意，完成这一步动作需要调用外部的 iconv.dll(注2)，你需要保证这个文件存在于$VIMRUNTIME或者其他列在 PATH环境变量中的目录里。

4.编辑完成后保存文件时，再次对比 fileencoding和 encoding的值。若不同，再次调用 iconv将即将保存的 buffer中的文本转换为 fileencoding所描述的字符编码方式，并保存到指定的文件中。同样，这需要调用 iconv.dll由于 Unicode能够包含几乎所有的语言的字符，而且 Unicode的 UTF-8编码方式又是非常具有性价比的编码方式(空间消耗比 UCS-2小)，因此建议 encoding的值设置为utf-8。这么做的另一个理由是 encoding设置为 utf-8时，Vim自动探测文件的编码方式会更准确(或许这个理由才是主要的;)。我们在中文 Windows里编辑的文件，为了兼顾与其他软件的兼容性，文件编码还是设置为 GB2312/GBK比较合适，因此 fileencoding建议设置为 chinese(chinese是个别名，在 Unix里表示 gb2312，在 Windows里表示cp936，也就是 GBK的代码页)。

vim中编辑不同编码的文件时需要注意的一些地方

此文讲解的是vim编辑多字节编码文档（中文）所要了解的一些基础知识，注意其没有涉及gvim，纯指字符终端下的vim。

vim编码方面的基础知识：

1，存在3个变量：

encoding—-该选项使用于缓冲的文本(你正在编辑的文件)，寄存器，Vim脚本文件等等。你可以把‘encoding’选项当作是对 Vim内部运行机制的设定。

fileencoding—-该选项是vim写入文件时采用的编码类型。

termencoding—-该选项代表输出到客户终端（Term）采用的编码类型。

2，此3个变量的默认值：

encoding—-与系统当前locale相同，所以编辑文件的时候要考虑当前locale，否则要设置的东西就比较多了。

fileencoding—-vim打开文件时自动辨认其编码，fileencoding就为辨认的值。为空则保存文件时采用encoding的编码，如果没有修改encoding，那值就是系统当前locale了。

termencoding—-默认空值，也就是输出到终端不进行编码转换。

由此可见，编辑不同编码文件需要注意的地方不仅仅是这3个变量，还有系统当前locale和、文件本身编码以及自动编码识别、客户运行vim的终端所使用的编码类型3个关键点，这3个关键点影响着3个变量的设定。

如果有人问：为什么我用vim打开中文文档的时候出现乱码？

答案是不确定的，原因上面已经讲了，不搞清楚这3个关键点和这3个变量的设定值，出现乱码是正常的，倒是不出现乱码那反倒是凑巧的。

再来看一下常见情况下这三个关键点的值以及在这种情况下这3个变量的值：

1，locale—-目前大部分Linux系统已经将utf-8作为默认locale了，不过也有可能不是，例如有些系统使用中文locale zh_CN.GB18030。在locale为utf-8的情况下，启动vim后encoding将会设置为utf-8，这是兼容性最好的方式，因为内部处理使用utf-8的话，无论外部存储编码为何都可以进行无缺损转换。locale决定了vim内部处理数据的编码，也就是encoding。

2，文件的编码以及自动编码识别—-这方面牵扯到各种编码的规则，就不一一细讲了。但需要明白的是，文件编码类型并不是保存在文件内的，也就是说没有任何描述性的字段来记录文档是何种编码类型的。因此我们在编辑文档的时候，要么必须知道这文档保存时是以什么编码保存的，要么通过另外的一些手段来断定编码类型，这另外的手段，就是通过某些编码的码表特征来断定，例如每个字符占用的字节数，每个字符的ascii值是否都大于某个字段来断定这个文件属于何种编码。这种方式vim也使用了，这就是vim的自动编码识别机制了。但这种机制由于编码各式各样，不可能每种编码都有显著的特征来辨别，所以是不可能 100%准确的。对于我们GB2312编码，由于其中文是使用了2个acsii值高于127的字符组成汉字字符的，因此不可能把gb2312编码的文件与 latin1编码区分开来，因此自动识别编码的机制对于gb2312是不成功的，它只会将文件辨识为latin1编码。此问题同样出现在gbk，big5上等。因此我们在编辑此类文档时，需要手工设定encoding和fileencoding。如果文档编码为utf-8时，一般vim都能自动识别正确的编码。

3，客户运行vim的终端所使用的编码类型—-同第二条一样，这也是一个比较难以断定的关键点。第二个关键点决定着从文件读取内容和写入内容到文件时使用的编码，而此关键点则决定vim输出内容到终端时使用的编码，如果此编码类型和终端认为它收到的数据的编码类型不同，则又会产生乱码问题。在 linux本地X环境下，一般终端都认为其接收的数据的编码类型和系统locale类型相符，因此不需关心此方面是否存在问题。但如果牵涉到远程终端，例如ssh登录服务器，则问题就有可能出现了。例如从1台locale为GB2310的系统（称作客户机）ssh到locale为utf-8的系统（称作服务器）并开启vim编辑文档，在不加任何改动的情况下，服务器返回的数据为utf-8的，但客户机认为服务器返回的数据是gb2312的，按照 gb2312来解释数据，则肯定就是乱码了，这时就需要设置termencoding为gb2312来解决这个问题。此问题更多出现在我们的 windows desktop机远程ssh登录服务器的情况下，这里牵扯到不同系统的编码转换问题。所以又与windows本身以及ssh客户端有很大相关性。在 windows下存在两种编码类型的软件，一种是本身就为unicode编码方式编写的软件，一种是ansi软件，也就是程序处理数据直接采用字节流，不关心编码。前一种程序可以在任何语言的windows上正确显示多国语言，而后一种则编写在何种语言的系统上则只能在何种语言的系统上显示正确的文字。对于这两种类型的程序，我们需要区别对待。以ssh客户端为例，我们使用的putty是unicode软件，而secure CRT则是ansi软件。对于前者，我们要正确处理中文，只要保证vim输出到终端的编码为utf-8即可，就是termencoding=utf-8。但对于后者，一方面我们要确认我们的windows系统默认代码页为cp936（中文windows默认值），另一方面要确认vim设置的termencoding= cp936。

最后来看看处理中文文档最典型的几种情况和设置方式：

1，系统locale是utf-8（很多linux系统默认的locale形式），编辑的文档是GB2312或GBK形式的（Windows记事本默认保存形式，大部分编辑器也默认保存为这个形式，所以最常见），终端类型utf-8（也就是假定客户端是putty类的unicode软件）

则vim打开文档后，encoding=utf-8（locale决定的），fileencoding=latin1（自动编码判断机制不准导致的），termencoding=空（默认无需转换term编码），显示文件为乱码。

解决方案1：首先要修正fileencoding为cp936或者euc-cn（二者一样的，只不过叫法不同），注意修正的方法不是:set fileencoding=cp936，这只是将文件保存为cp936，正确的方法是重新以cp936的编码方式加载文件为:edit++enc=cp936，可以简写为:e++enc=cp936。

解决方案2：临时改变vim运行的locale环境，方法是以LANG=zh_CN vim abc.txt的方式来启动vim，则此时encoding=euc-cn（locale决定的），fileencoding=空（此locale下文件编码自动判别功能不启用，所以fileencoding为文件本身编码方式不变，也就是euc-cn），termencoding=空（默认值，为空则等于encoding）此时还是乱码的，因为我们的ssh终端认为接受的数据为utf-8，但vim发送数据为euc-cn，所以还是不对。此时再用命令: set termencoding=utf-8将终端数据输出为utf-8，则显示正常。

2，情况与1基本相同，只是使用的ssh软件为secure CRT类ansi类软件。

vim打开文档后，encoding=utf-8（locale决定的），fileencoding=latin1（自动编码判断机制不准导致的），termencoding=空（默认无需转换term编码），显示文件为乱码。

解决方案1：首先要保证运行secure CRT的windows机器的默认代码页为CP936，这一点中文windows已经是默认设置了。其他的与上面方案1相同，只是要增加一步，:set termencoding=cp936

解决方案2：与上面方案2类似，不过最后一步修改termencoding省略即可，在此情况下需要的修改最少，只要以locale为zh_CN开启vim，则encoding=euc-cn，fileencoding和termencoding都为空即为encoding的值，是最理想的一种情况。

可见理解这3个关键点和3个参数的意义，对于编码问题有很大助力，以后就可以随心所欲的处理文档了，同时不仅仅是应用于vim，在其他需要编码转换的环境里，都可以应用类似的思路来处理问题解决问题。

最后推荐一款功能强大的windows下的ssh客户端—-xshell，它具有类似secure CRT一样的多tab的ssh窗口的能力，但最为方便的是这款工具还有改变Term编码的功能，这样我们就可以不用频繁调整termencoding，只需在ssh软件里切换编码即可，这是我用过的最为方便的ssh工具。它是商业软件，但非注册用户使用没有任何限制，只是30天试用期超出后会每次启动都提示注册，对于功能没有丝毫影响。

1、ibus输入法

Ubuntu系统安装后已经自带了ibus输入法，在英语环境下默认不启动。

配置ibus自动启动可以在ubuntu系统菜单上选择System--- Preferences--- Startup Applications，在该窗口中增加一个程序：

Name: ibus-daemon

Command: ibus-daemon-d-x-r

ibus默认提供的中文输入法比较弱智，需要额外安装ibus-pinyin，命令如下：

sudo apt-get install ibus-pinyin

这时，还需要将ibus-pinyin输入法启动。在ubuntu系统菜单上选择System--- Preferences--- IBus Preferences，在Input Method页中的“Select an input method”下拉框中选择增加Chinese– Pinyin，就是图标中有个一个大大的“拼”字的那一个，然后点击Add按钮，最后通过Up按钮将该输入法移动到最上面。

系统重启后，通过Ctrl+空格即可调出ibus输入法。

ibus输入法总体来说不错，但是在我的环境下发现无法在部分Java程序中调出来，例如Netbeans、OpenProj。

2、fcitx输入法

由于ibus的缺陷，所以我尝试了fcitx，使用下来也非常不错，而且可以在Java程序中正常使用，只是在这种情况下光标跟随有些问题，输入界面会停留在屏幕最下端，但是可以接受，比起ibus不能使用要好多了。

安装fcitx：

sudo apt-get install fcitx

启动fcitx：

im-switch-s fcitx

注销后重新登录，fcitx就会生效。

如果需要切换回ibus，可以运行im-switch-s ibus，然后注销，重新登录。

fcitx同样可以通过Ctrl+空格调出，这时会发现fcitx显示的中文是方框，因此需要修改fcitx的配置。Fcitx的配置文件在~/.fcitx/config，该文件为 GBK编码，在Ubuntu下显示不正常，可以通过如下方式操作：

cd~/.fcitx

iconv-f gbk-t utf8 config> config.tmp

mysql字符集是latin1,如何将中文存进去

中文不管用什么字符集来表示（GBK\GB2312\UTF8等），最终都是字节的整数倍，而latin1或者说ISO-8859-1就是满8byte（整字节）的编码方式。无论你传多少个字节进去，mysql都可以认为它是一个或者多个latin字符而已。是不是乱码取决于读出来之后的解码方式，或者说客户端的处理方式。客户端如果知道读出来的是中文，那么就会按照中文的方式来尝试解码，自然就得不到乱码，如果按照其它编码方式来解码，自然就可能是乱码。

什么是latin1字符集

Latin1是ISO-8859-1的别名，有些环境下写作Latin-1。

ISO-8859-1编码是单字节编码，向下兼容ASCII，其编码范围是0x00-0xFF，0x00-0x7F之间完全和ASCII一致，0x80-0x9F之间是控制字符，0xA0-0xFF之间是文字符号。

ISO-8859-1收录的字符除ASCII收录的字符外，还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。欧元符号出现的比较晚，没有被收录在ISO-8859-1当中。

因为ISO-8859-1编码范围使用了单字节内的所有空间，在支持ISO-8859-1的系统中传输和存储其他任何编码的字节流都不会被抛弃。换言之，把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题。这是个很重要的特性，MySQL数据库默认编码是Latin1就是利用了这个特性。ASCII编码是一个7位的容器，ISO-8859-1编码是一个8位的容器。

latin1是什么编码

Latin1是ISO-8859-1的别名，有些环境下写作Latin-1。

ISO-8859-1

ISO-8859-1编码是单字节编码，向下兼容ASCII，其编码范围是0x00-0xFF，0x00-0x7F之间完全和ASCII一致，0x80-0x9F之间是控制字符，0xA0-0xFF之间是文字符号。

ISO-8859-1收录的字符除ASCII收录的字符外，还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。欧元符号出现的比较晚，没有被收录在ISO-8859-1当中。

因为ISO-8859-1编码范围使用了单字节内的所有空间，在支持ISO-8859-1的系统中传输和存储其他任何编码的字节流都不会被抛弃。换言之，把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题。这是个很重要的特性，MySQL数据库默认编码是Latin1就是利用了这个特性。ASCII编码是一个7位的容器，ISO-8859-1编码是一个8位的容器。

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！