分析wireshark中无法正确显示字符的原因

       本文是我早期的一些理解记录,其中有的地方可能理解的并不是很准确,我将这些年最新的一些理解整理在我的专栏《wireshark从入门到精通》中,欢迎查看,这里
       我们知道wireshark所抓的是经过网卡的数据流,也就是原生的二进制码流,在服务器端是什么形式传输,那么wireshark所捕获的就是什么形式,当然wireshark会有默认的显示方式。此次讨论的主要是针对数据部分的内容乱码。因为像HTTP,TCP,IP等头部,首先是英文,也就是无论哪一种编码方式,只要按照ASCII对应的字符集都可以正确的解释;再次头部基本上除了以ASCII进行编码以外,是不进行其他处理的,例如压缩。(但是HTTP2.0引入了头部压缩技术)
       Wireshark中的编解码方式有utf-8,ASCII,HEX等方式,因此我们可以使用这几种方式对所抓到的二进制码流进行解码,以友好的方式进行显示。
       在wireshark中,中文的显示有时候存在着一定的问题。尽管现在wireshark已经有了中文版本,同时也有utf8解码方式,但是中文的显示有的时候却是乱码,就我们看到的�形式或者是.形式,稍后我会提到为什么乱码显示为�或者.,在此之前先分析一下乱码的原因。
       1、 首先可能所抓的字节流编码方式为gbk,big5等方式,而wireshark并没有提供对应的解码方式。对应的是客户端和服务器协商的Accept-Charset以及Content-Type头域。
       2、 当然这些字节流也可能是经过压缩编码的。对应的是客户端和服务器协商的Accept-Encoding以及Content-Encoding头域。
       3、 当然这些字节流也可能是经过传输编码的。对应的是服务器的Transfer-Encoding头域。
       4、 当然这些字节流也可能是经过加密的。
       5、 当然这些字节流是符合某种协议的。但是wireshark不支持的。可以通过wireshark右上角的expression看到,目前wireshark生态圈大概支持了一千多种协议。
       数据流被wireshark捕获的时候,首先按照某种协议进行了解码。比如TCP协议,从Frame->Ethernet->IP->TCP一层层进行解码,这些是基础的协议部分。对于情况2的gzip编码,情况3的chunk编码,wireshark都有默认的支持,都会有解压缩和报文重组的功能,不会导致乱码问题。但是对于情况1,编码方式由多种,wireshark无法全面提供,是常见的乱码。对于情况4,需要相应的密钥进行解密,在这里这里分别整理了手机和浏览器进行解密的方法。对于情况5,大多数是一些私有协议,就不再讨论。
       前面遗留的一个问题就是�和.的问题。�是会在utf-8的时候出现,utf-8对于无法识别的数据流,会使用�表示,同时�编码为0xFFFD。因此如果一个文件使用utf-8格式存储,其中出现了�字符,由于其表示为0xFFFD,因此在转换为其他编码格式,比如gbk,往往还是乱码。在ASCII码中,无法识别的字符会使用.表示。
       上面我们是在数据层面讨论的可能导致乱码的问题,其实在显示的时候可能也会出现毛病。当然现代的计算机字体库比较全面,这类情况较少,但是还是简单说一下。
       大家都编辑过word,而word是可以选择宋体,还是times new roman等字体格式来显示的。同样的道理,那wireshark默认的显示字体是什么呢?
       在说wireshark的默认字体之前,看看浏览器是如何显示网页的。浏览器在对所接受的数据进行解析后,比如将数据流中的中文都进行了utf8解码后,会调用本身的渲染引擎来让这些汉字以各种样式来显示出来。比如网页中规定了font为楷体,则渲染引擎会调用操作系统的楷体字库,完成楷体中文字符的显示。如果系统中没有楷体字库,就会调用默认的字库显示。
       对于word和wireshark这样的软件同理,根据设定的字体,调用相应的字体库。wireshark默认字体是consolas,这个字体库是可以显示中文字体的。但是如果选择不支持中文字体的字库,有可能就显示不了了。
       以上就是近期在解决乱码问题时候,突然冒出来的想法,做了粗浅的记录。
       本文为CSDN村中少年原创文章,转载记得加上小尾巴偶,博主链接这里

    原文作者:村中少年
    原文地址: https://blog.csdn.net/javajiawei/article/details/70255880
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞