基于Drupal7+PHP5.6的API响应出现ZWNBSP未知字符排查求助

先明确：你碰到的efbbbf是UTF-8格式的字节顺序标记（BOM），对应Unicode字符U+FEFF，也就是你说的ZWNBSP。下面分方向逐一排查：

一、排查CloudFlare CDN/WAF的影响 #

• 直接绕开CloudFlare：用生产服务器的IP（不是域名）调用受影响的API接口，看响应里还会不会有这个字符。如果没了，问题肯定出在CloudFlare。
• 查CloudFlare设置：看看有没有开自动编码转换、HTML重写这类内容优化功能，有些功能可能在处理响应时误插BOM。
• 看CloudFlare日志：检查边缘节点的请求/响应日志，确认BOM是在CloudFlare转发前就有，还是转发后加上的。

二、排查生产服务器PHP环境 #

• 检查PHP核心配置：打开php.ini，看output_buffering和default_charset，确保default_charset设为UTF-8，且没开能插入BOM的输出处理模块。
• 加调试日志抓输出前后的内容：在API输出响应的前后加日志，记录原始数据和最终输出的十六进制，对比BOM什么时候出现的。比如：

  // 输出响应前，记录原始数据
  $raw_response = ...; // 你的API原始响应内容
  file_put_contents('/tmp/api_raw.log', bin2hex($raw_response) . PHP_EOL, FILE_APPEND);
  
  // 捕获最终输出
  ob_start();
  // 原有输出逻辑（比如drupal_json_output($raw_response)）
  $final_output = ob_get_clean();
  file_put_contents('/tmp/api_final.log', bin2hex($final_output) . PHP_EOL, FILE_APPEND);
  

• 检查PHP扩展：看phpinfo()里的输出处理相关配置，有没有装mbstring这类可能修改输出的扩展，比如mb_output_handler会不会搞事。

三、排查Drupal 7.39的潜在问题 #

• 查API回调逻辑：看看输出响应的代码有没有读取那个UnicodeTest.txt，要是有逻辑不小心引入了这个文件的内容，可能会把BOM带进去。
• 检查Drupal输出管道：看用的是drupal_json_output()还是自定义输出，有没有第三方模块或自定义模块在输出前修改了响应内容，插了BOM。
• 对比本地和生产的Drupal配置：导出两边的system模块配置，看有没有差异，比如是不是生产环境开了某些本地没开的内容过滤模块。

四、其他可能的排查点 #

• 检查数据库数据：如果API数据来自数据库，用数据库客户端导出对应字段的内容，看十六进制里有没有efbbbf。
• 检查静态资源/模板：要是响应里包含模板渲染的内容，查对应的模板文件、静态资源本身有没有带BOM。

内容的提问来源于stack exchange，提问作者Muhammad Dyas Yaskur