『壹』 字符编码的GB2312
GB2312 也是ANSI编码里的一种，对ANSI编码最初始的ASCII编码进行扩充，为了满足国内在计算机中使用汉字的需要，中国国家标准总局发布了一系列的汉字字符集国家标准编码，统称为GB码，或国标码。其中最有影响的是于1980年发布的《信息交换用汉字编码字符集 基本集》，标准号为GB 2312-1980,因其使用非常普遍，也常被通称为国标码。GB2312编码通行于我国内地；新加坡等地也采用此编码。几乎所有的中文系统和国际化的软件都支持GB 2312。GB 2312是一个简体中文字符集，由6763个常用汉字和682个全角的非汉字字符组成。其中汉字根据使用的频率分为两级。一级汉字3755个，二级汉字3008个。由于字符数量比较大，GB2312采用了二维矩阵编码法对所有字符进行编码。首先构造一个94行94列的方阵，对每一行称为一个“区”，每一列称为一个“位”，然后将所有字符依照下表的规律填写到方阵中。这样所有的字符在方阵中都有一个唯一的位置，这个位置可以用区号、位号合成表示，称为字符的区位码。如第一个汉字“啊”出现在第16区的第1位上，其区位码为1601。因为区位码同字符的位置是完全对应的，因此区位码同字符之间也是一一对应的。这样所有的字符都可通过其区位码转换为数字编码信息。GB2312字符的排列分布情况见表1－4。表1－4 GB2312 字符编码分布表 分区范围 符号类型 第01区 中文标点、数学符号以及一些特殊字符 第02区 各种各样的数学序号 第03区 全角西文字符 第04区 日文平假名 第05区 日文片假名 第06区 希腊字母表 第07区 俄文字母表 第08区 中文拼音字母表 第09区 制表符号 第10－15区 无字符 第16－55区 一级汉字（以拼音字母排序） 第56－87区 二级汉字（以部首笔画排序） 第88－94区 无字符 GB2312字符在计算机中存储是以其区位码为基础的，其中汉字的区码和位码分别占一个存储单元，每个汉字占两个存储单元。由于区码和位码的取值范围都是在1－94之间，这样的范围同西文的存储表示冲突。例如汉字‘珀’在GB2312中的区位码为7174，其两字节表示形式为71，74；而两个西文字符‘GJ’的存储码也是71,74。这种冲突将导致在解释编码时到底表示的是一个汉字还是两个西文字符将无法判断。为避免同西文的存储发生冲突，GB2312字符在进行存储时，通过将原来的每个字节第8bit设置为1同西文加以区别，如果第8bit为0，则表示西文字符，否则表示GB2312中的字符。实际存储时，采用了将区位码的每个字节分别加上A0H（160）的方法转换为存储码，计算机存储规则是此编码的补码，而且是位码在前，区码在后。例如汉字‘啊’的区位码为1601，其存储码为B0A1H，其转换过程为： 区位码 区码转换 位码转换 存储码 1001H 10H+A0H=B0H 01H+A0H=A1H B0A1H GB2312编码用两个字节(8位2进制)表示一个汉字，所以理论上最多可以表示256×256=65536个汉字。但这种编码方式也仅仅在中国行得通，如果您的网页使用的GB2312编码，那么很多外国人在浏览你的网页时就可能无法正常显示，因为其浏览器不支持GB2312编码。当然，中国人在浏览外国网页(比如日文)时，也会出现乱码或无法打开的情况，因为我们的浏览器没有安装日文的编码表。
『贰』 htm文件和JSP文件中utf-8与gb2312是什么
UTF-8（8 位元 Universal Character Set/Unicode Transformation Format）是针对Unicode 的一种可变长度字元编码。它可以用来表示 Unicode 标准中的任何字元，而且其编码中的第一个位元组仍与 ASCII 相容，使得原来处理 ASCII 字元的软体无需或只作少部份修改后，便可继续使用。因此，它逐渐成为电子邮件、网页及其他储存或传送文字的应用中，优先采用的编码。GB 2312或GB 2312-80是一个简体中文字符集的中国国家标准，全称为《信息交换用汉字编码字符集•基本集》，又称为GB0，由中国国家标准总局发布，1981年5月1日实施。GB2312编码通行于中国大陆；新加坡等地也采用此编码。中国大陆几乎所有的中文系统和国际化的软件都支持GB 2312。
『叁』 GB2312 的编码，繁体内容变成乱码，怎么解决
第一步：下载htmlunit的源代码，在com\gargoylesoftware\htmlunit\util目录下有个EncodingSniffer文件，其中就有获取页面编码的情况，大概在626行encoding = encoding.toUpperCase(Locale.ROOT);后边添加if(encoding.equals("GB2312"))encoding="GBK";第二步：大概在715行charset = charset.toUpperCase(Locale.ROOT);后边添加if(charset.equals("GB2312"))charset="GBK";原理：gb2312支持的字符集编码比较小，GBK兼容并且大，可以直接转GBK的，所以获取页面的时候，htmlunit本身会调用这个EncodingSniffer类，将其中遇到gb2312的情况，统一变成gbk。比较麻烦就是要下载htmlunit源码，做个编译后，把生成的EncodingSniffer.class文件覆盖到maven引用的包对应的class文件中。
『肆』 如何将TXT文件的GBK编码转为GB2312编码
gb2312编码大约包含6000多汉字（不包括特殊字符）,编码范围为第一位b0-f7,第二位编码范围为a1-fe(第一位为cf时,第二位为a1-d3),计算一下汉字个数为6762个汉字。当然还有其他的字符。包括控制键和其他字符大约7573个字符编码gbk编码是对gb2312编码的扩充，容纳的汉字更多，但仅仅是扩充，没有质的变化。保留了所有gb2312编码,在此基础上进行编码范围的扩充.容纳(包含特殊字符)共22014个字符编码.gb18030编码是在gbk编码基础上的扩充，因为汉字更多，仅仅使用两位编码已经不能容纳要求的汉字，所以采用了2\4位混和的办法，可以支持更多的汉字编码。并且保留了原有的gbk2字节编码兼容gb2312和gbk编码的文件。大概容纳55657个编码(包含特殊字符)unicode编码(也就是utf编码)：俗称万国码，致力于使用统一的编码准则表达各国的文字。为表达更多的文字，utf-8采用2/3混编的方式。目前容纳的汉字范围小于gbk编码。并且以3字节的方式处理中文，带来了兼容性的问题，原有的gbk,gb2312,gb18030编码文件都不能正常的处理,还有很长的路要走。
『伍』 vim 如何编辑 GB2312 编码的文件
修改.vimrc文件，让其支持 gb2312就行"设定文件编码类型，彻底解决中文编码问题 let &termencoding=&encoding set fileencodings=utf-8,gbk,ucs-bom,cp936 略微查了一下.vimrc中添加内容的含意， 内容如下： 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，在其他需要编码转换的环境里，都可以应用类似的思路来处理问题解决问题。
『陆』 怎么把html页面的编码方式从UTF-8变成GB2312
1、首先打开dreamweaver，新建文件login.html，此时默认的编码是gb2312，如图所示。
『柒』 怎么把文件设置成gb2312编码
1、新建一个gb2312编码页面，将页面代码复制过去；2、将页头部分的 meta http-equiv="Content-Type" content="text/html; charset=utf-8"把 utf-8 换成gb2312就可以了；
『捌』 如何将TXT文本编码变为GB2312
如果你用记事本，另存为选择ansi就是gb2312。另外，如果你不确认文件是什么编码，推版荐用Replace Pioneer:首先用Replace Pioneer检测出一个权文件是什么编码：1. 选择Tools->Encoding Detection 2. 在"File to Check"里输入文件名，点击Start 3. 你的文件就会被用70多种编码方式显示出来 哪一个显示正确就可能是这种编码。确定编码方式后(比如说utf8)，用以下方法把它批量转变成ansi(中文一般是gbk):第一步：选文件 1.打开Tools->Batch Runner菜单 2.点击Pick Files,用鼠标对需要处理的多个文件进行多选。 第二步：变换编码 1.点击Change Encode按钮 2.点击input encoding，设置成utf-83.点击output encoding,设置成CN->gbk 4.点击start，完成
『玖』 文字怎么转换成GB2312编码
转换方法如下：
以office2003为例：
开始菜单-Microsoftoffice- Microsoftoffice工具- Microsoft office2003语言设置，将Microsoft office应用程序默认方式的语言设为"中文（简体）"。
保存完毕后，用EXCEL打开这个文件就会正常显示。
未经允许不得转载：山九号 » 文件内容编码gb2312|如何将TXT文本编码变为GB2312
