自从上次'编译Ethereal On Windows'之后，好久没有接触Ethereal了，前期策划的基于Ethereal开发的一个工具的任务就落到了这批来的一个新员工的头上了。第一阶段他在Windows上开发了一个基于Ethereal的插件用于分析CMPP协议之用；第二个阶段我们需要移植到Unix上，我们使用的是Solaris。

目标机器是一个x86的Solaris10的系统，首先是将Ethereal依赖的所有开源包都先装上。开源的唯一不好的一点就是互相依赖太多，像Ethereal这样规模的软件，依赖的包不下十几种。这里我们用的源码包是ethereal-0.99.0。按照常规编译软件包的方法：解包=>进入Ethereal目录=>执行./configure => make。

如果想一次make成功显然是不太可能的。

我的那个新同事第一次make得到如下结果：
libtool: link: only absolute run-paths are allowed，他查找了好久，终于"投降"了。由于是新同事对Unix上繁芜复杂的操作不了解也是情有可原的，亲自出马吧。

我对libtool同样是不熟悉，到网上找答案吧。网上关于这个错误的解释太少了。只能用"only absolute run-paths are allowed"在libtool这个脚本文件里搜索，果然找到了，有两个地方有这样的echo输出。大致检查了一下，基本定位问题所在：在libtool执行的语句中，有类似"-R../lib"这样的参数选项，显然这个"../lib"不是一个绝对路径，我们需要针对这个地方进行一下手工修改。

目标就是Makefile文件。打开Makefile搜寻"../lib"，一共有4处，分别在SNMP_LIBS、ethereal_LDADD、tethereal_LDADD和dftest_LDADD的定义中，在其中删除"-R../lib"或者为-R指定一个绝对路径即可。

问题解决，继续Make。还是没有过去，提示：在"/usr/sfw/lib/.libs下找不到libnetsnmp.so"，Makefile中明明配置的是/usr/sfw/lib，且该路径下存在libnetsnmp.so，为什么libtool非要到"/usr/sfw/lib/.libs"下找呢？libtool就是这样一个怪脾气，没办法，创建/usr/sfw/lib/.libs路径，并将libnetsnmp.so拷贝进去，在Make这块就过去了。

问题仍然层出不穷，程序在链接tethereal的时候，提示：ld: fatal: Symbol referencing errors. No output written to .libs/tethereal
Undefined                       first referenced
 symbol                             in file
gsm_a_pd_str                        tap-gsm_astat.o
RegistrationRejectReason_vals       tap-h225counter.o
register_all_protocol_handoffs      tethereal.o

继续在网上搜索，还好有类似的问题别人也遇到了，解决方法：将epan/dissectors/.libs/libdissectors.a加到Makefile中多个变量的定义中。下面是详细的修改：
(1)
tethereal_additional_libs = \
        wiretap/libwiretap.la           \
        epan/libethereal.la

=>

tethereal_additional_libs = \
        wiretap/libwiretap.la           \
        epan/libethereal.la \
        epan/dissectors/.libs/libdissectors.a \

(2)
dftest_additional_libs = \
        wiretap/libwiretap.la           \
        epan/libethereal.la \
=>
dftest_additional_libs = \
        wiretap/libwiretap.la           \
        epan/libethereal.la \
        epan/dissectors/.libs/libdissectors.a
(3)
dumpcap_LDADD = \
        $(dumpcap_additional_libs)      \
        -lgmodule-2.0 -lglib-2.0                        \
        -lpcap
=>
dumpcap_LDADD = \
        $(dumpcap_additional_libs)      \
        -lgmodule-2.0 -lglib-2.0                        \
        -lpcap -lsocket -lnsl
(4)
ethereal_additional_libs = \
        gtk/libui.a             \
        wiretap/libwiretap.la   \
        epan/libethereal.la \
=>
ethereal_additional_libs = \
        gtk/libui.a             \
        wiretap/libwiretap.la   \
        epan/libethereal.la \
        epan/dissectors/.libs/libdissectors.a \
这回你再make，哇，编译成功了。

然后敲入make install安装这个ethereal，在Windows上启动Xmanager(trial版)，连接到目标服务器，用root登录(如果没有root权限，是看不到网卡的，也就不能进行协议分析了)。进入/usr/local/bin，在这里我只发现了tethereal这个程序，执行起来也没有问题，但是那个图形界面的ethereal哪里去了。翻看install的日志，发现根本没有安装ethereal。怎么回事？

继续网上找答案，很快答案找到了：是否编译安装ethereal是configure决定的。在configure的执行日志我看到：
The Ethereal package has been configured with the following options.
                    Build ethereal : no
                   Build tethereal : yes
                    Build capinfos : yes
                     Build editcap : yes
                     Build dumpcap : yes
                    Build mergecap : yes
                   Build text2pcap : yes
                     Build idl2eth : yes
                     Build randpkt : yes
                      Build dftest : yes

显然Build ethereal : no。网上的理由是：GTK+版本安装不当。从configure日志看到：
checking for GTK+ – version >= 2.0.0… no
*** Could not run GTK+ test program, checking why…
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GTK+ is incorrectly installed.

这时只能重新检查GTK+，甚至是重新安装GTK+。

搞定这个后，再重新configure，注意别忘了备份上述对Makefile的修改，否则configure会覆盖你的成果。之后的工作这里就不说了。

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

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

计算机，毫无疑问是一部机器，在最初我们接触计算机时或者接收计算机教育时，我们就知道：计算机能识别的只有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，自己平时很少会去实现一个编码转换。学习以上知识只是为了让自己再遇到乱码问题的时候不再迷糊，而且对计算机字符编码知识有一个概念上的了解是必要的且大有裨益的。