蜘蛛抓页面时，拿到的是一串字节，而不是已经排好版的文字。它需要先按字符编码把字节还原成字符，才能继续切词、识别标题、判断主题。这一步出问题，页面本身能正常访问，返回码也是 200，可蜘蛛读到的内容却可能是问号、方块或者错位的符号。对站点运营来说，这类问题不像 404 那样一眼可见，但一旦发生，往往牵涉整批页面。
编码不对时，蜘蛛会看到什么
乱码不一定会让页面抓取失败，更常见的是“抓到了但读不懂”。表现通常集中在几个地方：
- 标题与摘要里出现替换字符，搜索结果展示异常；
- 正文关键词提取失败，页面主题判定偏移；
- 内链锚文本变成乱码，链接的语义信息丢失；
- 栏目名、面包屑显示错乱，站点结构理解受影响。
这些问题里，最容易被忽略的是锚文本。锚文本本身是蜘蛛理解链接目标的重要线索，如果它读到的是乱码，这条内链就只剩下一个地址，描述性信息基本作废。
三个声明位置，优先级要理清
页面编码通常有三个来源：HTTP 响应头里的 Content-Type、HTML 里的 meta charset，以及蜘蛛在两者缺失时的自动检测。多数情况下，响应头的优先级高于 meta。如果响应头写着一种编码，meta 里写着另一种，解析结果就取决于抓取端的取舍策略，等于把不确定性留给了别人。
所以自查的第一步不是看哪个声明写得漂亮，而是看它们是否一致。
具体的自查步骤
- 用 curl 或浏览器开发者工具查看响应头中的 Content-Type，确认是否带上 charset 参数。
- 抓取 HTML 源码的前几百字节，确认 meta charset 是否存在、是否放在 head 靠前的位置。
- 检查文件开头是否多出 BOM 字节，BOM 有时会让头部声明位置整体后移。
- 核对数据库连接、建表语句与数据表本身的字符集是否统一。
- 抽查含中文标点、生僻字、特殊符号的页面，这类页面最容易暴露编码问题。
- 检查同域下 JS、CSS、JSON 接口的编码声明是否与页面保持一致。
抽查时建议覆盖不同类型模板：首页、列表页、详情页、搜索结果页。有些乱码只出现在某个模板的某一处输出变量上，只看首页很难发现。
修复时容易踩的坑
- 只改 meta 不改响应头。两者矛盾时，改动可能完全不起作用。
- 只改页面不改数据源。如果数据入库时已经损坏，输出端再怎么声明也还原不回来。
- 忽略缓存层。CDN 或页面缓存里还留着旧版本，修复后抓到的仍是乱码页。
- 忘记后台与表单。编辑提交、接口回传如果用的是另一套编码，内容会在写入环节被破坏。
编码问题属于改一次、长期受益的类型，但要留意新上线的栏目模板别把老毛病带回来。建议把编码检查写进模板上线前的确认清单。
把它放进例行巡检
编码不会天天出问题，可一旦出问题，影响面往往不小。比较务实的做法是：统一使用 UTF-8，在响应头里明确声明，meta 作为兜底且与响应头保持一致；每次更换服务器、调整 CDN、更新模板后，重新抽查几个含中文的页面。
这件事不需要频繁做，但需要在关键节点做。它不是能立刻看到效果的操作，只是让蜘蛛在解析环节少一次误判的机会。