问题描述
|
我有以下用于数据验证的正则表达式:
lexer = /(?:
(.{18}|(?:.*)(?=\\s\\S{2,})|(?:[^\\s+]\\s){1,})\\s*
(.{18}|(?:.*)(?=\\s\\S{2,})\\s*
(?:\\s+([A-Za-z][A-Za-z0-9]{2}(?=\\s))|(\\s+))\\s*
(Z(?:RO[A-DHJ]|EQ[A-C]|HIB|PRO|PRP|RMA)|H(?:IB[2E]|ALB)|F(?:ER[2T]|LUP2|ST4Q))\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\s+\\d{10}|\\s+)\\s*
(\\d{6})\\s*
(.*)(?=((?:\\d{2}\\/){2}\\d{4}))\\s*
((?:\\d{2}\\/){2}\\d{4})\\s*
(\\S+)
)/x
问题是我必须遍历一个具有10000行(平均)的文件,并使用正则表达式执行验证,从而导致应用程序解析缓慢。
filename = File.new(@file,\"r\")
filename.each_line.with_index do |line,index|
next if index < INFO_AT + 1
lexer = /(?:
(.{18}|(?:.*)(?=\\s\\S{2,})\\s*
(?:\\s+([A-Za-z][A-Za-z0-9]{2}(?=\\s))|(\\s+))\\s*
(Z(?:RO[A-DHJ]|EQ[A-C]|HIB|PRO|PRP|RMA)|H(?:IB[2E]|ALB)|F(?:ER[2T]|LUP2|ST4Q))\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\s+\\d{10}|\\s+)\\s*
(\\d{6})\\s*
(.*)(?=((?:\\d{2}\\/){2}\\d{4}))\\s*
((?:\\d{2}\\/){2}\\d{4})\\s*
(\\S+)
)/x
m = lexer.match(line)
begin
if (m) then ...
编辑
在这里,您可以找到一些我需要解析的行:File
编辑II
@迈克·R
我正在解析一个每行包含25列的文件,每列可能都有它自己的验证方式。它可以是空格或完整的字符集。
该验证是必需的,因为我必须放弃与该部分不匹配的行。
可能不是必需的
这是必要的
我不认为该表达式的构造不正确,也不使用它的前瞻性,也许我重复了这段代码(我只是不记得捕获组索引\\ 1。)。 。\\ n,如果这是您的意思!)我也相信,灾难性的回溯正在这里发生。
如果您看到该文件,也许您会明白我为什么这样做的原因!让我们以第一列为例。我必须匹配一个\“ Part Number \”,而我对此没有任何规则,例如:
123456789
1555989
0123456789123456789
简单的\\ S +或(\\ S + \\ s){1,}都无法解决此问题,因为我不会保证数据的完整性。
!
有什么改进,建议吗?
〜埃德·基尼翁斯
解决方法
您的文件是具有固定宽度字段的格式。 Ruby有一个称为
unpack
的字符串方法,专门用于解析这种类型的文件。
field_widths = [19,41,14,11,11] #etc
field_pattern = \"A#{fields.join(\'A\')}\"
然后在您的行循环中:
row = line.unpack(field_pattern)
现在,您有了一个包含每个字段内容的数组(行)。然后,您可以将每一个正则表达式应用于验证。这更快,更易于管理,并且还允许特定于字段的错误消息。
,
regexp在循环中没有变化,因此将lexer =
分配拉出循环。 (\“循环不变代码运动。\”)
我不确定这是快还是慢,但重复的子表达式可能只是一个外部重复组。
我敢肯定,这很明显,但是编写一个真正的解析器可能有意义。 Ruby具有称为Treetop的高级PEG解析器生成器。传统方法是Lex + Yacc(例如flex + bison)或仅是一个C程序,它实现了扫描器和递归下降解析器。是的,老式的,但是很容易编写,并且与另一个CRUD程序相比是一种有趣的变化。
我同意其他响应者的观点,该表达不必要地多余,复杂,应该分解为至少两个单独的较小的表达。两个表达式可能很有趣,因为它们都可能相反地锚定。
, 您可能正在经历灾难性的回溯。
即,但不仅是因为您贪婪的\\S+\\s*
序列。由于以下原因,它们也可能无效:
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
(\\S+)\\s*
会匹配\'abcd\'
(经过大量的回溯之后)。
另外,正如其他答案所指出的那样,请尝试在循环外编译该正则表达式定义。
, 您实际上在寻找什么?
据我所知,您只需要寻找一些重要的元素。
您正在寻找以Z开头的字母数字。
(Z(?:RO[A-DHJ]|EQ[A-C]|HIB|PRO|PRP|RMA)|H(?:IB[2E]|ALB)|F(?:ER[2T]|LUP2|ST4Q))\\s*
您正在寻找6位数字
(\\d{6})\\s*
您正在寻找日期
(?=((?:\\d{2}\\/){2}\\d{4}))\\s*
((?:\\d{2}\\/){2}\\d{4})\\s*
(请注意,最后一个日期表达式是一个构造错误的示例。它具有对日期的前瞻性,紧随其后的是与该日期完全相同的非捕获匹配。因此,前瞻性毫无意义。请参阅有关灾难性回溯的其他答案,这无疑是在这里发生的。)
该表达式中的几乎所有其他内容都可以匹配任何/所有内容,我发现很难相信它们在表达任何有意义形式的规则。实际数据只是变化不大,或者随一些可以用一个(或多个正则表达式)表达的精确规则而变化。
因此,请完全废弃该表达式,并停止尝试立即全部完成。进行单独的处理(根据需要在\\ s上分割行),然后将其分解为几个小正则表达式,这些正则表达式实际上与您实际需要验证的内容匹配。