17370845950

PHP接口乱码主因是文件编码非UTF-8无BOM、Content-Type响应头缺失或错误、MySQL连接及表字符集不一致；需统一为UTF-8无BOM，设header('Content-Type: application/json; charset=utf-8')，执行SET NAMES utf8mb4，并逐层验证输出字节。

PHP 接口返回数据乱码，绝大多数情况是 Content-Type 响应头缺失或错误 + PHP 文件自身编码不一致导致的，不是“加个 header('Content-Type: text/html; charset=utf-8');”就能一劳永逸的事。

检查 PHP 文件本身的编码是否为 UTF-8 无 BOM

很多编辑器（如 Windows 记事本、旧版 Notepad++）默认保存为 ANSI 或 UTF-8 with BOM，BOM 会作为不可见字符提前输出，破坏 JSON 格式，导致前端解析失败或显示乱码。

• 用 VS Code / Sublime Text / 新版 Notepad++ 打开 PHP 文件 → 查看右下角编码显示，确认是 UTF-8（不是 UTF-8 with BOM）
• 若显示带 BOM，点击编码菜单 → 转换为 UTF-8（无 BOM）→ 重新保存
• 特别注意：require 或 include 的所有 PHP 文件（包括配置、函数库）都必须是 UTF-8 无 BOM

设置正确的 Content-Type 响应头和字符集

接口返回 JSON 时，Content-Type 必须明确声明 charset=utf-8，且不能被其他输出干扰（如空格、echo、warning 输出）。

• 在 echo json_encode(...) 前，确保没有 echo、print、空白行、错误提示输出
• 强制设置响应头：

  header('Content-Type: application/json; charset=utf-8');

• 不要用 text/html 做 JSON 接口，即使加了 charset，部分浏览器或客户端仍可能忽略
• 如果用了 json_encode()，建议加上 JSON_UNESCAPED_UNICODE 避免中文被转成 \uXXXX：

  echo json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);

确认 MySQL 查询结果编码是否一致

即使 PHP 和响应头都正确，从数据库读出的数据本身是 latin1 编码，也会导致乱码——尤其老项目表结构用的是 latin1_swedish_ci。

• 连接 MySQL 后立即执行：

  $pdo->exec("SET NAMES utf8mb4");

  （推荐 utf8mb4，兼容 emoji）
• 检查表与字段的 CHARACTER SET：

  SHOW CREATE TABLE `your_table`;

  确保是 utf8mb4 和 utf8mb4_unicode_ci
• 如果用 mysqli，连接时指定 charset：

  $mysqli = new mysqli($host, $user, $pass, $db, $port, $socket);
  $mysqli->set_charset("utf8mb4");

调试时快速定位乱码源头

别猜，用最直接的方式验证每层输出的原始字节：

• 用 curl -v http://your-api.com/xxx.php 查看响应头中是否有 Content-Type: application/json; charset=utf-8
• 用 curl -s http://your-api.com/xxx.php | hexdump -C | head 查看前几个字节：正常 UTF-8 中文开头是 e4 b8 ad 这类，如果看到 ef bb bf 就是 BOM；如果看到 ce d2 类似值，很可能是 GBK 编码残留
• 在 PHP 中临时加一行：

  file_put_contents('/tmp/debug.txt', print_r($data, true), FILE_APPEND | LOCK_EX);

  检查变量内容是否已乱，排除数据库或逻辑层问题

真正卡住的往往不是某一行代码，而是多个环节编码状态不一致：文件存的是 GBK，MySQL 连接设的是 latin1，header 写的是 utf-8，JSON encode 又没处理好——这种组合会让任何单点修复都失效。逐层验证比反复改 header 更有效。