Smalot PDF Parser提取文本后preg_match_all匹配失败问题排查

出现这种情况的常见原因及解决方法如下：

1. 不可见控制字符或非标准空格干扰 #

PDF文件中常包含软换行、非断空格（ASCII 160）、零宽空格这类不可见字符，它们在浏览器显示时会被自动忽略，但提取的原始文本中仍会保留。从浏览器复制的文本会丢失这些字符，导致两者严格对比不相等；同时正则表达式中的\s默认只匹配标准空格、制表符和换行，无法匹配非断空格这类特殊空白字符，进而导致匹配失败。

解决方法：

• 用bin2hex($fullPageText)和bin2hex($copiedText)对比十六进制值，找出差异字符；
• 清理文本中的控制字符和非标准空格：

  $fullPageText = preg_replace('/[\x00-\x1F\x7F\xA0]/', ' ', $fullPageText);
  

• 正则中用[\s\xA0]替代\s，确保匹配所有空白类型。

2. 字符编码不一致 #

PDF解析提取的文本可能带有BOM（字节顺序标记），或者采用了与浏览器输出不同的编码（比如UTF-8 vs GBK）。严格相等判断对编码差异非常敏感，会直接返回不相等；同时编码不兼容也会导致正则匹配失效。

解决方法：

• 检测并统一编码为UTF-8：

  $encoding = mb_detect_encoding($fullPageText);
  $fullPageText = mb_convert_encoding($fullPageText, 'UTF-8', $encoding);
  

3. 换行符格式不统一 #

PDF文本中的换行可能是\n、\r或\r\n，浏览器输出时会将其转换为HTML换行，复制到变量时又会被系统替换为对应平台的换行符（Windows是\r\n，Linux是\n），导致两者换行符不一致，对比失败且正则中的换行匹配逻辑失效。

解决方法：

• 统一所有换行符为\n：

  $fullPageText = preg_replace('/\r\n|\r/', "\n", $fullPageText);
  

4. PDF文本存储顺序与视觉顺序不符 #

PDF的文本内容不一定按视觉排版顺序存储，getText()方法拼接文本时可能按PDF内部的存储顺序拼接，导致提取的文本顺序和视觉显示、复制的文本顺序不一致，这种情况下正则自然无法匹配预期的内容结构。

解决方法：

• 用var_dump($fullPageText)查看提取文本的实际字符顺序；
• 使用PDF Parser的getTextBlocks()方法获取带有位置信息的文本块，按坐标排序后再拼接：

  $textBlocks = $page->getTextBlocks();
  // 按Y坐标降序、X坐标升序排序（模拟从上到下、从左到右的阅读顺序）
  usort($textBlocks, function($a, $b) {
      if ($a['bbox'][1] != $b['bbox'][1]) {
          return $b['bbox'][1] - $a['bbox'][1];
      }
      return $a['bbox'][0] - $b['bbox'][0];
  });
  $fullPageText = '';
  foreach ($textBlocks as $block) {
      $fullPageText .= $block['text'] . ' ';
  }
  

5. 浏览器输出时的自动处理 #

直接用echo输出文本时，浏览器会按HTML规则处理内容：合并多个连续空格、转义特殊字符（如<、>）、将换行转为<br>，导致复制的文本和原始提取文本存在差异。

解决方法：

• 在输出前设置纯文本响应头，让浏览器直接显示原始文本：

  header('Content-Type: text/plain; charset=utf-8');
  echo $fullPageText;
  

  此时复制的内容就是提取文本的原始状态，再进行对比或正则匹配就会准确。

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