Tomcat内核之ASCII解码的表驱动模式

我们知道Tomcat通信是建立在Socket的基础上，而套接字在服务器端和客户端传递的报文都是未经过编码的字节流，每8位组成1个字节，计算机以二进制为基础，这是由于使用晶体管的开合状态表示1和0，这样8个电晶体管就可以组成一个字节，这正是应用层使用的最小单位——字节。

在通过Socket进行网络通信的程序中，假如我们在接收到报文时不知道通过什么编码才能正确解码，最好的办法就是用Socket最底层的输入装置读取字节流，在确认编码后再对这些字节流进行转码，否则产生解码错误。我们常见的编码有ASCII、GB2312、UNICODE、UTF-8等等，除此之外还有很多其他编码，为什么会有这么多不同的编码？

ASCII编码即个字符已经完全满足使用英语的美国人，英语单词可以通过拆分成字母后用ASCII码表示。

则表示ASCII，如果两个大于127的字节连在一起则表示汉字，而且两个字节的值都在一定的范围内。经过一轮扩展后已经基本解决汉字编码不足问题。

再后来很多国家都按自己规定给自己的文字编码，对其他国家的编码一概不认识，情况一度混乱。接着国际标准化组织推出UNICODE编码，它要把全世界所有文字符号都包括进来，使用两个字节16位对所有字符进行编码，同时为了保证兼容ASCII码，低七位仍用于表示ASCII码原来的字符。通过UNICODE确实是把世界所有字符都统一起来了。

UNICODE编码虽然统一了所有字符，但还存在一个问题，如果是英文字符其实用一个字节已经足够，但使用UNICODE却必须要搭上另外一个毫无意义的字节，在网络传输过程中则意味着要多传输一倍无用的报文。于是引入UTF-8编码，它属于UNICODE的一种实现，它是一种变长的编码方式，在UTF-8规定的实现下可以用一个字节表示ASCII码表示的所有字符，避免了多余的空间浪费。

出了上面几种常见的编码，还有很多其他编码，不同编码指定的规则也不同，但基本都对ASCII做了兼容处理，可以说ASCII是最基础的，这节正是讨论ASCII码解密的常用方法——表驱动模式。

谈到web容器其实就是基于HTTP协议通信建立起两端通信，通过socket实现报文传输，传输过程肯定设计编码的约定，如果没有一个约定将导致消息解码错误。HTTP报文包括三部分：请求行、请求头和请求体（详细可参加前面HTTP协议章节），HTTP协议约定请求行和请求头必须用ASCII编码，这样才能把所有基于HTTP协议通信服务器统一起来，以免造成不同系统默认编码带来混乱。Tomcat接收到ASCII编码的报文，因为ASCII码长度为1字节（8位），java的byte长度也是1字节，两者刚好符合，所以在java中套接字接收到的报文是使用字节类型的数组进行缓冲存储。一般而言，我们比较关心ASCII码向数字、字母及几个特殊符号的解码，通过他们已经足以组成常用的词语语句。如下表，ASCII码中48-57分别表示数字0-9，65-90分别代表A-Z，97-122分别代表a-z。

在解码的过程涉及一些逻辑处理，例如解码后是否为英语字母、是大写还是小写、是否为数字、是否为空白符、转换为其他类型、大小写转换等等。我们惯用的办法是直接用if-else进行判断，如要判断一个ASCII编码是否为英语字母就判断编码是否在65到90、97到122之间，而表驱动思想则不是这样做，它把一张是否为英语字母的结果表放在内存，如下图所示，数组中标为t的表示是英语字母，数组的值即是结果。

类似地，根据其他需求可以在内存中存放更多张表，把判断的逻辑结果事先算好，直接获取数组值便是需要的结果。表驱动模式经常被用于取代很多if-else、switch-case逻辑判断语句中，它的使用有利于提高代码的可读性和维护性。Tomcat使用的ASCII表驱动类为org.apache.tomcat.util.buf.Ascii.java。

喜欢研究java的同学可以交个朋友，下面是本人的微信号：