字符编码是什么？

 

 

字符编码是什么？
计算机只能进行二进制存储、运算数据，也就是说，你输入一个数字“9”，会被计算机识别成“1001”。
但是，你使用的毕竟不是计算器，总要输入个"abcdefg"，这个时候，就有了ASCII编码（ASC读作“阿斯科”）系统。英文字母只有26种变化，算上大小写也只有52种变化，再加上老外用的英文标点符号、特殊字符也没多少种变化。用8位二进制数就可以表达256种字符，这就足以胜任处理英文字符的工作了。
但是，在我们这些非英文用户这里，大部分时间都要输入非英文字符。汉字保守估计有6万多个，常用的有三五千个。ASCII编码肯定是无法满足我们的需求的，于是就有诸如BIG5、GBK这类字符编码，用16位二进制数可以表达65535个汉字，对日常用字来说是够用了。
现在简体中文环境常用的编码除了GB2312和GB18030之外，还会用到UTF-8。GBK是专用做中文的字符编码规范，UTF是通用转换格式的缩写，又被称为万国码，理论上来说可以表达各种文字的编码格式。
现在我们明白了，字符编码，就是将“人类可以识别的汉字、英文字母、标点符号等信息”和“计算机可以识别的二进制信息”进行转换的规则。

乱码是什么？
假设你用的一个普通的中文操作系统，你打开网页浏览器是可以正常显示中文的，但如果你刻意选错了编码，选择日语、越南语、希伯来语等编码，打开的网页肯定都是你读不出来的一些外语。但这个时候你找个懂日语、越南语、希伯来语的人来看这个网页，他也是看不懂的。你更换编码了就会真的实现一键翻译，但这个翻译结果就是驴唇不对马嘴的乱码。
上文是用错了编码的情况，很多时候不是我们想用错，而是压根就没有这个字符集。比如说我们精简安装一个linux系统，或者纯英文版（非多语言支持版）的windows，我们尝试打开中文网页的时候就会看到惨不忍睹的乱码。
乱码问题只会出现在两种情况下：
1，操作系统层面缺少可以正常使用的字符集。
2，应用程序使用了错误的字符编码。

操作系统缺少字符集是最容易解决的问题，windows有多语言支持版、有东亚语言支持包，Unix/Linux下也可以安装中文支持。“locale -a”命令可以查看当前linux系统安装了哪些字符集。
但就算系统有了编码字符集，应用程序也经常会用错它。
1，应用程序本身不支持某些字符编码；这种情况一般出现在开发工具或服务器软件上。大家记得编译mysql的时候是可以指定支持哪种字符集的吧？不支持这种字符集但你坚决要用这种字符集，那就只有换软件这一个方法。
2，应用程序手头有N多种可用字符集，但没有用对，比如说mysql给php发utf-8格式的数据，但php用gb2312解读的一头雾水，最后还用big5给mysql回馈，让他更改字符集，最后大家集体晕菜。。。

针对第二种情况，我列一下几个常见的问题解决方法：
1，shell显示中文的问题。
 首先设置当前shell的LANG变量为en_US.UTF-8并确认。
 [root@caotest-1 ~]# LANG=en_US.UTF-8
 [root@caotest-1 ~]# echo  $LANG
 en_US.UTF-8
 然后在支持中文字符的系统（如winxp）下新建一个文件“文本文档.txt”，并传输到当前shell。
 然后ls看一下。
 [root@caotest-1 ~]# ls  *.txt
 ?谋??牡?.txt
 OK，现在的输出结果已经是乱码了，但接下来用一个命令就可以让bash shell正常显示中文：
 [root@caotest-1 ~]# LANG=zh_CN.GB18030
 [root@caotest-1 ~]# ls  *.txt
 文本文档.txt
 这是怎么回事哪？我们知道bash shell是redhat/centos linux的默认人机交互界面，但它也只是一个应用程序。在它的设定中，使用什么字符编码就是去读取“LANG”变量。当字符编码是“en_US.UTF-8”它无法正常显示中文文件名，但当我们将编码设置成linux系统中已有可用的另一个支持中文的字符集“zh_CN.GB18030”，它就可以正常显示中文了。
 如果要让你的shell长期支持中文，可以每次登录shell都手动指定LANG变量为“zh_CN.GB18030”，也可以将这个变量设定加到“~/.bash_profile ”或“/etc/profile”。
 但这样都只是给LANG变量“重命名”，它的初次定义在哪里哪？就在这个文件：
 [root@caotest-2 ~]# cat  /etc/sysconfig/i18n
 LANG="en_US.UTF-8"
 SYSFONT="latarcyrheb-sun16"
 “/etc/sysconfig/i18n”这个文件即定义了当前正在使用哪个字符集，又定义了诸如系统字体等信息，我们可以通过修改它来修改系统默认的字符集。
2，ssh/ftp等工具连接后出现乱码的问题。
 这种情况比较少见，ssh/ftp客户端工具一般兼容性很好，能正常的识别对端服务器使用的什么编码。但正是因为一般不出什么问题，出现了问题就能堵住初学者。
 以SecureCRT为例，在“选项”——“会话选项”——“终端”——“外观”里就有“字符编码”的选项，默认选项是是“默认”。我们如果遇到乱码以后就应该考虑SecureCRT使用的字符编码和bash shell使用的是否相同，如果不同，我们可以选择修改SecureCRT，也可以修改bash shell。
 比如说设置shell变量 LANG="en_US.UTF-8"，使用SecureCRT运行“setup”命令就会出现乱码。
 那么请你试试修改LANG=en，然后在SecureCRT里运行一下“setup”，就会出现正常的英文界面。而当我们设置 LANG=zh_CN.GB18030，再次运行setup，就会出现正常的中文界面。
3，服务器程序之间乱码导致的问题。
 本来我一直不太重视这个问题，但在上个月就发生了一次问题。因为resin（一个类似tomcat的java容器）的字符集发生了变动，最终导致resin服务无法连接到oracle。在很多次试验中，我们没有遇到字符集相关问题，这是因为“默认”的设置恰好兼容性最好而已，但一旦出现了不兼容问题，往往都无从下手。所以我们要有意识的保持程序之间沟通时字符集的一致性。