嫩草精品入口乱码｜入口页中文显示排查与修复笔记

打开入口页，标题栏跳出一串方块、问号，或者「锟斤拷」「烫烫烫」这类替换串，正文却零零散散能认出一半——这就是典型的嫩草精品入口乱码现象。它几乎不是内容本身出了问题，而是文字在「存下来—传过去—画出来」这条链路上，编码声明和实际字节对不上号。

下面这份笔记按真实排查顺序组织：先认形态，再一层层往下找，最后给出可在浏览器、路由与终端里直接照做的处理办法。全程不需要装任何插件。

四种最常见的乱码形态

乱码不是同一种病，认对形态能省掉大半时间。

• 方块与问号 □□□：字体里根本没有这些字，通常是设备缺少中文字体，或者页面声明了错误的字符集。
• 锟斤拷、烫烫烫、屯屯屯：典型的 UTF-8 与 GBK 之间来回转码留下的痕迹，往往出现在老模板或二次拼接的段落里。
• 首屏正常、往下滚才乱：后半段内容来自另一段拼接输出，那段数据的编码和前段不一致。
• 只有标题或导航乱：页面主体用了新模板，头部或导航还留着旧声明，两者打架。

从声明到渲染的六步排查

1. 看页面的字符集声明。打开源码，确认头部是否写了 charset="utf-8"，以及它是否排在其他内容之前。声明晚于正文，浏览器就可能已经按默认编码读完前几百字节。
2. 核对响应头。同一份页面，服务器在响应头里另报了一套编码，就会和页面内的声明冲突。两边统一成 UTF-8 是最省事的做法。
3. 手动切换编码试读。在浏览器的编码菜单里逐个试 UTF-8、GBK、GB18030，哪种切过去正文立刻正常，答案就指向哪一边。
4. 检查跳转链路。从首页跳到入口页，中间若经过一次带参数的重写或代理转发，中文参数容易被二次编码，落到目标页时已经是「转了两遍」的样子。
5. 检查 URL 里的中文。地址栏里的中文参数应当是 URL 编码后的形式，出现 % 后接十六进制是正常的；出现裸中文或成对的 %25，就说明编解码多做了或漏做了一次。
6. 检查设备侧。换一台手机或另一款浏览器做对照，如果只有某一台设备乱，那多半是系统字体包缺字，和页面本身无关。

现象与对应处理一览

页面声明缺失或写在正文之后

把字符集声明移到头部最前面，并确保保存文件时使用的就是同一套编码，避免「文件是 GBK、声明写 UTF-8」这种自相矛盾。

响应头与页面声明不一致

统一两处设置即可，通常保留响应头参与判断、页面显式声明 UTF-8，能让大多数浏览器稳定落到同一结果。

中文参数被重复编码

在跳转或转发环节只做一次编码转换，接收端只解码一次；多解一次会把正常中文拆成乱码。

只有局部段落乱

定位到那段内容的来源，单独统一其输出编码，不必整页重做。

换设备后正常

属于本机字体缺失，安装或切换一套包含中文字形（如思源黑体、苹方）的系统字体即可恢复。

常见疑问

为什么同一个入口，在两台设备上显示完全不同？

浏览器回退编码的策略和本地字体覆盖范围不一样，同一份字节会被解释成不同结果。用一台显示正常的设备做基准，更容易判断问题在哪一层。

只乱在标题和导航，正文却没事，需要整页重做吗？

不需要。这通常说明页面主体已经按新规范输出，只有头部仍沿用旧声明，改那一处即可。

换了浏览器就好了，是不是就不用管了？

换浏览器只是绕开了回退策略，根源仍在编码声明或响应头。建议把声明统一，否则换回原来的浏览器还会重现。

复制出来的文字粘到文档里恢复正常，说明什么？

说明原始数据是对的，问题出在渲染环节，重点检查字体与编码声明，而不是内容源。

把乱码段落手打一遍能解决吗？

能暂时绕过，但下次更新还会重现。优先修声明的统一性问题，而不是逐字重录。