手机下载TXT文件万物编程TXT方式为UTF-8，怎样传输到另一只能识别GBK编码的设备?

来源：蜘蛛抓取(WebSpider) 时间：2018-08-05 14:46 标签： TXT编程

阅读本文之前，需要了解GBK与UTF-8的编码知识，相关内容可以参考。

字符集错误转换导致的问题

UTF-8格式编码的字节流，按GBK字符集转换为字符串，会出现乱码，这很正常。但将其重新转为字节流，再用UTF-8字符集转为字符串，还是乱码。这就让我产生了疑惑，虽然使用错误的字符集必然导致乱码，但字节的信息并没有改变，因此再转为字节流，用正确的字符集解码，应该得到正常的字符串。但事实是，被错误字符集转换过的字符串，无法恢复到原来的字符集。

造成该问题的根源是字节发生了变化。GBK或UTF-8遇到无法解析的字符时，会使用特殊的字符代替，因此造成原有字节信息的丢失，无法恢复。

对于一串UTF-8编码的字节流，使用GBK进行解码。连续两个大于127的字节被认为是一个GBK编码的字符；若只读到一个大于127的字节，便发生错误，无法解析。此时，用字符'？'代替错误字节，ASCII码是63。
以“樊”字为例，UTF-8编码使用三个字节表示该字符，字节码为[001010]（[e6, a8, 8a]）。使用GBK解码时，读到第一个字节大于127，则取两个字节解析为一个GBK字符。前两个字节e6 8a被解析为GBK字符——妯。 第三个字节无法解析，所以赋值为？，最后的结果是 妯?。
可以看出，最后一个字节的信息丢失了，由8a变成3F，即使把结果再转换为字节流，也无法用utf-8字符集正确解析了。

对于一串GBK编码的字节流，使用UTF-8解码。UTF-8对于字节的格式有严格要求，当解析某个字符失败时，使用'?'（UTF-8编码为EF BF BD）代替。
继续以“樊”字为例，其GBK字节码为[101110]（[B7, AE]）。使用UTF-8解码时，根据规则，要求10开头的字节之前，必须有字节标识一个字符的长度，所以两个字节都无法解析。最后的字符串是??。
可以看出，所有的字节信息都丢失了，因此无法再使用GBK解析该字符串。
注意，UTF-8用?替换，是以字符为单位的。例如[000001]使用UTF-8解码，得到的结果是?A，而不是??A。根据第一个字节的格式，UTF-8期望将三个字节转换为一个字符。但最后一个字节不符合要求，所以前两个字节被一个?代替。而不是每个字节都被?代替。

原发布在个人博客，欢迎访问！！

在Vim中，有四个与编码有关的选项，它们是：fileencodings、fileencoding、encoding和termencoding。在实际使用中，任何一个选项出现错误，都会导致出现乱码。因此，每一个Vim用户都应该明确这四个选项的含义。下面，我们详细介绍一下这四个选项的含义和作用。

encoding是Vim内部使用的字符编码方式。当我们设置了encoding之后，Vim内部所有的buffer、寄存器、脚本中的字符串等，全都使用这个编码。Vim 在工作的时候，如果编码方式与它的内部编码不一致，它会先把编码转换成内部编码。如果工作用的编码中含有无法转换为内部编码的字符，在这些字符就会丢失。因此，在选择 Vim 的内部编码的时候，一定要使用一种表现能力足够强的编码，以免影响正常工作。

由于encoding选项涉及到Vim中所有字符的内部表示，因此只能在Vim启动的时候设置一次。在Vim工作过程中修改encoding会造成非常多的问题。用户手册上建议只在 .vimrc中改变它的值，事实上似乎也只有在 .vimrc中改变它的值才有意义。如果没有特别的理由，请始终将encoding设置为utf-8。为了避免在非UTF-8的系统如Windows下，菜单和系统提示出现乱码，可同时做这几项设置：

termencoding是Vim用于屏幕显示的编码，在显示的时候，Vim会把内部编码转换为屏幕编码，再用于输出。内部编码中含有无法转换为屏幕编码的字符时，该字符会变成问号，但不会影响对它的编辑操作。如果termencoding没有设置，则直接使用encoding不进行转换。

举个例子，当你在Windows下通过telnet登录Linux工作站时，由于Windows的telnet是GBK编码的，而Linux下使用UTF-8编码，你在telnet下的Vim中就会乱码。此时有两种消除乱码的方式：一是把Vim的encoding改为gbk，另一种方法是保持encoding为utf-8，把termencoding改为gbk，让Vim在显示的时候转码。显然，使用前一种方法时，如果遇到编辑的文件中含有GBK无法表示的字符时，这些字符就会丢失。但如果使用后一种方法，虽然由于终端所限，这些字符无法显示，但在编辑过程中这些字符是不会丢失的。

当Vim从磁盘上读取文件的时候，会对文件的编码进行探测。如果文件的编码方式和Vim的内部编码方式不同，Vim就会对编码进行转换。转换完毕后，Vim会将fileencoding选项设置为文件的编码。当Vim存盘的时候，如果encoding和fileencoding不一样，Vim就会进行编码转换。因此，通过打开文件后设置fileencoding，我们可以将文件由一种编码转换为另一种编码。但是，由前面的介绍可以看出，fileencoding是在打开文件的时候，由Vim进行探测后自动设置的。因此，如果出现乱码，我们无法通过在打开文件后重新设置fileencoding来纠正乱码。

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

编码的自动识别是通过设置fileencodings实现的，注意是复数形式。fileencodings是一个用逗号分隔的列表，列表中的每一项是一种编码的名称。当我们打开文件的时候，VIM按顺序使用fileencodings中的编码进行尝试解码，如果成功的话，就使用该编码方式进行解码，并将fileencoding设置为这个值，如果失败的话，就继续试验下一个编码。

因此，我们在设置fileencodings的时候，一定要把要求严格的、当文件不是这个编码的时候更容易出现解码失败的编码方式放在前面，把宽松的编码方式放在后面。例如，latin1是一种非常宽松的编码方式，任何一种编码方式得到的文本，用latin1进行解码，都不会发生解码失败——当然，解码得到的结果自然也就是理所当然的“乱码”。因此，如果你把latin1放到了fileencodings的第一位的话，打开任何中文文件都是乱码也就是理所当然的了。

把VIM打造成一个简单实用的IDE

在 6.2上搭建Vim开发环境

Vim技巧分享:C语言设置

Vim编辑器使用基础教程

其中，ucs-bom是一种非常严格的编码，非该编码的文件几乎没有可能被误判为ucs-bom，因此放在第一位。

utf-8也相当严格，除了很短的文件外(例如许多人津津乐道的GBK编码的“联通”被误判为UTF-8编码的经典错误)，现实生活中一般文件是几乎不可能被误判的，因此放在第二位。

接下来是cp936和gb18030，这两种编码相对宽松，如果放前面的话，会出现大量误判，所以就让它们靠后一些。cp936的编码空间比gb18030小，所以把cp936放在gb18030前面。

至于big5、euc-jp和euc-kr，它们的严格程度和cp936差不多，把它们放在后面，在编辑这些编码的文件的时候必然出现大量误判，但这是Vim内置编码探测机制没有办法解决的事。由于中国用户很少有机会编辑这些编码的文件，因此我们还是决定把cp936和gb18030放在前面以保证这些编码的识别。

最后就是latin1了。它是一种极其宽松的编码，以至于我们不得不把它放在最后一位。不过可惜的是，当你碰到一个真的latin1编码的文件时，绝大部分情况下，它没有机会fall-back到latin1，往往在前面的编码中就被误判了。不过，正如前面所说的，中国用户没有太多机会接触这样的文件。

如果编码被误判了，解码后的结果就无法被人类识别，于是我们就说，这个文件乱码了。此时，如果你知道这个文件的正确编码的话，可以在打开文件的时候使用 ++enc=encoding 的方式来打开文件，如：

更多详情见请继续阅读下一页的精彩内容：

那么，如何将GBK编码成 UTF8 ？？

于是我设计了一个负责字符转换的类,修正了其中的一些不足，增加了部分功能,以后我会不断扩充该类，来支持更多的字符集


big5,Unicode,GBK之间的相互转换,前提是只转换共同的字符集部分,

使用前,请将var $FilePath=""变量该为该程序文件的绝对路径,否则将会找不到数据文件


将gbk编码的字符串转化为UTF-8编码:

在浏览器中使用UTF-8编码察看,将会看到正确的字符

我要回帖

更多关于 TXT编程 的文章

 

随机推荐