中文存数据库老是变问号，到底是编码还是啥问题导致的啊

“中文存数据库老是变问号，到底是编码还是啥问题导致的啊”，这个问题可以说是无数程序员，尤其是初学者在接触数据库时几乎必定会踩的一个“大坑”，你绝对不是一个人遇到这个问题，简单直接地说，这个问题九成九就是编码问题，它不是一个bug，而是一个在数据流转过程中，某个环节“语言不通”导致的误会，我们可以把数据从你输入到最终存入数据库再显示出来的过程，想象成一场需要多次翻译的跨国旅行，只要有一个翻译不认识中文字，他就会用“？”来代替他看不懂的东西。

我们得知道“问号”是怎么产生的，问号（？）通常是数据库或程序在遇到无法识别的字符时使用的替换符号，就像你给一个只懂英文的人看一个中文汉字，他看不懂，只好画个问号，关键在于，这个“看不懂”发生在哪个环节，整个流程大致是这样的：你的程序（比如Java、PHP、Python）<- -> 数据库连接器（比如JDBC、ODBC）<- -> 数据库本身（比如MySQL、PostgreSQL）。

第一个最常见的“案发现场”是数据库本身的设置，数据库在创建的时候，就像一个新生的婴儿，你得告诉它，它将来主要要处理什么语言，这就涉及到几个关键设置：字符集和排序规则，字符集好比是一本字典，定义了哪些字符对应哪些数字编号，比如UTF-8这本“超级字典”几乎包含了世界上所有的字符，包括中文、日文、阿拉伯文等等，而像latin1这种“基础字典”主要只包含西欧语言字符，如果你创建数据库或者数据表的时候，选择的字符集是latin1，那么当你试图存入一个中文汉字时，它翻遍latin1这本小字典也找不到这个字对应的编号，于是它就懵了，只好存一个问号上去。确保你的数据库、数据表甚至具体字段的字符集都设置为支持中文的字符集，比如utf8mb4（这是MySQL中真正的全功能UTF-8），而不是latinal或utf8（MySQL早期的utf8有缺陷，不支持部分字符）。

第二个容易出问题的地方是数据库连接，即使你的数据库本身是UTF-8的，但你的程序在连接数据库的时候，也需要“握手”确认一下：“嘿，我们接下来要用什么语言交流？”这个沟通的环节就是连接字符集设置，如果数据库是UTF-8，但你的程序连接时却告诉数据库“我用的是GBK编码（另一种中文编码）”，那么误会就产生了，程序用GBK编码把“你好”两个字翻译成一串数字发给数据库，数据库用UTF-8的方式去解读这串数字，发现根本对不上号，结果就又变成了问号，在建立数据库连接的代码里，明确指定连接使用UTF-8字符集至关重要，比如在MySQL的JDBC连接字符串里，通常会加上参数“?characterEncoding=UTF-8”。

第三个环节是你的程序本身或网页的编码，如果你的程序源文件保存的编码、处理字符串时使用的默认编码，或者你的HTML网页页面声明的编码（meta charset）不是UTF-8，问题也可能在到达数据库之前就发生了，你写了一个JSP页面，但页面头没有声明<%@ page contentType=“text/html; charset=UTF-8” %>，或者一个HTML页面没有，那么浏览器可能用错误的编码（比如ISO-8859-1）来发送表单数据，导致服务器端程序收到的中文已经是乱码了，再把这个乱码存进数据库,自然也是问号。

怎么排查和解决呢？思路就是顺着数据流一个个环节检查，直接登录数据库管理系统（比如Navicat、MySQL Workbench或命令行），手动插入一条中文数据，然后查询看看，如果这里显示正常，说明数据库本身设置没问题，问题就出在程序连接到数据库这个环节，如果这里直接插入就是问号，那问题百分百就是数据库或表的字符集设置错了，检查你的程序连接数据库的代码，确保设置了正确的连接字符集,检查你的程序文件和网页的编码声明。

中文变问号几乎可以断定是编码问题，核心思路就是保证“三位一体”的统一性：即你的程序（或页面）、程序与数据库的连接、数据库本身，这三者使用的字符集必须保持一致，并且这个字符集必须支持中文，在当今环境下，无脑全部选择UTF-8（在MySQL中具体指utf8mb4） 是最简单、最一劳永逸的解决方案，别再纠结于GBK、GB2312这些旧时代的编码了，UTF-8才是国际通用的“世界语”，把这个流程检查一遍,这个烦人的问号问题基本就能解决了。