WPF PDF解析Regex异常：金额丢小数位、日期无法匹配

1. 金额提取丢失末尾0的问题 #

这大概率不是Regex的问题，先聚焦iTextSharp的文本提取环节：

• 直接输出PDF提取后的原始文本（未经过Regex处理），确认金额显示的是6.9还是6.90。如果是6.9，说明PDF内部存储的数字就是6.9，只是渲染时补了末尾0，iTextSharp提取的是原始数值，和Regex无关。
• 解决办法：提取到金额后，用格式化字符串强制保留两位小数，示例代码：

  string matchedAmount = Regex.Match(text, @"\d+\.\d+").Value;
  string formattedAmount = decimal.Parse(matchedAmount).ToString("F2");
  

• 如果原始PDF里确实是6.90但提取后变成6.9，尝试更换文本提取策略：把SimpleTextExtractionStrategy换成LocationTextExtractionStrategy，部分PDF的数字格式会因提取策略不同而变化。

2. 日期09-06-2022无法匹配的问题 #

核心是确认提取后的原始日期文本和Regex规则是否匹配：

• 打印提取后的日期行原始文本（比如用Debug.WriteLine输出），检查是否存在隐藏字符（零宽空格、全角破折号等），或者日期是否被拆成了多行。
• 检查Regex模式：如果用的是@"\d{2}-\d{2}-\d{4}"，要确认分隔符是不是标准短破折号-——很多PDF里的日期分隔符可能是长破折号–或—，此时把Regex改成@"\d{2}[-–—]\d{2}[-–—]\d{4}"来匹配多种分隔符。
• 如果日期被拆成多行，比如09-06在一行、2022在下一行，需要给Regex加上RegexOptions.Singleline选项允许跨行匹配：

  Match dateMatch = Regex.Match(text, @"\d{2}-\d{2}-\d{4}", RegexOptions.Singleline);
  

3. 自制Regex执行器与实际提取结果不一致的问题 #

本质是两者的输入文本或Regex配置存在差异：

• 把iTextSharp提取的完整原始文本复制到自制执行器里测试，不要手动输入示例文本——手动输入的文本没有PDF提取时可能携带的隐藏字符、换行或排版差异。
• 检查两边的Regex选项是否完全一致：比如实际代码里是否开启了IgnoreCase、Multiline等选项，自制执行器也要保持相同配置。
• 确认编码一致性：确保自制执行器使用的文本编码和iTextSharp提取的编码一致（iTextSharp默认是UTF-8）。

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