分类 技术志 下的文章

也谈计算机字符编码

以前真的未就计算字符编码有过什么深入的学习探究,这次学习也是源于客户的一次投诉。客户的投诉简要来说就是:我们的网关在截断客户发的长度越限的短信内容时,导致该短信在终端上显示为乱码。顺着这个起因,我花了一些时间概要性的学习了一些关于计算机字符编码的常识性知识。

字符,这个我们在平时编码过程中最最常见的元素,其实也有着一段小故事。

计算机,毫无疑问是一部机器,在最初我们接触计算机时或者接收计算机教育时,我们就知道:计算机能识别的只有010101的二进制码。人与计算机交互早期也是用的是二进制方式,当时人们或通过扳动计算机庞大的面板上无数的开关来向计算机输入信息,或使用打孔卡片来向计算机输入指令和数据。终端和键盘组成的字符人机界面的诞生让人们大大提高了与计算机的交互效率。这里提到了'字符',那么什么是'字符'?说的通俗些:字符就是人们使用的记号,抽象意义上的一个符号。比如阿拉伯数字1,这就是一个符号,这个符号的抽象含义:1代表一种数量的概念,关于1这个抽象概念是如何诞生的,有兴趣的人可以去翻阅一下类似数学史之类科普书籍。

人类的记号五花八门,包括国家文字、标点符号、图形符号、数字等。这些在计算机领域会被统称为'字符'。而所有字符的集合就被称为'字符集'。有了'字符'概念,那么在计算机中如何表示'字符'呢?前文提到了计算机中都是用二进制bit来交流的,'字符'也只能建筑在bit的基础上。多少bit表示一个字符合适呢?或者说我们的字符集有多大呢?如果字符集里只有8个字符,那么我用3个bit的组合就可以将这些字符都表示和识别出来。想当年美国人也在考虑这个问题,不过美国人想当然的就认为:所有能用到的有现实意义的字符不超过256个,当时美国人也只用到了128个,预留128个备用,而256个字符的字符集用8bit就可以表示,这就是举世闻名的美国标准信息交换代码( American Standard Code for Information Interchange, ASCII)。而这8bit恰与计算机中的基本存储数据单元-'字节'的位个数相同,这样一个字节就恰可以表示一个ASCII字符了。如:ASCII字符'A'的内存位模式:0×41。

这里提到了一个'编码'的概念,上面提到的ASCII就是众多字符编码规范中的一种,最早的一种,最重要的一种。那么什么是字符编码呢?回顾一下ASCII在制订的时候都做了哪些事:
1) 规定用8bit即一个字节来表示一个ASCII字符;
2) 制定了ASCII字符表,即该字符集中的每个字符对应的位模式。如:ASCII字符'B'的内存位模式:0×42,'1'的内存位模式:0×31。

由此看来一个字符编码规范要做两件事:
1) 规定这个字符集中的字符用多少字节来表示;
2) 制订该字符编码集的字符表,即该字符集中每个字符对应的位模式
1)和2)这两个规定合在一起就是编码。

随着计算机的普及,世界各国都开始使用计算机,但是对于非英语国家如中、日、韩等来说,ASCII码是远远不能满足本国人的需要的,我中华文明渊源五千年,这五千年来积淀下来的文明怎是这256个字符(精确的说是128个字符)所能表达出来的。我们也要制定自己的编码,同样日本人、韩国人也都是这么做的。这样一来,世界范围内就多了诸如GB2312、BIG5、JIS等局限于某个国家或地区使用的本地化编码标准,这些编码标准被统称为:ANSI编码。这些ANSI编码有一些共同的特点:
1) 每种ANSI编码或者说ANSI字符集只规定自己国家或地区使用的语言所需的'字符';比如中文GB-2312编码中就不会包含韩国人的文字。
2) ANSI字符集的空间都比ASCII要大很多,一个字节已经不够,绝大多数都使用了多字节的存储方案。
3) ANSI编码一般都会兼容ASCII码。

ANSI的出现让计算机迅速普及到世界的每个角落,每个国家都利用上了这样的先进的工具提高了自己的生产力。打开Windows记事本,"另存为"对话框的"编码"下拉框中有ANSI编码,在简体中文系统下,ANSI编码代表GB2312编码,在日文操作系统下,ANSI 编码代表 JIS 编码。但是随着互联网的兴起,问题出现了。由于ANSI码的第一个特点:各个国家或地区在编制自己的ANSI码时并未考虑到其他国家或地区的ANSI码,导致编码空间有重叠,比如:汉字'中'的GB编码是[0xD6,0xD0],这个编码在JIS中是什么呢,我不知道,我也不愿意去查那些稀奇古怪的鬼子文,但我可以肯定的是肯定不是'中'这个字符了,虽然鬼子的语言文字中抄袭了大量的汉文字。这样一来当在不同ANSI编码系统之间进行信息交换和展示的时候,乱码就不可避免了。

为了使国际间信息交流更加方便,Unicode字符集编码诞生。Unicode是Universal Multiple-Octet Coded Character Set的缩写,中文含义是"通用多八位编码字符集"。它是由一个名为 Unicode学术学会(Unicode Consortium)的机构制订的字符编码系统,Unicode目标是将世界上绝大多数国家和的确的文字、符号都编入其字符集,它为每种语言中的每个字符设定了统一并且唯一的二进制编码(位模式),以满足跨语言、跨平台进行文本转换、处理的要求,以达到支持现今世界各种不同语言的书面文本的交换、处理及显示的目的,使世界范围人们通过计算机进行信息交换时达到畅通自如而无障碍。说白了Unicode编码就是先将世界上存在的绝大多数常用字符纳入Unicode字符集,然后进行统一排号。而每个Unicode字符的编码(位模式)就是该字符在Unicode字符表中的序号,所以与上面提到的ANSI编码不同的是,一个Unicode字符的编码用的是一个整数表示,而这个整数的长度通常>= 2个字节。这样Unicode编码在不同平台存储时就要注意其字节序了。比如:采用标准Unicode编码的'中'在Windows上的存储就是'2D4E',而在SPARC Solaris上的存储则是'4E2D'。

上面提到了标准Unicode编码,难道还有其他Unicode编码方式,的确,Unicode的出现的确使我们在统一计算机编码过程中迈出的一大步,但是毕竟Unicode诞生才10几年,这之前大家一直使用ASCII码,一直使用各自的ANSI编码。要想一次性将全世界的计算机系统都统一改为Unicode编码,可能性不大。那么现在越来越多的新系统都开始支持并使用Unicode,这些新系统与旧系统之间如何交换数据其实是首要难题。于是一个新名词又诞生了,那就是UTF, Unicode Translation Format,即把Unicode转做某种格式的意思。为什么要转换成某种格式呢?转换是为了传输和交换。一种好的UTF-x方案应该便于在不同的计算机之间使用网络传输不同语言和编码的文字,使得标准双字节的Unicode能够在现存的处理单字节的系统上正确传输。目前比较常见的UTF方案有三种:
UTF-16:其本身就是标准的Unicode编码方案,又称为UCS-2,它固定使用16 bits(两个字节)整数来表示一个字符。
UTF-32:又称为UCS-4,它固定使用32 bits(四个字节)整数来表示一个字符。
UTF-8:最广泛的使用的UTF方案,UTF-8使用可变长度字节来储存Unicode字符,例如ASCII字母继续使用1字节储存,重音文字、希腊字母或西里尔字母等使用2字节来储存,而常用的汉字就要使用3字节。辅助平面字符则使用4字节。UTF-8更便于在使用Unicode的系统与现存的单
字节的系统进行数据传输和交换。与前两个方案不同:UTF-8以字节为编码单元,没有字节序的问题。

UTF有三种方案,那么如何在接收数据和存储数据时识别数据和指导识别数据采用的是哪个方案呢?在UTF编码方案中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传输或存储中。UCS规范建议我们在传输或存储字节流前,先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样根据识别前面的"ZERO WIDTH NO-BREAK SPACE"即可识别编码方案:
EF BB BF UTF-8
FE FF UTF-16/UCS-2, little endian
FF FE UTF-16/UCS-2, big endian
FF FE 00 00 UTF-32/UCS-4, little endian.
00 00 FE FF UTF-32/UCS-4, big-endian.

以上是简略的字符编码的基本知识。下面将编码与具体的编程语言结合起来进行更直观的学习。这里还是以C语言举例。
C语言定义了两个字符集(character set):源代码字符集(source character set)是用于组成C源代码的字符集合,而运行字符集(execution character set)是可以被执行程序解释的字符集合。应用程序都有自己的执行字符集,也就说在应用程序执行过程中使用什么字符集或字符编码来识别各种数据存储介质中的bit流。

[Example1]
/* testwprintf.c , windows xp, mingw gcc-3.4.2 */
int main() {
wchar_t ws[] = L"中文"; — (1)
wprintf(L"%s\n", ws);
}

编译该程序gcc编译器提示:(1)这行:converting to execution character set: Illegal byte sequence
为什么转换失败呢?我们看到程序中使用了宽字符常量。这里先插入一段C语言的小故事:多字节字符和宽字节字符。
C语言原本是在英文环境中设计的,主要的字符集是ASCII字符。但是国际化软件必须能够表示不同的字符,而这些字符数量庞大,无法使用一个字节编码,于是在1994年,"Normative Addendum 1"(基准增补一)的采用,让ISO C可以标准化两种表示大型字符集的方法:宽字符(wide character,该字符集内每个字符使用相同的位长)以及多字节字符(multibyte character,每个字符可以是一到多个字节不等,而某个字节序列的字符值由字符串或流(stream)所在的环境背景决定)。自从1994 年的增补之后,C不只提供char类型,还提供wchar_t类型(宽字符)。虽然此次C标准仍没有支持Unicode字符集,但许多实现版本使用Unicode转换格式UTF-16和UTF-32来处理宽字符(我遇到的mingw gcc用的是UTF-16, Sun Sparc Gcc用的则是UTF-32),也就是说在大部分标准C实现版本中,默认的一个wchar_t就是一个unicode字符,一个宽字符实际上就是一个unicode字符,一个宽字符常量字符串(L"…")实际上是一个unicode编码的常量字符串。这样我们来解释上面的问题。

上面程序中编译器在遇到宽字符常量:L"中文"时,试图将之转换成unicode码存储,mingw gcc试图使用默认的源代码符号集->unicode的转码方式转换"中文"这个字面量的二进制位模式到unicode位模式,但却发现"中文"这个字面量的位模式不能识别,这就需要我们在外部告知gcc我们的这个"中文"字面量的位模式是GB2312的,我们使用:gcc -finput-charset=GB2312 testwprintf.c就能解决这一问题了。

好了,编译完了。我们来执行一下a.exe,但却发现在控制台没有任何输出,又出现什么问题了呢?分析一下:目前我们的ws中使用的位模式是unicode编码位模式,哇,原来wprintf并不支持直接输出:unicode编码。类似:printf, wprintf等输出到控制台或者文件的库函数只支持ANSI编码或多字节编码输出。其实这是符合C语言规范的,因为C标准并未支持Unicode,只是很多C的实现将宽字符用unicode的位模式表示罢了。这时我们需要通过setlocale函数来设置如何将unicode编码的宽字符转换成一种可以输出的编码。
[Example2]
/* testwprintf.c , windows xp, mingw gcc-3.4.2 */
int main() {
wchar_t ws[] = L"中文";
setlocale(LC_ALL, "chs"); /* 设置gb码, unix上没有"chs"这样的locale,unix上可通过locale -a查 */
wprintf(L"%s\n", ws);
}
setlocale(…)只在运行时起作用,这样编译执行后,"中文"二字就会显示在我们的控制台上了。

当然了我们还可以通过标准库调用将宽字符手动转成ANSI字符后再直接输出。
[Example3]
/* testwprintf.c , windows xp, mingw gcc-3.4.2 */
int main() {
wchar_t ws[] = L"中文";
char ms[12];
memset(&ms, 0, sizeof(ms));

setlocale(LC_ALL, "chs"); /* 设置gb码, unix上没有"chs"这样的locale,unix上可通过locale -a查 */
wcstombs(ms, ws, sizeof(ms));
printf("%s\n", ms);
}
编译执行后,"中文"二字同样跃然纸上。wcstombs是将宽字符串按照setlocale设置的编码转成指定的ANSI编码字符串;而mbstowcs则是按照etlocale设置的编码将将多字节字符串转换成unicode编码存储在宽字符串中。前者调用setlocale是指导目标编码的;后者调用setlocale的作用是指导如何将源字符串翻译成目的unicode字符串的。类似的还有字符级别的标准函数:wctomb和mbtowc。

关于字符编码转换,其实有很多好用的开源工具包可用,比如著名的iconv,自己平时很少会去实现一个编码转换。学习以上知识只是为了让自己再遇到乱码问题的时候不再迷糊,而且对计算机字符编码知识有一个概念上的了解是必要的且大有裨益的。

浅谈如何编码使程序更易维护

毕业后就一直从事于服务器端程序的开发,主要客户是中国移动,大家知道移动的产品都是电信级的,稍出差错后果都是严重的,所以在我们平时的工作中除了研发之外,还有的就是对我们卖给移动的产品的维护性工作,而这种维护性工作要求就是要"迅速解决现场的问题"。这几个月维护工作占据了我很大一部分精力,说实话,有些烦了,但是从另外一个角度来看,也说明了我们的产品在维护性方面做的不够好,否则移动的工作人员或当地的技术支持人员通过手册或者查看系统日志的方式就可以解决问题的。这让我反思。

一般来说,我们的产品在交付时都是有详尽的用户手册的,现场人员可以根据维护手册来查找问题所在。另外维护工作也是分层次的,在运行我们产品的各省移动公司都有我们的当地技术支持人员,而移动自己的网管人员在多年的维护过程中也逐渐的积累了丰富的问题解决经验。一般问题发生后,移动的人员都会试着自己来尝试解决,当其无法解决时,会将问题告诉当地的技术支持人员,只有在技术支持人员也解决不了问题的时候,问题才会反馈给我们研发人员,而研发人员就成为了系统的最后一道保护伞了。移动人员的素质我们自然控制不了,我方技术人员我们会尽可能的通过培训和讲解的方式传授解决问题的办法,并通过他们自己在维护过程中积累经验,但是一旦问题提交给研发人员,我们就需要在远程以最快的时间将问题解决。

研发人员一般来说对业务熟悉,对功能是如何实现也有把握,但是一个系统往往是很庞大的,很可能是经过"几代人"前离后继"(前人离职了,后人来继承)完成的,所以到最后很可能整个产品组内没有一个人对整个系统的每个角落都了如指掌的,这时问题就出现了。

对于研发人员来说,他们最擅长的就是通过问题现象去到代码里分析,现场产品因为在运行,一般来说我们不可能去用调试工具直接调试现场运行的程序的。而问题的现象一般是通过系统日志体现出来的;也就是说在研发人员解决问题这层,系统的运行日志对解决问题起着至关重要的作用。这样一来系统日志设计的好坏直接会影响到你解决问题的效率和质量。

而通过日志定位问题所在的代码位置一般有如下几个现象:

[现象一]  当你用某一个错误日志去search in project的时候,居然发现:
if (condition1 | condition2 | condition3)
      你查询的日志输出;
输出该日志的条件是多个或的关系,而且每个condition也许是一个复杂的函数调用,这会大大延长你跟踪问题的时间;

解决方法:
a) 尽量减少condition1 | condition2 | condition3的使用;
b) 对于复杂和关键地方的处理,给出"点睛"的注释;

[现象二] 当你用某一个错误日志去search in project的时候,居然发现:
Project中存在不止一条这样的错误日志,其位置可能分布在Project的不同源文件中的不同位置。这同样会大大延长你跟踪问题的时间和难度。

解决方法:
我们套用"幸福的家庭往往是相同的,不幸的家庭各有各的不幸"来说明:成功的日志往往格式相同,失败的日志各有各的特征。如果每条错误日志的特点都不相同,那么当我们search的时候,就可以一次定位问题所在了。

[现象三] 当你用某一个错误日志去search in project的时候,居然发现:
该日志是在一个宏的定义中输出的,而该宏散布在Project的各个角落。

解决方法:
不要在宏(广泛使用的宏)中做任何日志输出。

当然上述的某些解决方法可能与代码的可读性或者精炼性有悖,这就要看你是如何抉择的了,根据具体情况三思而后行。

另外对于查找问题而言,关键而详尽的注释会给研发人员带来很大帮助,否则他就很可能陷入复杂的业务逻辑中,长时间不能自拔了。

以上一点私人见解,仅供参考。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats