有人可以告诉我为什么以下preg_match搜索有效:
preg_match("/\xF0\x49\xF7\xF8..\xF3\xF8/s", $bin, $matches2, PREG_OFFSET_CAPTURE);
虽然这不会产生任何结果:
preg_match("/\x3F.\x0D\x01\x3E.\xF3\xFA..\x43\xFA.\x04\xFD\x02/s", $bin, $matches, PREG_OFFSET_CAPTURE);
两种可能性都在$ bin内。
进一步的问题:
搜索以下位置的最佳方法是什么,其中XX是变量,可以是$ bin文件中的任何内容(1匹配或更多),至少我需要每个匹配的起始位置。
我需要搜索一下:
3F XX 0D 01 3E XX F3 FA XX XX 43 FA XX 04 FD 02
示例匹配:
**4 example matches**
1) 3F 64 0D 01 3E 64 F3 FA 86 F8 43 FA E1 04 FD 02
2) 3F 5C 0D 01 3E 5C F3 FA 9C F8 43 FA B6 04 FD 02
3) 3F 5B 0D 01 3E 5B F3 FA 9A F8 43 FA 69 04 FD 02
4) 3F 6B 0D 01 3E 6B F3 FA 78 F8 43 FA 38 04 FD 02
我可以在$ bin文件中搜索$ bin包含原始二进制文件,或者将其转换为bin2hex($ bin),..
我现在发现了这种方式,它似乎正在起作用,但是,这是一个“好”且快速的方法吗?我现在已经在我的脚本中分配了超过300MB的ram,并希望它有点资源友好。
preg_match_all("/3F[A-Z0-9]{2}0D013E[A-Z0-9]{2}F3FA[A-Z0-9]{4}43FA[A-Z0-9]{2}04FD02/", $binhex, $matches, PREG_OFFSET_CAPTURE);
答案 0 :(得分:1)
您最新的正则表达式遗漏了几个空格而{4}
组不符合您的样本。更正了,它看起来像这样:
3F [A-F\d]{2} 0D 01 3E [A-F\d]{2} F3 FA [A-F\d]{2} [A-F\d]{2} 43 FA [A-F\d]{2} 04 FD 02
这是在172steps运行,这没什么可失望的。
为项目选择正确的正则表达式模式时,最好确定您的优先级:
模式简洁&可读性 - 如果在团队中工作或经常更新,则更为关注。
模式速度/步骤 - 处理大量数据时肯定是一个问题。
模式验证强度 - 了解必要的内容是开发人员的责任。
让我们考虑一下我准备的一些选项(还有更多,正则表达式是兔子洞)。
(?:.. ?){16}
272steps :这会优先考虑模式简洁,但需要大量验证强度和速度
(?:[A-F\d]{2} ?){16}
208步:这可以优先考虑简洁性,并略微提高验证和速度
3F \d[A-F\d] 0D 01 3E \d[A-F\d] F3 FA \d[A-F\d] F8 43 FA [A-F\d]\d 04 FD 02
192steps :这是非常直观的,并且优先考虑验证,花费在模式长度和速度上
3F [A-F\d]{2} 0D 01 3E [A-F\d]{2} F3 FA [A-F\d]{2} [A-F\d]{2} 43 FA [A-F\d]{2} 04 FD 02
172steps :量词{2}会提高速度,但会对验证产生轻微影响,因为每对中的字符范围变宽
[A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2} [A-F\d]{2}
135步:当优先考虑速度,模式简洁和验证强度受到很大影响时,这是最明智的权衡
[A-F\d ]{47}
12步:如果验证只需要保护免受恶意字符串的攻击而不是检查字符串质量,这可能就是这样。
然后,如果您对验证的要求很低,那么可能会同时避免regex
/ preg_match_all
的费用。也许使用str_split($str,49)
或类似的。
所以这个决定纯粹属于你自己,但最好有几个选项来比较和对比。
每当您对正则表达式模式有疑问或怀疑时,请转到regex101.com引入一些示例数据并使用一些正则表达式模式进行播放。该页面将显示错误,步骤/速度和捕获的数据 - 这非常方便。