编码问题原理及漏洞解析

原创： 4ct10n 合天智汇

0x00 简介

前一段时间一直想解决一下字符编码问题，从而研究了Python (Python2.7版本)、PHP、MYSQL等在字符编码方面的原理，从根本上理解编码问题产生的根源，以及一些有效的解决办法。本文打算从两大部分出发分别介绍各个语言在编码上的处理机制，以及由编码问题造成的漏洞。

总的来说字符编码问题可以归结为以下几点

1、以错误的方式解析字符编码

2、在编码转化时被转化的编码没有相应的值

3、在编码转化时没有相应的值与被转化的编码对应

简单介绍几种方式

UTF-8

UTF-8是一种变长字节编码方式。对于某一个字符的UTF-8编码，如果只有一个字节则其最高二进制位为0；如果是多字节，其第一个字节从最高位开始，连续的二进制位值为1的个数决定了其编码的位数，其余各字节均以10开头。UTF-8最多可用到6个字节。

如表：

1字节 0xxxxxxx

2字节 110xxxxx 10xxxxxx

3字节 1110xxxx 10xxxxxx 10xxxxxx

4字节 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

5字节 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

6字节 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

GBK

专门为解决汉字的编码而生成的解决方案

GBK的中文编码是双字节来表示的，英文用单字节表示，但GBK编码表中也有英文字符的双字节表示形式，所以英文字母可以有2种GBK表示方式。为区分中文，将其最高位都定成1。英文单字节最高位都为0。

0x01 Python&PHP&MYSQL编码问题

Python

整体分为三大部分，从存储、解析到显示。python里string object和unicode object是两种不同的类型，string里的character是有多种编码方式的，比如单字节的ASCII，双字节的GB2312等等，再比如UTF-8。很明显要想解读string，必需知道string里的character是用哪种编码方式，然后才能进行。

Python文档编码

Python解析器从文本中解析代码，需要知道文档的编码方式一般在文档开头

# coding:utf-8# -*- coding:utf-8 -*-

例如：

# encoding:utf-8print "?"

此时文档应当按照utf-8编码存储，因为Python 解析器会以utf-8的格式读取存储在磁盘上的二进制，如果存储格式有误就会出现解析错误。例如下面报错信息

SyntaxError: Non-ASCII character '\\xe5' in file F:\code\python\2.py on line 4, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

Python 解析器默认以ascii进行解析，'\\xe5'超出ascii编码范围，因此解析错误。

另一种改变python 解析器的默认解析编码为使用UTF-8-BOM进行存储。

不用使用头部注释即可解析中文字符编码，利用hexdump工具可以看出其中的文件头有三个标志字符ef bb bf

至此Python加载文件的编码操作已经结束，下面就是在Python解析器中的操作，可以说是在内存中的操作。

Python解析器编码

由前面的介绍可以了解到Python中的字符类型分为string 和 unicode，其中string 又包括了gbk、utf-8等各种编码。他们之间的转化通过encode和decode进行

>>> a = '啊'>>> a'\\xb0\\xa1'>>> a.decode('gbk')u'\\u554a'>>> a.decode('gbk').encode('utf-8')'\\xe5\\x95\\x8a'

因为终端使用的是gbk编码，所以啊的编码为'\\xb0\\xa1' 以gbk编码格式进行解析，解析成unicode编码，再使用encode编码方式编码成utf-8。

在这里需要再次强调一下Python string的默认编码方式 ascii形式，也就是说在不指定string编码方式的情况下默认以ascii进行解析，因此会造成很多编码问题。

比如下面两个例子，正好将encode和decode函数都有讲解到

Python 写入字符串到文件

这里只针对py2,

write方法的参数类型是str，str是二进制流（不包含编码信息），当给出一个unicode对象时，会执行str函数转换成str类型再送给write方法。unicode转str包含一次编码，如不指定则默认使用ascii编

看下面的错误

# coding:utf-8a = u'啊'f = open('./111','a')

f.write(a)

Traceback (most recent call last):

File "F:\code\python\2.py", line 4, in

f.write(a)

UnicodeEncodeError: 'ascii' codec can't encode character u'\\u554a' in position 0: ordinal not in range(128)

这里产生错误的原因是，unicode首先要encode转化为ascii编码，显然有很多字节是对不上号的，这里的解决方法有两个，其一是改变其默认编码使用下面代码

# coding:utf-8import sys

reload(sys)

sys.setdefaultencoding('utf-8')

a = u'啊'f = open('./111','a')

f.write(a)

其二将unicode转换为其他编码过后再次存入文件

# coding:utf-8a = u'啊'f = open('./111','a')

f.write(a.encode('gbk'))

绕过unicode直接进行编码转化

首先看下下面代码

>>> a = '啊'>>> print a.encode('utf-8')

Traceback (most recent call last):

File "", line 1, in

UnicodeDecodeError: 'ascii' codec can't decode byte 0xb0 in position 0: ordinal not in range(128)

a原本为gbk编码，如果直接进行encode那么首先会转换编码为unicode格式，因为默认解析格式为ascii所以在ascii转换成unicode编码时会产生以上错误。那么这时可以改变默认编码

# coding:utf-8import sys

reload(sys)

sys.setdefaultencoding('utf-8')

a = '啊'print a.encode('utf-8')

成功解决该类编码问题

终端显示编码

在第二小节的图示中最后一个环节，是终端编码的问题。

问题一般出在交给操作系统的字符编码与终端显示编码有所差别。

在windows cmd终端采用的gbk编码

如果使用utf-8编码就会出现乱码

在linux 终端下采用的是utf-8编码形式![enter description here](./attachments/Little CMS.md "Little CMS")如果使用gbk编码就会出现乱码

PHP

加载

PHP编码相对 Python而言简单了许多，PHP直接使用ascii进行单字节解析，也就是说不论文件采用什么编码，PHP在解析是总是按字节处理，如下面例子：

该PHP脚本采用gbk编码方式编码，"?" 字的字节码为"D55c" 5c为\使得PHP解析错误。

显示

PHP以及HTML脚本可以指定显示在浏览器上的编码方式

header("content-type:text/html;charset=utf-8")

MYSQL

编码过程

mysql 编码数据比较复杂，大体上可以分为以下几个

1、character_set_client

2、character_set_connection

3、character_set_results

4、数据字段存储

character_set_client

无论客户端传递的是什么编码的数据，服务器都当成该编码来处理，例如该编码为UTF8，那么如果客户端发送过来的数据不是UTF8，那么就会出现乱码；

character_set_connection

connection 可以说是在SQL语句执行时的编码，当执行的是查询语句时，客户端发送过来的数据会先转换成connection指定的编码。但只要客户端发送过来的数据与client指定的编码一致，那么转换就不会出现问题；

数据字段存储

当insert数据时需要将数据存储在数据库中，这里就涉及到编码转化，当没用找到对应关系时就会令该位置字符为3F ，这也是数据库中乱码中3F出现的原因。

character_set_results

当select从数据库中取出时以前的编码要变为character_set_results设置的编码。

整个流程可参照下图：

从查询到取出整个流程经历了三次编码转换，每次转换都有可能产生编码问题。client编码指定了用户输入的编码格式，connection按照此编码格式将编码转化为connection指定的编码，然后再将编码转化为存储格式。当有查询操作时再将取出的数据按照results格式转化。

这里盗用一张图

验证原理

设计以下实验

实验一（验证数据存储时的转换）

写一个数据库交互的代码，在前端使用GBK编码方式插入数据，character_set_client设置为GBK，character_set_connection设置为GBK，数据存储设置为utf8，查看最后的存储字节为E8AAA0为正确的utf8编码

http://127.0.0.1/1.php?a=%d5%5c$conn->query("SET character_set_client = gbk"); $conn->query("SET character_set_connection = gbk"); ALTER TABLE `yz` CHANGE `a` `a` TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;

实验二（验证client到connection的转换）

在前端使用GBK编码方式插入数据，character_set_client设置为GBK，character_set_connection设置为utf8，数据存储设置为utf8，查看最后的存储字节为E8AAA0为正确的uft8编码

http://127.0.0.1/1.php?a=%d5%5c$conn->query("SET character_set_client = gbk"); $conn->query("SET character_set_connection = utf8"); ALTER TABLE `yz` CHANGE `a` `a` TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;

实验三（验证数据存储到取出的显示的转换）

将以utf8编码存储的内容用gbk格式取出

http://127.0.0.1/1.php?a=%d5%5c$conn->query("SET character_set_client = gbk"); $conn->query("SET character_set_connection = utf8"); $conn->query("SET character_set_results = gbk"); ALTER TABLE `yz` CHANGE `a` `a` TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;

成功转化为gbk格式，没有乱码出现enter code here