已配置全链路UTF-8仍出现�字符，求排查方案

1. 定位页面首行的非法字节 #

W3C提示首行存在无法解析的UTF-8字节，这是核心线索：

• 检查index.php的BOM头：用VS Code打开后，右下角编码选择「UTF-8 without BOM」重新保存；或用十六进制编辑器查看文件开头是否有EF BB BF字节（UTF-8 BOM），若有直接删除。
• 排查PHP文件开头的空白字符：确认<?php标签前无空格、换行或不可见字符，包括所有被include/require的文件，这些额外输出会成为页面首内容，可能引入非法字节。

2. 对比正式页与测试页的差异 #

既然test.informel1.de运行正常，重点排查两者的不同点：

• 逐行对比index.php与测试页的代码，尤其是内容输出逻辑：正式页是否有额外的header输出、缓存机制，或引入了测试页没有的第三方脚本/样式？
• 检查正式页是否开启输出缓存（如ob_start()），临时关闭缓存测试是否恢复正常。
• 对比两者的.htaccess配置：正式页是否存在AddDefaultCharset或其他编码相关规则，而测试页没有？

3. 验证数据库连接编码的有效性 #

尽管已执行mysqli_set_charset和SET NAMES，仍需确认生效状态：

• 在数据库查询前执行echo mysqli_character_set_name($link);，确认输出为utf8mb4而非utf8或其他编码。
• 输出数据库查询结果的原始字节：取含变音符号的记录，用bin2hex()转换为十六进制，与phpMyAdmin中存储的原始数据对比，排查过程中是否发生编码转换。

4. 排查PHP输出的编码转换操作 #

• 检查代码中是否调用mb_convert_encoding、iconv等转换函数，确认未错误地将UTF-8转成ISO-8859-1等其他编码。
• 对比正式页与测试页的phpinfo()输出，确认default_charset、mb_internal_encoding、mb_http_output等配置完全一致。

5. 检查服务器响应头的编码设置 #

用浏览器开发者工具查看正式页的响应头：

• 确认Content-Type头为text/html; charset=utf-8，而非text/html; charset=ISO-8859-1或其他编码。
• 若存在Content-Encoding头（如gzip），确认压缩过程未破坏UTF-8编码，可临时关闭压缩测试。

6. 排查静态资源的编码问题 #

若页面引入CSS、JS等静态文件，检查这些文件的编码是否为UTF-8：

• 重点排查CSS中的特殊字符（如字体图标、德语变音符号），若文件本身为GBK或ISO-8859-1，会污染页面的编码检测结果。

内容的提问来源于stack exchange，提问作者liogetz