我们知道Tomcat通信是建立在Socket的基础上，而套接字在服务器端和客户端传递的报文都是未经过编码的字节流，每8位组成1个字节，计算机以二进制为基础，这是由于使用晶体管的开合状态表示1和0，这样8个电晶体管就可以组成一个字节，这正是应用层使用的最小单位——字节。
在通过Socket进行网络通信的程序中，假如我们在接收到报文时不知道通过什么编码才能正确解码，最好的办法就是用Socket最底层的输入装置读取字节流，在确认编码后再对这些字节流进行转码，否则产生解码错误。我们常见的编码有ASCII、GB2312、UNICODE、UTF-8等等，除此之外还有很多其他编码，为什么会有这么多不同的编码？
ASCII编码即American Standard Code for Information Interchange，作为美国标准信息交换编码，并且计算机刚开始只在美国流行，所以当时所有的计算机都使用ASCII编码，ASCII编码是由8比特组成，从0到127分别用于表示不同的字符，包括各种符号、英语字母、阿拉伯数字等，由于128种字符只需7位即可完成编码，所以最高位被0填充。这128个字符已经完全满足使用英语的美国人，英语单词可以通过拆分成字母后用ASCII码表示。
后来随着计算机的迅速发展，其他国家相继引入计算机，他们发现这些编码根本不够对他们本国文字编码，ASCII码一共8位，最多也只能表示256个字符，于是他们对最高位做文章，其中0-127已经被美国使用并成为标准，为了兼容考虑肯定不能改动，剩下128-255可供使用，但很快剩下的128个编码又被用完，现在唯一能做的就是使用两个甚至更多个字节来表示一个字符，每个国家都有自己的规定，于是中国编制了GB2312编码，为了兼容ASCII，它规定一个字节如果小于等于127则表示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。