网站乱码，字符集才是元凶

打开页面，中文全成了一排问号，或者冒出 æ–‡ç« 这种带帽子的拉丁字母。第一反应多半是“被人改了”“中病毒了”，可十有八九，网站乱码，字符集才是元凶——文件存的、页面声明的、服务器返回的，只要有一处对不上，中文当场散架。

网站乱码，字符集才是元凶——三层声明先对上

字符集这件事说白了就三层：文件本身存成什么编码、HTML 前几行的 meta 声明、HTTP 响应头里的 Content-Type。三层都是 UTF-8 就天下太平，三层各说各话，浏览器只能挑一个信。别怪浏览器不聪明，它大致按 BOM、响应头、meta 这个顺序判，各家实现还有细微差别，与其指望它猜，不如自己写清楚。

怎么确认？打开开发者工具，Network 面板点开那个 HTML 请求，看响应头里有没有 charset；源码里搜 meta charset；编辑器右下角或者“另存为”对话框看文件编码。三处一致了，一大半问题当场就没了。

文件存成什么编码，比你怎么写还关键

最常见的翻车点在保存那一下。同一份模板，自己电脑上打开正常，发给同事一保存就乱——不是代码被改了，是他编辑器默认存成了另一种编码。系统自带的记事本尤其容易惹事，Windows 不同版本默认值不一样，有的 ANSI，有的 UTF-8，你以为只是改了个字，整个文件的编码被重写了一遍。

还有从网页复制代码块、从别人的压缩包里拷模板，全角空格、弯引号、零宽字符一起带进来。这些东西在编辑器里看不出来，一跑就报错或者显示成方块。养成习惯：接到外部文件先看编码，再另存为 UTF-8，别省这一步。

数据库连接字符集，最容易漏的那一层

页面上汉字正常，一调数据库就变乱码——这种形态多半不是页面编码的事，而是连接字符集没设对。MySQL 的连接层面有 client、connection、results 几个变量，还有库和表的字符集，任何一环还停在 latin1 或者老 utf8，写进去的就已经是坏数据了。这种乱不是改改配置就能自动修复的，脏数据得单独清洗。

稳妥做法是连接串里带 charset=utf8mb4，或者连上先执行 SET NAMES utf8mb4；建库建表统一用 utf8mb4。老库里存着历史数据，想升字符集别在生产环境直接动大表，先备份、先在测试库跑一遍，具体参数以服务商或官方文档说明为准。

utf8 和 utf8mb4，差的不只是一个字母

顺带说一句，MySQL 里那个叫 utf8 的字符集并不完整，只覆盖三字节，四字节的字符塞不进去。用户昵称里带个 emoji，或者名字里有生僻字，存的时候直接报错，或者被截成问号。所以现在建库基本都上 utf8mb4，这个别图省事。

nginx 一句 charset，可能把程序输出盖掉

应用层明明已经 header 输出 utf-8，服务器配置里又躺着一句 charset gbk，某些场景下会被后写的盖掉。还有一点不少人不知道：charset 指令只对 charset_types 里列出的 MIME 类型生效，默认盯的是 text/html，css、js、txt 未必管到，于是页面主体正常，样式表里的中文注释乱成一团。

报错页单独乱也是同一个道理——error_page 跳过去的那个静态文件，编码和主站不一致。检查思路很简单：把出问题的 URL 打开，看响应头，再比对文件本身，别只盯着主页面。

BOM 和剪贴板，两个看不见的坑

UTF-8 带 BOM 保存的文件是个隐形杀手。BOM 是文件头那几个字节，服务器会把它当正文提前吐出去，随后 PHP 就报 headers already sent，跳转、Cookie、session 全部失灵。查法不难，用十六进制工具看文件头有没有 EF BB BF，有就去掉，编辑器一般都有 UTF-8 无 BOM 的选项。

另一个坑在内容来源。从 Word 或者某些后台富文本编辑器粘过来的引号、破折号、不换行空格，会被转成特殊字符，看着像乱码，其实不是编码错误；粘进 JSON 里更糟，解析直接失败。要排查这种，把那段字符串拿去做十六进制比对，问题一眼就出来了。

真乱起来了，按这个顺序排查

先分清范围：是单个页面还是全站，静态页还是动态页，前台还是后台。全站都乱，去看统一的响应头和模板；只有列表页乱，去看数据库查询和连接；只有一个 js 文件乱，去看文件本身。再往下就是那三层加数据库，一层层排掉，比东改一处西改一处快得多。

还有一种容易被忽略：CDN 上开了内容改写或者压缩，Content-Type 里的 charset 被抹掉，源站正常、加速之后反而乱。这种先刷缓存，再看回源配置和响应头，拿不准就直接问服务商，以他们页面上的说明为准。

换个场景：后台导出的表格也乱

客服那边常接到这种问题——后台导出的 CSV，用 Excel 打开中文全是乱码。多半是文件存成 UTF-8 无 BOM，Excel 按本地编码硬解。解法是导出时带上 BOM，或者干脆生成 xlsx。JSON 接口同理，编码函数里加那个不转义 Unicode 的选项，前端拿到的才是汉字，不是 \u4e2d 这种。

老 GBK 站想转 UTF-8，别一口气全改

跑了很多年的老站，文件和库都是 GBK，眼馋 utf8mb4 想迁。能迁，但别一次性全动。先把整站和数据库备到手上，在测试环境里转，用 mysqldump 导出时指定字符集参数，导入新库后逐页核对；注意搜索替换只针对文本文件，别碰图片和压缩包，二进制改坏了就真废了。转完观察一段时间，再动生产。

页面冒问号的时候，先别删代码，也别急着怀疑被黑。把文件编码、meta、响应头、数据库连接这四处排一遍，多数问题当场就能定位。改动之前先备份，这条老规矩从来没白费过。