每天进步一点点，自我实现
编码就是那点事
编码一直是让新手头疼的问题，特别是 GBK、GB2312、UTF-8 这三个比较常见的网页编码的区别，更是让许多新手晕头转向，怎么解释也解释不清楚。但是编码又是那么重要，特别在网页这一块。如果你打出来的不是乱码，而网页中出现了乱码，绝大部分原因就出在了编码上了。此外除了乱码之外，还会出现一些其他问题（例如：IE6 的 CSS 加载问题）等等。写出本文的目的，就是要彻底解释清楚这个编码问题！如果你遇到了类似的问题，就要认真看下面的内容了。
字节（octet），顾其英文名而思义，就是一个八位的存储单元，取值范围一定是0～255； 字符（character）就是一个语言上的符号，"中"字就是一个字符。字符所占的大小由其编码方式解决，比如"中"在UTF-8中占3个字节（0xE4A8AD），而在GBK中，则占两个字节(0xD6D0)。 字符集是字符的集合，像Unicode字符集，目标就是收纳了这个世界上所有语言的文字、符号等； 注意，字符集只是规定了有哪些字符，而最终决定采用哪些字符，每一个字符用多个字节表示等问题，则是由编码来决定的。像Unicode字符集的编码方式有很多，诸如UTF-8、UFT-16、UTF-32等。字符集和字符编码是分开的概念，但有时候称呼上会有些模糊，我们经常笼统地称这些Unicode字符集的编码为Unicode编码。内码是操作系统内部的字符编码。像早期的DOS采用的是ASCII，而现在的操作系统大把采用Unicode编码。
在讲各种编码之前，有必要先讲一个编码这个令人头疼的家伙的历史，这样有助于大家理解今天的编码世界为什么会是这样一个局面。
计算机对多语言的支持，大致为分以下三个阶段。
阶段一：ASCII时代。计算机是DOS时代的计算内码是ASCII码，ASCII的表示范围就是0到127那几个符号，这意味着，DOS时代的计算机只能显示英文，而无法支持其他语言。没办法，由于英文系国家开创了并继续主导了计算机的世界，他们自然而然地认为全世界的文字用8位表示足矣。
阶段二：ANSI时代。由于上述原因，像我们这些非英文系的国家的为了显示自家的文字，不得不一开始就得面对字符编码的问题，不同国家不同地区都创建了自己的编码标准。像是中国大陆是GB2312及后来的GBK，台湾是BIG5，日本是JIS。ASCII字符集，以及这些由此派生并兼容的字符集称为ANSI字符集。
阶段三：Unicode时代。为了和谐而出现，相较于以上两个阶段，这个时代称为国际化时代，适应了跨平台，跨语言之间交换信息的需求。
ASCII收录了空格及94个“可印刷字符”，足以给英语使用。但是，其他使用拉丁字母的语言(主要是欧洲国家的语言)，都有一定数量的变音字母，故可以使用ASCII及控制字符以外的区域来储存及表示。除了使用拉丁字母的语言外，使用西里尔字母的东欧语言、希腊语、泰语、现代阿拉伯语、希伯来语等，都可以使用这个形式来储存及表示如ISO 8859-1(Latin-1，西欧语言)。很明显，iso8859-1编码表示的字符范围很窄，无法表示中文字符。但是，由于是单字节编码，和计算机最基础的表示单位一致，所以很多时候，仍旧使用iso8859-1编码来表示。而且在很多协议上，默认使用该编码。
很久很久以前，有一群人，他们决定用8个可以开合的晶体管来组合成不同的状态，以表示世界上的万物，他们把这称为”字节”。再后来，他们又做了一些可以处理这些字节的机器，机器开动了，可以用字节来组合出很多状态，状态开始变来变去，他们就把这机器称为”计算机”。
开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。他们把其中的编号从0开始的32种状态分别规定了特殊的用途，一但终端、打印机遇上约定好的这些字节被传过来时，就要做一些约定的动作。遇上 00×10, 终端就换行，遇上0×07, 终端就向人们嘟嘟叫，例好遇上0x1b, 打印机就打印反白的字，或者终端就用彩色显示字母。他们看到这样很好，于是就把这些0×20以下的字节状态称为”控制码”。
他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字 了。大家看到这样，都感觉很好，于是大家都把这个方案叫做 ANSI 的”Ascii”编码（American Standard Code for Information Interchange，美国信息互换标准代码）。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。
后来计算机发展越来越广泛，世界各国为了可以在计算机保存他们的文字，他们决定采用127号之后的空位来表示这些新的字母、符号，还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了 最后一个状态255。从128到255这一页的字符集被称”扩展字符集”。但是原有的编号方法，已经再也放不下更多的编码。
等中国人们得到计算机时，已经没有可以利用的字节状态来表示汉字，况且有6000多个常用汉字需要保存呢。于是国人就自主研发，把那些127号之后的奇异符号们直接取消掉。规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到 0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的”全角”字符，而原来在127号以下的那些就叫”半角”字符了。
中国人民看到这样很不错，于是就把这种汉字方案叫做 “GB2312″。GB2312 是对 ASCII 的中文扩展。
但是中国的汉字太多了，后来还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是 扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。
因为当时各个国家都像中国这样搞出一套自己的编码标准，结果互相之间谁也不懂谁的编码，谁也不支持别人的编码。当时的中国人想让电脑显示汉字，就必须装上一个”汉字系统”，专门用来处理汉字的显示、输入的问题，装错了字符系统，显示就会乱了套。这怎么办？就在这时，一个叫 ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号的编码！他们打算叫它”Universal Multiple-Octet Coded Character Set”，简称 UCS, 俗称 “UNICODE”。
UNICODE 开始制订时，计算机的存储器容量极大地发展了，空间再也不成为问题了。于是 ISO 就直接规定必须用两个字节，也就是16位来统一表示所有的字符，对于 ascii 里的那些”半角”字符，UNICODE 包持其原编码不变，只是将其长度由原来的8位扩展为16位，而其他文化和语言的字符则全部重新统一编码。由于”半角”英文符号只需要用到低8位，所以其高 8位永远是0，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
但是，UNICODE 在制订时没有考虑与任何一种现有的编码方案保持兼容，这使得 GBK 与UNICODE 在汉字的内码编排上完全是不一样的，没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换，这种转换必须通过查表来进行。UNICODE 是用两个字节来表示为一个字符，他总共可以组合出65535不同的字符，这大概已经可以覆盖世界上所有文化的符号。
UNICODE 来到时，一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，顾名思义，UTF8 就是每次8个位传输数据，而 UTF16 就是每次16个位，只不过为了传输时的可靠性，从UNICODE到 UTF时并不是直接的对应，而是要过一些算法和规则来转换。
看完这些，相信你对于这几个编码关系等，了解的比较清楚了吧。我再来简单的总结一下：
中国人民通过对 ASCII 编码的中文扩充改造，产生了 GB2312 编码，可以表示6000多个常用汉字。汉字实在是太多了，包括繁体和各种字符，于是产生了 GBK 编码，它包括了 GB2312 中的编码，同时扩充了很多。中国是个多民族国家，各个民族几乎都有自己独立的语言系统，为了表示那些字符，继续把 GBK 编码扩充为 GB18030 编码。每个国家都像中国一样，把自己的语言编码，于是出现了各种各样的编码，如果你不安装相应的编码，就无法解释相应编码想表达的内容。终于，有个叫 ISO 的组织看不下去了。他们一起创造了一种编码 UNICODE ，这种编码非常大，大到可以容纳世界上任何一个文字和标志。所以只要电脑上有 UNICODE 这种编码系统，无论是全球哪种文字，只需要保存文件的时候，保存成 UNICODE 编码就可以被其他电脑正常解释。
UNICODE 在网络传输中，出现了两个标准 UTF-8 和 UTF-16，分别每次传输 8个位和 16个位。于是就会有人产生疑问，UTF-8 既然能保存那么多文字、符号，为什么国内还有这么多使用 GBK 等编码的人？因为 UTF-8 等编码体积比较大，占电脑空间比较多，如果面向的使用人群绝大部分都是中国人，用 GBK 等编码也可以。但是目前的电脑来看，硬盘都是白菜价，电脑性能也已经足够无视这点性能的消耗了。所以推荐所有的网页使用统一编码：UTF-8。
Unicode 字符集收录了这世界上所有的文字符号和特殊符号。对于每一个符号都定义了一个值，称为代码点（code point）。代码点可以用2个字节表示(UCS-2)，也可以用4个字节（UCS-4编码）。
UCS编码虽然定义了每个代码点的编码方式，但是没规定如何传输和存储。比如，在UCS-2码中，英文符号是在ACSII码的前面加上一个0 byte，像"A"的ASCII码 0x41，在UCS码中就是0x0041，这样，对于英文系统来讲会出现大量的0 byte，造成不必要的浪费。而且容易存在对现在ASCII码不兼容的问题。所以这个重担就落在了UTF编码身上，全称是Unicode Transformation Format。
我们知道"中"字的UFT-16编码是0x4E，0x2D，但是传输存储的过程中，字节的顺序有可能是(0x4E，0x2D)，也可能是(0x2D，0x4E)，这就是涉及一个字节序的问题。对于前一种，我们称为Big Endian（大尾，也就是高位在前），而后一总称为Little Endian（小尾，低位在前）。
那我们如何知道在不清楚哪一"尾"的情况下进行解析？ 先人已有解决的办法，就是在最前面加多2个字节，OxFEFF表示BE，而0xFFFE表示LE。（注：OxFEFF是实际上不存在的字符，所以正常情况下是不会使用到的，所以，不用担心出现与正常的字符数据冲突的问题），这就是所谓的BOM(Byte Order Mark )。理论上UTF-8可以达到6个字节编码（上表省略后3位字节以上的编码方式），但实际上，我们一般只采用0x 到0xFFFF的范围内的字符，也就说UTF-8实际上只采用了3个字节编码。
UTF-8除了省空间和兼容ASCII的优点后，其编码方式（类似于哈夫曼编码，很容易判断出1个字节及其后面的字节数）决定了它以下两个优点：
1、与字节顺序无关, 可以在不同平台之间交流。
2、容错能力高, 任何一个字节损坏后, 最多只会导致一个编码码位损失, 不会链锁错误(如GB码错一个字节就会整行乱码)
Base64可以用来将binary的字节序列数据编码成ASCII字符序列构成的文本。主要应用在电子邮件技术、LDIF档案等。Base64怎么编码？简单来讲，Base64不管你使用的是什么编码，UTF－8也好，ASCII也好，它的眼里只有二进制序列，比如说"中国"GBK编码的二进制序列是[],[],[],[]。Base64是一种基于64个可打印字符来表示二进制数据的表示方法。由于2的6次方等于64，所以每6个位元为一个单元，对应某个可打印字符。三个字节有24个位元，对应于4个Base64单元，即3个字节需要用4个可打印字符来表示。它可用来作为电子邮件的传输编码。在Base64中的可打印字符包括字母A-Z、a-z、数字0-9 ，这样共有62个字符，此外两个可打印符号在不同的系统中而不同。
GBK的文字编码是双字节表示的，即不论中、英文字符均使用双字节，只不过为区分中文，将其最高位定成1。至于UTF－8编码则是用以解决国际上字符的一种多字节编码，它对英文使用8位（即一个字节），中文使用24位（三个字节）来编码。对于英文字符较多的论坛则用UTF－8节省空间。
没有更多推荐了，better than better
djiango 中unicode 和str 方法转换的问题
写django 时候发现，作者为了保证最好的可用性，统一使用了unicode 编码。
使用django 中的模块，它会自动转为合适的类型。
而自己的代码如果直接去调用底层的接口，则可能出现错误。
例如在调用sockets.py这个底层的文件中的create_connection(）方法时，传递二个参数，host，port.这两个参数在django中赋值是默认为unicode。而sockets则要求为int 或者 str
from django.utils.encoding import smart_unicode
from django.utils.encoding import smart_str
host=smart_unicode('192.168.10.1')
print type(host)
host=smart_str('192.168.10.1')
print type(host)
完美解决咯。
没有更多推荐了，java中文乱码解决之道（3）：编码详情：伟大的创想—Unicode编码 - ImportNew
| 标签： ,
随着计算机的发展、普及，世界各国为了适应本国的语言和字符都会自己设计一套自己的编码风格，正是由于这种乱，导致存在很多种编码方式，以至于同一个二进制数字可能会被解释成不同的符号。为了解决这种不兼容的问题，伟大的创想Unicode编码应时而生！！
Unicode又称为统一码、万国码、单一码，它是为了解决传统的字符编码方案的局限而产生的，它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。可以想象Unicode作为一个“字符大容器”，它将世界上所有的符号都包含其中，并且每一个符号都有自己独一无二的编码，这样就从根本上解决了乱码的问题。所以Unicode是一种所有符号的编码[2]。
Unicode伴随着通用字符集的标准而发展，同时也以书本的形式对外发表，它是业界的标准，对世界上大部分的文字系统进行了整理、编码，使得电脑可以用更为简单的方式来呈现和处理文字。Unicode至今仍在不断增修，迄今而至已收入超过十万个字符，它备受业界认可，并广泛地应用于电脑软件的国际化与本地化过程。
我们知道Unicode是为了解决传统的字符编码方案的局限而产生的，对于传统的编码方式而言，他们都存在一个共同的问题：无法支持多语言环境，这对于互联网这个开放的环境是不允许的。而目前几乎所有的电脑系统都支持基本拉丁字母，并各自支持不同的其他编码方式。Unicode为了和它们相互兼容，其首256字符保留给ISO 8859-1所定义的字符，使既有的西欧语系文字的转换不需特别考量；并且把大量相同的字符重复编到不同的字符码中去，使得旧有纷杂的编码方式得以和Unicode编码间互相直接转换，而不会丢失任何信息[1]。
一个字符的Unicode编码是确定的，但是在实际传输过程中，由于不同系统平台的设计不一定一致，以及出于节省空间的目的，对Unicode编码的实现方式有所不同。Unicode的实现方式称为Unicode转换格式（Unicode Transformation Format，简称为UTF）[1]。
Unicode是字符集，它主要有UTF-8、UTF-16、UTF-32三种实现方式。由于UTF-8是目前主流的实现方式，UTF-16、UTF-32相对而言使用较少，所以下面就主要介绍UTF-8。
提到Unicode可能有必要了解下，UCS。UCS（Universal Character Set，通用字符集），是由ISO制定的ISO 10646（或称ISO/IEC 10646）标准所定义的标准字符集。它包括了其他所有字符集，保证了与其他字符集的双向兼容，即，如果你将任何文本字符串翻译到UCS格式，然后再翻译回原编码，你不会丢失任何信息。
UCS不仅给每个字符分配一个代码，而且赋予了一个正式的名字。表示一个UCS或Unicode值的十六进制数通常在前面加上“U+”，例如“U+0041”代表字符“A”。
Little endian & Big endian
由于各个系统平台的设计不同，可能会导致某些平台对字符的理解不同（比如字节顺序的理解）。这时将会导致同意字节流可能会被解释为不同的内容。如某个字符的十六进制为4E59，拆分为4E、59，在MAC上读取时是欧诺个低位开始的，那么MAC在遇到该字节流时会被解析为594E，找到的字符为“奎”，但是在Windows平台是从高字节开始读取，为4E59，找到的字符为“乙”。也就是说在Windows平台保存的“乙”跑到MAC平台上就变成了“奎”。这样势必会引起混乱，于是在Unicode编码中采用了大头（Big endian）、小头（Little endian）两种方式来进行区分。即第一个字节在前，就是大头方式，第二个字节在前就是小头方式。那么这个时候就出现了一个问题：计算机怎么知道某个文件到底是采用哪种编码方式的呢？
Unicode规范中定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做”零宽度非换行空格”（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。这正好是两个字节，而且FF比FE大1。
如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。
UTF-8是一种针对Unicode的可变长度字符编码,可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。它可以用来表示Unicode标准中的任何字符，且其编码中的第一个字节仍与ASCII兼容，这使得原来处理ASCII字符的系统无须或只须做少部份修改，即可继续使用。因此，它逐渐成为电子邮件、网页及其他存储或传送文字的应用中，优先采用的编码。
UTF-8使用一到四个字节为每个字符编码，编码规则如下：
1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。
2）对于n字节的符号（n&1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。
转换表如下：
0080 ~07FF
110X XXXX 10XX XXXX
0800 ~FFFF
1110XXXX 10XX XXXX 10XX XXXX
1 0000 ~1F FFFF
1111 0XXX 10XX XXXX 10XX XXXX 10XX XXXX
20 0000 ~3FF FFFF
1111 10XX 10XX XXXX 10XX XXXX 10XX XXXX 10XX XXXX
400 0000 ~7FFF FFFF
X 10XX XXXX 10XX XXXX 10XX XXXX 10XX XXXX 10XX XXXX
根据上面的转换表，理解UTF-8的转换编码规则就变得非常简单了：第一个字节的第一位如果为0，则表示这个字节单独就是一个字符;如果为1，连续多少个1就表示该字符占有多少个字节。
以汉字”严”为例，演示如何实现UTF-8编码[3]。
已知”严”的unicode是4E25（101），根据上表，可以发现4E25处在第三行的范围内（00 FFFF），因此”严”的UTF-8编码需要三个字节，即格式是&#xxxx 10xxxxxx 10xxxxxx”。然后，从”严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，”严”的UTF-8编码是&#0 0;，转换成十六进制就是E4B8A5。
Unicode与UTF-8之间的转换
通过上面的例子我们可以看到”严”的Unicode码为4E25，UTF-8编码为E4B8A5，他们两者是不一样的，需要通过程序的转换来实现，在Window平台最简单的直观的方法就是记事本。
在最下面的”编码（E）”处有四个选项：ANSI、Unicode、Unicode big endian、UTF-8。
ANSI：记事本的默认的编码方式，对于英文文件是ASCII编码，对于简体中文文件是GB2312编码。注意：不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ANSI 编码的文本中
Unicode：UCS-2编码方式，即直接用两个字节存入字符的Unicode码。该方式是”小头”little endian方式。
Unicode big endian：UCS-2编码方式，”大头”方式。
UTF-8：阅读上面（UTF-8）。
&&&实例：在记事本中输入”严”字，依次选择ANSI、Unicode、Unicode big endian、UTF-8四种编码风格，然后另存为，使用EditPlus文本工具使用”16进制查看器”进行查看，得到如下结果：
ANSI：两个字节”D1 CF”正是”严”的GB2312编码。
Unicode：四个字节”FF FE 25 4E”，其中”FF FE”表示小头存储方式，真正的编码为&#E”。
Unicode big endian：四个字节”FE FF 4E 25″，”FE FF”表示大头存储方式，真正编码为&#″。
UTF-8：编码是六个字节”EF BB BF E4 B8 A5″，前三个字节”EF BB BF”表示这是UTF-8编码，后三个&#A5″就是”严”的具体编码，它的存储顺序与编码顺序是一致的。
参考文献&更多阅读
1、Unicode维基百科：
2、Unicode百度百科：
3、字符编码笔记：ASCII，Unicode和UTF-8：
4、UTF-8百度百科：
关于ImportNew
ImportNew 专注于 Java 技术分享。于日 11:11正式上线。是的，这是一个很特别的时刻 :)
ImportNew 由两个 Java 关键字 import 和 new 组成，意指：Java 开发者学习新知识的网站。 import 可认为是学习和吸收， new 则可认为是新知识、新技术圈子和新朋友……
新浪微博：
推荐微信号
反馈建议：ImportNew.
广告与商务合作QQ：
– 好的话题、有启发的回复、值得信赖的圈子
– 写了文章？看干货？去头条！
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 活跃 & 专业的翻译小组
– 国内外的精选博客文章
– UI,网页，交互和用户体验
– JavaScript, HTML5, CSS
– 专注Android技术分享
– 专注iOS技术分享
– 专注Java技术分享
– 专注Python技术分享
& 2018 ImportNew春水碧于天，画船听雨眠
处理字符串
将字符串中的unicode字符转为汉字
处理字符串 将字符串中的unicode字符转为汉字
public class UnicodeUtil {
* 处理字符串
将字符串中的unicode字符转为汉字
* asciicode
public static String ascii2native ( String asciicode )
String[] asciis = asciicode.split ("\\\\u");
StringBuffer nativeValue = new StringBuffer();
nativeValue.append(asciis[0]) ;
for ( int i = 1; i & asciis. i++ )
String code = asciis[i];
nativeValue.append((char) Integer.parseInt (code.substring (0, 4), 16));
if (code.length () & 4)
nativeValue.append(code.substring (4, code.length ())) ;
catch (NumberFormatException e)
return nativeValue.toString();
没有更多推荐了，专注Java工作多年
Java用native2ascii命令做unicode编码转换
https://www.cnblogs.com/tv151579/archive//2862706.html
背景：在做Java开发的时候，常常会出现一些乱码，或者无法正确识别或读取的文件，比如常见的validator验证用的消息资源 （properties）文件就需要进行Unicode重新编码。原因是java默认的编码方式为Unicode，而我们的计算机系统编码常常是GBK等编码。需要将系统的编码转换为java正确识别的编码问题就解决了。
　　1. native2ascii简介：native2ascii是sun java sdk提供的一个工具。用来将别的文本类文件（比如*.txt,*.ini,*.properties,*.java等等）编码转为Unicode编码。 为什么要进行转码，原因在于程序的国际化。Unicode编码的定义：Unicode（统一码、万国码、单一码）是一种在计算机上使用的字符编码。它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。1990年开始研发，1994年正式公布。随着计算
机工作能力的增强，Unicode也在面世以来的十多年里得到普及。（声明：Unicode编码定义来自互联网）。
　　2. 获取native2ascii：安装了jdk后，假如你是在windows上安装，那么在jdk的安装目录下的bin目录，其中native2ascii.exe正是。
　　3. native2ascii的命令行的命名格式：
native2ascii -[options] [inputfile [outputfile]]
　　-[options]：表示命令开关，有两个选项可供选择
　　-reverse：将Unicode编码转为本地或者指定编码，不指定编码情况下，将转为本地编码。
　　-encoding encoding_name：转换为指定编码，encoding_name为编码名称。
　　-[inputfile [outputfile]]
　　inputfile：表示输入文件全名。
　　outputfile：输出文件名。如果缺少此参数，将输出到控制台。
　　4. 最佳实践：
　　a.首先将JDK的bin目录加入系统变量
　　b.在盘下建立一个test目录，在test目录里建立一个zh.txt文件，文件 内容为：“熔岩”，打开“命令行提示符”，并进入C:\test目录下;
　　c.下面就可以按照说明一步一步来操作，注意观察其中编码的变化。
　　A：将zh.txt转换为Unicode编码，输出文件到u.txt
　　native2ascii zh.txt u.txt
　　打开u.txt，内容为“\u”。
　　B：将zh.txt转换为Unicode编码，输出到控制台
　　C:\test&native2ascii zh.txt
　　\u　　可以看到，控制台输出了“\u”。
　　C：将zh.txt转换为ISO8859-1编码，输出文件到i.txt
　　native2ascii -encoding ISO8859-1 zh.txt i.txt
　　打开i.txt文件，内容为“\u00c8\u00db\u00d1\u00d2”。
　　D：将u.txt转换为本地编码，输出到文件u_nv.txt
　　native2ascii -reverse u.txt u_nv.txt
　　打开u_nv.txt文件，内容为“熔岩”。
　　E：将u.txt转换为本地编码，输出到控制台
　　C:\test&native2ascii -reverse u.txt
　　可以看到，控制台输出了“熔岩”。
　　F：将i.txt转换为本地编码，输出到i_nv.txt
native2ascii -reverse i.txt i_nv.txt
　　打开i_nv.txt文件，内容为“\u00c8\u00db\u00d1\u00d2”。发现转码前后完全一样的。也就是说，等于没有转，或者说思想糊涂，对命名没有理解。。
　　G：将i.txt转换为GBK编码，输出到i_gbk.txt
　　native2ascii -reverse -encoding GBK i.txt i_gbk.txt
　　打开i_gbk.txt文件，内容为“\u00c8\u00db\u00d1\u00d2”。发现转码前后完全一样的。也就是说，等于没有转，或者说思想糊涂，对命名没有理解。
　　H：将u_nv.txt转码到本地编码GBK，输出到控制台
　　C:\test&native2ascii -reverse -encoding ISO8859-1 i.txt
　　从这个结果看，目标达到到了，编码i.txt为ISO8859-1，转为本地编码后内容为“熔岩”。从这里应该意识到，native2ascii -reverse命令中-encoding指定的编码为源文件的编码格式。而在native2ascii 命令中-encoding指定的编码为（生成的）目标文件的编码格式。这一点非常的重要！切记！！
　　继续探索，新建文件12a.txt，内容“12axyz”。看看纯字母数字的编码又如何?
　　I：将纯字母数字的文本文件12a.txt转换为Unicode编码
　　native2ascii 12a.txt 12a_nv.txt
　　打开12a_nv.txt文件，内容为“12axyz”。
　　继续测试，转为ISO8859-1编码看看
　　C:\test&native2ascii -encoding ISO8859-1 12a.txt
　　12axyz
　　结果还是没有转码。
　　从结果可以得出结论：对于纯数字和字母的文本类型件，转码前后的内容是一样的。
　　5、总结：native2ascii是一个非常的好转码工具，并且转码是可逆的！而其真正的含义并非本地编码——&转码为ASCII码， 而是一个通用的文本文件编码转换工具。在做编码转换的时候有两类指定编码的情形，分别指输出文件编码和输入文件编码，具体可以看看最佳实践部分。
没有更多推荐了，}