我正在尝试寻找一种更好的解决方案,以对其中一些著名的文件格式进行解析,例如:EDIFACT和TRADACOMS。
如果您不熟悉这些标准,请查看Wikipedia的以下示例:
参见以下有关用于回答产品可用性请求的EDIFACT消息的示例:-
UNA:+.? '
UNB+IATB:1+6XPPC+LHPPC+940101:0950+1'
UNH+1+PAORES:93:1:IA'
MSG+1:45'
IFT+3+XYZCOMPANY AVAILABILITY'
ERC+A7V:1:AMD'
IFT+3+NO MORE FLIGHTS'
ODI'
TVL+240493:1000::1220+FRA+JFK+DL+400+C'
PDI++C:3+Y::3+F::1'
APD+714C:0:::6++++++6X'
TVL+240493:1740::2030+JFK+MIA+DL+081+C'
PDI++C:4'
APD+EM2:0:130::6+++++++DA'
UNT+13+1'
UNZ+1+1'
UNA段是可选的。如果存在,它将指定将用于解释消息其余部分的特殊字符。UNA后面有六个字符,顺序如下:
- 组件数据元素分隔符(在此示例中:)
- 数据元素分隔符(此示例中的+)
- 十进制通知(此示例中的。)
- 释放字符(此示例中的?)
- 保留,必须为空格
- 段终止符(此示例中的')
如您所见,这只是一些以特殊方式格式化的数据等待解析(非常类似于XML文件)。
现在我的系统是建立在PHP之上的,并且我能够为每个段使用正则表达式创建解析器,但是问题不是每个人都能完美地实现标准。
一些供应商倾向于完全忽略可选的细分市场和领域。其他人可能选择发送比其他人更多的数据。这就是为什么我不得不为段和字段创建验证器以测试文件是否正确。
您可以想象我现在正在遇到的正则表达式的噩梦。另外,每个供应商都需要对正则表达式进行很多修改,我倾向于为每个供应商构建一个解析器。
问题:
1-这是解析文件(使用正则表达式)的最佳实践吗?
2-是否有更好的解析文件的解决方案(也许那里有现成的解决方案)?它能否显示缺少的段或文件已损坏?
3-如果仍然要构建解析器,应该使用哪种设计模式或方法?
笔记:
我读过有关yacc和ANTLR的文章,但不知道它们是否符合我的需求!