常见编码及乱码的处理

常见编码及乱码的处理

本文解决的问题

• 编码是什么
• 字符是什么
• 字符集是什么
• 编码用在哪
• 我们常出现的错误（乱码）
• 怎么正确的使用编码

前言

我们日常接触到的文件分ASCII是“美国信息交换标准编码”的英文字头缩写，可称之为“美标”。美标规定了用从0到127的128个数字来代表信息的规范编码，其中包括33个控制码，一个空格码，和94个形象码。形象码中包括了英文大小写字母，阿拉伯数字，标点符号等。我们平时阅读的英文电脑文本，就是以形象码的方式传递和存储的。美标是国际上大部分大小电脑的通用编码。

然而电脑中的一个字符大都是用一个八位数的二进制数字表示。这样就有256个不同的数值，可以用来表示256个不同的字符。由于美标只规定了128个编码，剩下的另外128个数码没有规范，各家用法不一。另外美标中的33个控制码，各厂家用法也不尽一致。这样我们在不同电脑间交换文件的时候，就有必要区分两类不同的文件。第一类文件中每一个字都是美标形象码或空格码。这类文件称为“美标文本文件”(ASCII Text Files)，或略为“文本文件”，通常可在不同电脑系统间直接交换。第二类文件，也就是含有控制码或非美标码的文件，通常不能在不同电脑系统间直接交换。这类文件有一个通称，叫“二进制文件”(Binary Files)。

本文讨论的内容只在可读文本即ASCII系列

一、字符集与编码

1、字符集简介

**字符(Character)**是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。
**字符集(Character set)**是多个字符的集合，字符集种类较多，每个字符集包含的字符个数不同，常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、 GB18030字符集、Unicode字符集等。计算机要准确的处理各种字符集文字，需要进行字符编码，以便计算机能够识别和存储各种文字。

**字符编码（Character encoding）**是把字符集中的某个字符编码为指定字符集中字符，以便文本在计算机中存储和通过通信网络的传递。常见的例子包括将拉丁字母表编码成ASCII，ASCII将字母、数字和其它符号编号，并用7比特的二进制来表示。

**字符序 (collation)**是指同一个字符集内字符之间的比较规则。只有确定字符序后，才能在一个字符集上定义什么是等价的字符，以及字符之间的大小关系。一个字符可以包含多种字符序。MySQL字符序命名规则是：以字符序对应的字符集名称开头，以国家名居中(或以general居中)，以ci、cs、或bin结尾。以ci结尾的字符序表示大小写不敏感，以cs结尾的字符序表示大小写敏感，以bin结尾的字符序表示按二进制编码值比较。

2、ASCII编码

ASCII既是编码字符集，又是字符编码，ASCII直接将字符在编码字符集中的序号作为字符在计算机中存储从数值。
例如：在ASCII中A字符在表中排第65位，序号是65，而编码后A的数值是0100 0001，即十进制的65的二进制转换结果。

3、Latin1字符集

Latin1字符集在ASCII字符集基础上进行了扩展，仍然使用一个字节表示字符，但启用了高位，扩展了字符集的表示范围。

4、UTF-8编码

UTF-8（8-bit Unicode Transformation Format）是一种针对Unicode的可变长度字符编码，又称万国码。由Ken Thompson于1992年创建。现在已经标准化为RFC 3629。UTF-8用1到6个字节编码Unicode字符。
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
因此UTF-8中可以用来表示字符编码的实际位数最多有31位，即上表中x所表示的位。除去控制位（每字节开头的10等），x表示的位与UNICODE编码是一一对应的，位高低顺序也相同。
实际将UNICODE转换为UTF-8编码时应先去除高位0，然后根据所剩编码的位数决定所需最小的UTF-8编码位数。 因此基本ASCII字符集中的字符（UNICODE兼容ASCII）只需要一个字节的UTF-8编码（7个二进制位）便可以表示。

5、字符集兼容性

对于中文字符来说，UTF-8、GBK、GB2312、BIG5四种编码之间是互不兼容的，直接相互转换会导致乱码；当UTF-8、GBK、GB2312、BIG5四种编码转换为ASCII编码和Latin1编码格式时，每个中文字符会被转换为0x3F，即中文字符’？’。
GB2312支持简体中文，BIG5支持繁体中文，GBK支持简体中文及繁体中文，UTF-8支持几乎所有字符。
GBK是国家标准GB2312基础上扩容后兼容GB2312的标准。GB2312是GBK的子集，GBK是GB18030的子集。

GB编码标准中，比较常用的是GB2312和GBK两种，GB2312是GBK的一个子集，GB2312编码范围是 0xA1A1 - 0xFEFE ，如果纯粹的 GB2312编码，处理起来是十分简单的，但处理GBK字符集时有些小的提示，先说说GBK编码的标准吧：

GBK 采用双字节表示，总体编码范围为 8140-FEFE，首字节在 81-FE 之间，尾字节在 40-FE 之间，剔除 xx7F 一条线。总计 23940 个码位，共收入 21886 个汉字和图形符号，其中汉字（包括部首和构件）21003 个，图形符号 883 个。

6、文件编码从哪看？

以notepad++ 为例

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6en5xDiL-1574241894791)(https://i.loli.net/2019/11/12/kxESrPKRHlXATBY.png)]

我们打开一个文本文件

一般默认会指定一个正确的编码去读

如果我们以二进制的方式打开文件

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fksApxjd-1574241894792)(https://i.loli.net/2019/11/12/aTyPWf2QOJcnrAx.png)]

ASCII码表

二进制	十进制	十六进制	缩写	名称/意义
0000 0000	0	0	NUL	空字符（Null）
0000 0001	1	1	SOH	标题开始
0000 0010	2	2	STX	本文开始
0000 0011	3	3	ETX	本文结束
0000 0100	4	4	EOT	传输结束
0000 0101	5	5	ENQ	请求
0000 0110	6	6	ACK	确认回应
0000 0111	7	7	BEL	响铃
0000 1000	8	8	BS	退格
0000 1001	9	9	HT	水平定位符号
0000 1010	10	0A	LF	换行键
0000 1011	11	0B	VT	垂直定位符号
0000 1100	12	0C	FF	换页键
0000 1101	13	0D	CR	归位键
0000 1110	14	0E	SO	取消变换（Shift out）
0000 1111	15	0F	SI	启用变换（Shift in）
0001 0000	16	10	DLE	跳出数据通讯
0001 0001	17	11	DC1	设备控制一（XON 启用软件速度控制）
0001 0010	18	12	DC2	设备控制二
0001 0011	19	13	DC3	设备控制三（XOFF 停用软件速度控制）
0001 0100	20	14	DC4	设备控制四
0001 0101	21	15	NAK	确认失败回应
0001 0110	22	16	SYN	同步用暂停
0001 0111	23	17	ETB	区块传输结束
0001 1000	24	18	CAN	取消
0001 1001	25	19	EM	连接介质中断
0001 1010	26	1A	SUB	替换
0001 1011	27	1B	ESC	跳出
0001 1100	28	1C	FS	文件分割符
0001 1101	29	1D	GS	组群分隔符
0001 1110	30	1E	RS	记录分隔符
0001 1111	31	1F	US	单元分隔符
0111 1111	127	7F	DEL	删除

二进制	十进制	十六进制	图形
0010 0000	32	20	（空格）(␠)
0010 0001	33	21	!
0010 0010	34	22	"
0010 0011	35	23	#
0010 0100	36	24	$
0010 0101	37	25	%
0010 0110	38	26	&
0010 0111	39	27	’
0010 1000	40	28	(
0010 1001	41	29	)
0010 1010	42	2A	*
0010 1011	43	2B	+
0010 1100	44	2C	,
0010 1101	45	2D	-
0010 1110	46	2E	.
0010 1111	47	2F	/
0011 0000	48	30	0
0011 0001	49	31	1
0011 0010	50	32	2
0011 0011	51	33	3
0011 0100	52	34	4
0011 0101	53	35	5
0011 0110	54	36	6
0011 0111	55	37	7
0011 1000	56	38	8
0011 1001	57	39	9
0011 1010	58	3A	:
0011 1011	59	3B	;
0011 1100	60	3C	<
0011 1101	61	3D	=
0011 1110	62	3E	>
0011 1111	63	3F	?
0100 0000	64	40	@
0100 0001	65	41	A
0100 0010	66	42	B
0100 0011	67	43	C
0100 0100	68	44	D
0100 0101	69	45	E
0100 0110	70	46	F
0100 0111	71	47	G
0100 1000	72	48	H
0100 1001	73	49	I
0100 1010	74	4A	J
0100 1011	75	4B	K
0100 1100	76	4C	L
0100 1101	77	4D	M
0100 1110	78	4E	N
0100 1111	79	4F	O
0101 0000	80	50	P
0101 0001	81	51	Q
0101 0010	82	52	R
0101 0011	83	53	S
0101 0100	84	54	T
0101 0101	85	55	U
0101 0110	86	56	V
0101 0111	87	57	W
0101 1000	88	58	X
0101 1001	89	59	Y
0101 1010	90	5A	Z
0101 1011	91	5B	[
0101 1100	92	5C	\
0101 1101	93	5D	]
0101 1110	94	5E	^
0101 1111	95	5F	_
0110 0000	96	60	`
0110 0001	97	61	a
0110 0010	98	62	b
0110 0011	99	63	c
0110 0100	100	64	d
0110 0101	101	65	e
0110 0110	102	66	f
0110 0111	103	67	g
0110 1000	104	68	h
0110 1001	105	69	i
0110 1010	106	6A	j
0110 1011	107	6B	k
0110 1100	108	6C	l
0110 1101	109	6D	m
0110 1110	110	6E	n
0110 1111	111	6F	o
0111 0000	112	70	p
0111 0001	113	71	q
0111 0010	114	72	r
0111 0011	115	73	s
0111 0100	116	74	t
0111 0101	117	75	u
0111 0110	118	76	v
0111 0111	119	77	w
0111 1000	120	78	x
0111 1001	121	79	y
0111 1010	122	7A	z
0111 1011	123	7B	{
0111 1100	124	7C	|
0111 1101	125	7D	}
0111 1110	126	7E	~

二、乱码

1、文件乱码

当使用编辑器打开文本文件时（如：txt、jsp、HTML、java、js、css……）发生乱码，可能是由于打开时使用了错误的字符集

如下

解决方案

切换正确的字符集即可

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8yTMZYue-1574241894793)(https://i.loli.net/2019/11/13/EPZtvHOQzVI7Yum.png)]

也存在一种可能，文本写入时即发生乱码写入了错误的字符。此种方式不可逆，基本无法还原。所以，写入文本时一定确保写入的内容编码正确

2、HTML乱码

检查浏览器使用的编码

查看源文件指定的字符集为UTF-8

指定浏览器编码

** 解决方案**

开发时HTML在<meta>中明确指定字符集

3、JSP乱码

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        ...
    </head>
    ...
</html>

JSP在部署后提供给用户使用，会经过三个阶段：

1. JSP生成java文件：这个阶段会使用pageEncoding所定义的编码格式进行转换
2. java文件生成class文件：这个阶段由服务器tomcat自动使用utf-8编码把java文件转换成字节码class文件
3. 通过读取class文件展现给用户：这个阶段由tomcat服务器获取字节码内容，通过使用contentType所定义的编码格式展现给用户

解决方案

请在各个环节指定正确的字符集，最好全部指定utf-8

4、GET,POST请求乱码

form表单有两种方法把数据提交给服务器:

1）get提交

get请求时，在前端URIEncode编码两次；

容器接收时，默认ISO-8859-1解码一次；

手动再解码一次。

前端：

url1=encodeURI(url);   
url2=encodeURI(url1);

后台：

String name1=request.getParameter("name");   
String name2 = java.net.URLDecoder.decode(name1,"UTF-8"); 

不管容器用的什么编码，都不会有乱码：

url1会把url中的中文编为ASCII码。

url2对url1进行再编码，由于是对ASCII码进行编码，在request.getParameter(“name”)解码的时候，不管是按 GBK 还是 UTF-8 还是 ISO-8859-1 都好，都能够正确的得到url1。

因为ASCII码用GBK、UTF-8、ISO-8859-1编码的结果是相同的。

​ 首先说下客户端（浏览器）的form表单用get方法是如何将数据编码后提交给服务器端的。

​ 对于get方法来说，都是把数据串联在请求的url后面作为参数，如：http://localhost:8080/servlet?msg=abc（很常见的一个乱码问题就要出现了，如果url中出现中文或其它特殊字符的话，如：http://localhost:8080/ /servlet?msg=南京，服务器端容易得到乱码），url拼接完成后，浏览器会对url进行URL encode，然后发送给服务器，URL encode的过程就是把部分url做为字符，按照某种编码方式（如：utf-8,gbk等）编码成二进制的字节码，然后每个字节用一个包含3个字符的字符串 “%xy” 表示，其中xy为该字节的两位十六进制表示形式。具体介绍可以看下java.net.URLEncoder类的介绍。

​ 了解了 URL encode的过程，我们能看到2个很重要的问题：

​ 第一：需要URL encode的字符一般都是非ASCII的字符（笼统的讲），再通俗的讲就是除了英文字母以外的文字（如：中文，日文等）都要进行URL encode，所以对于我们来说，都是英文字母的url不会出现服务器得到乱码问题，出现乱码都是url里面带了中文或特殊字符造成的；

​ 第二：URL encode到底按照那种编码方式对字符编码？这里就是浏览器的事情了，而且不同的浏览器有不同的做法，中文版的浏览器一般会默认的使用GBK，通过设置浏览器也可以使用UTF-8，可能不同的用户就有不同的浏览器设置，也就造成不同的编码方式，所以很多网站的做法都是先把url里面的中文或特殊字符用 javascript做URL encode，然后再拼接url提交数据，也就是替浏览器做了URL encode，好处就是网站可以统一get方法提交数据的编码方式。 完成了URL encode，那么现在的url就成了ASCII范围内的字符了，然后以iso-8859-1的编码方式转换成二进制随着请求头一起发送出去。这里想多说几句的是，对于get方法来说，没有请求实体，含有数据的url都在请求头里面，之所以用URL encode，我个人觉的原因是：对于请求头来说最终都是要用iso-8859-1编码方式编码成二进制的101010…的纯数据在互联网上传送，如果直接将含有中文等特殊字符做iso-8859-1编码会丢失信息，所以先做URL encode是有必要的。
服务器端（tomcat）是如何将数据获取到进行解码的。
第一步是先把数据用iso-8859-1进行解码，对于get方法来说，tomcat获取数据的是ASCII范围内的请求头字符，其中的请求url里面带有参数数据，如果参数中有中文等特殊字符，那么目前还是URL encode后的%XY状态，先停下，我们先说下开发人员一般获取数据的过程。通常大家都是request.getParameter(“name”)获取参数数据，我们在request对象或得的数据都是经过解码过的，而解码过程中程序里是无法指定，这里要说下，有很多新手说用 request.setCharacterEncoding(“字符集”)可以指定解码方式，其实是不可以的，看servlet的官方API说明有对此方法的解释：Overrides the name of the character encoding used in the body of this request. This method must be called prior to reading request parameters or reading input using getReader().可以看出对于get方法他是无能为力的。那么到底用什么编码方式解码数据的呢，这是tomcat的事情了，默认缺省用的是 iso-8859-1,这样我们就能找到为什么get请求带中文参数为什么在服务器端得到乱码了，原因是在客户端一般都是用UTF-8或GBK对数据 URL encode，这里用iso-8859-1方式URL decoder显然不行，在程序里我们可以直接

Java代码

new String(request.getParameter("name").getBytes("iso-8859-1"),"客户端指定的URL encode编码方式")

还原回字节码，然后用正确的方式解码数据，通常是在tomcat里面做个配置
Xml代码

<Connector port="8080" protocol="HTTP/1.1" maxThreads="150" connectionTimeout="20000" redirectPort="8443" URIEncoding="GBK"/>

这样是让tomcat在获取数据后用指定的方式URL decoder，URL decoder的介绍在这里

http://blog.csdn.net/vickyway/article/details/46375971

http://www.jb51.net/article/80181.htm

2）post提交

客户端（浏览器）的form表单用post方法是如何将数据编码后提交给服务器端的。
在post方法里所要传送的数据也要URL encode，那么他是用什么编码方式的呢？
在form所在的html文件里如果有段<meta http-equiv="Content-Type" content="text/html; charset=字符集（GBK，utf-8等）"/>，那么post就会用此处指定的编码方式编码。一般大家都认为这段代码是为了让浏览器知道用什么字符集来对网页解释，所以网站都会把它放在html代码的最前端，尽量不出现乱码，其实它还有个作用就是指定form表单的post方法提交数据的 URL encode编码方式。从这里可以看出对于get方法来数，浏览器对数据的URL encode的编码方式是有浏览器设置来决定，（可以用js做统一指定），而post方法，开发人员可以指定。
服务器端（tomcat）是如何将数据获取到进行解码的。
如果用tomcat默认缺省设置，也没做过滤器等编码设置，那么他也是用iso-8859-1解码的，但是request.setCharacterEncoding("字符集")可以派上用场。

我发现上面说的tomcat所做的事情前提都是在请求头里没有指定编码方式，如果请求头里指定了编码方式将按照这种方式编码。
有2篇文章推荐下，地址分别是
深入浅出URL编码：http://www.cnblogs.com/yencain/articles/1321386.html；
表单用post方法提交数据时乱码问题：http://wanghuan8086.javaeye.com/blog/173869

用post很重要的在form所在的html文件里如果有段<meta http-equiv="Content-Type" content="text/html; charset=字符集（GBK，utf-8等）"/>
强烈建议使用post提交

也可以通过base64编码传输，服务端base64解码拿到正确的字符

5、URL包含特殊字符

在HTTP请求时会遇到以下几种情况：

1. 当字符串数据以url的形式传递给web服务器时，字符串中是不允许出现空格和特殊字符串的
2. url对字符有限制，比如把一个邮箱放入url，就需要使用urlencode函数。
3. url转义其实也只是为了符合url的规范而已。因为在标准的url规范中中文和很多的字符是不允许出现在url中的。

解决方案

使用 urlencode (上文已介绍过)

java：

java.net.URLEncoder.encode("要转码的内容","UTF-8"); // 原来单参数方法已经过时。

javaScript:

encodeURI()

6、数据库乱码

1、MySQL环境变量

Session会话变量：
使用show variables like '%char%';可以查看Session会话的字符集变量：

set character_set_server=utf8;
set character_set_database=utf8;
使用SET可以设置不同字符集。但是使用SET设置的字符集都是Session会话级别的，如果新打开一个会话，新会话使用的是默认的字符集。
Global全局变量：
使用show global variables like '%char%';可以查看Global的字符集变量：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZLuomhT7-1574241894801)(https://i.loli.net/2019/11/12/AiQSf3M6umIK82O.png)]

set global character_set_database=utf8;
set global character_set_server=utf8;
使用SET GLOBAL可以设置多个会话的字符集。
使用show charset;查看MySQL支持的字符集和对应字符集的字符序。
MySQL服务重启后，Global的值会被重置为默认值。永久修改Global的值的方法如下：
修改mysql配置文件/etc/my.cnf。

[mysqld]
character-set-server=utf8
[client]
default-character-set=utf8
[mysql]
default-character-set=utf8

2、MySQL字符集

MySQL服务器可以支持多种字符集，提供了不同级别的设置，包括server级、database级、table级、column级。
MySQL数据库的环境变量查看使用SQL语句show variables like '%char%';
character_set_client：客户端使用的字符集，当客户端向服务器发送请求时，请求以客户端字符集进行编码。
character_set_connection ：客户端/数据库建立的通信连接使用的字符集，MySQL服务器接收客户端的查询请求后，将其转换为character_set_connection变量指定的字符集。
character_set_database：数据库服务器中某个数据库的字符集，如果没有默认数据库字符集，使用 character_set_server指定的字符集。
character_set_results：数据库给客户端返回时的字符集，MySQL数据库把结果集和错误信息转换为character_set_results指定的字符集，并发送给客户端。
character_set_server：数据库服务器的字符集，内部操作字符集。
character_set_system：系统元数据（字段名等）使用的字符集
当客户端连接服务器的时候，客户端会将自己想要的字符集名称发给MySQL服务端，然后服务端就会使用字符集去设置character_set_connection、character_set_client、character_set_results。
创建数据库时如果不指定数据库的字符集，默认会使用character_set_server字符集。
创建表时如果不指定表的字符集，默认使用当前数据库字符集。
创建列时如果不指定字符集，默认使用当前表的字符集。

3、MySQL字符集的设置

A、MySQL服务器级字符集
修改MySQL服务器配置文件/etc/my.cnf文件。

[mysqld]
character_set_server=utf8

重启MySQL数据库服务生效。
B、MySQL数据库级字符集：
创建数据库时指定：

CREATE DATABASE db_name
[[DEFAULT] CHARACTER SET charset_name]
[[DEFAULT] COLLATE collation_name]

修改已有的数据库的字符集：

ALTER DATABASE db_name
[[DEFAULT] CHARACTER SET charset_name]
[[DEFAULT] COLLATE collation_name]

ALTER修改只对修改后在数据库上的操作有效。
C、MySQL表级字符集：
创建表时指定：

CREATE TABLE tbl_name (column_list)
[[DEFAULT] CHARACTER SET charset_name]
[COLLATE collation_name]]

修改表的字符集：

ALTER TABLE tbl_name
[[DEFAULT] CHARACTER SET charset_name]
[COLLATE collation_name]

D、MySQL字段级字符集：
修改已有字段的字符集：

ALTER TABLE table_name MODIFY
column_name {CHAR | VARCHAR | TEXT} (column_length)
  [CHARACTER SET charset_name]
  [COLLATE collation_name]

MySQL客户端设置：set names utf8;等价于：
set character_set_client=utf8;
set character_set_connection=utf8;
set character_set_results=utf8;
E、客户端字符集
修改MySQL服务器配置文件/etc/my.cnf文件。

[client]
default-character-set=utf8

等价于set names utf8;
会影响会话中的变量character_set_client，character_set_connection 和character_set_results的值。
修改后无需重启MySQL数据库服务即可生效。

4、MySQL字符集的转换过程

A、MySQL服务端收到请求时将请求数据从character_set_client字符集转换为character_set_connection字符集。
B、进行内部操作前将请求数据从character_set_connection字符集转换为内部操作字符集。确定步骤：
–使用每个数据字段的CHARACTER SET设定值；
–若上述值不存在，则使用对应数据表的DEFAULT CHARACTER SET设定值；
–若上述值不存在，则使用对应数据库的DEFAULT CHARACTER SET设定值；
–若上述值不存在，则使用character_set_server字符集设定值；
C、将操作结果从内部操作字符集转换为character_set_results字符集。
D、将character_set_results字符集的执行结果转换为character_set_client字符集，发送到客户端，客户端使用设置的字符集展示结果。

5、MySQL乱码产生的原因

乱码产生的原因如下：
A、存入和取出时对应环节的编码不一致。
B、如果两个字符集之间无法进行无损编码转换，一定会出现乱码。

6、编码无损转换

如果一个使用编码A表示的字符X，转化为编码B的表示形式，而编码B的字符集中并没有X字符，则编码转换是有损的，否则编码转换就是无损的。
由于每个字符集所支持的字符数量是有限的，并且各个字符集涵盖的字符之间存在差异。将UTF-8字符转换为GBK字符时，MySQL内部如果无法在GBK字符集找到一个UTF8字符集中的字符时，就会转换成一个错误标记（0x3F，问号）。
编码无损转换的条件：
A、被转换的字符是否同时在两个字符集中。
B、目标字符集是否能够对不支持字符，保留其原有表达形式。

解决方案

从创建数据库，创建表到连接数据库全部指定统一字符集，并从一而终。

---

©️ 框架组 以上信息如有不足，请斧正 📧 mengfanding@aliyun.com