двоичный файл — сбой preg_match
Может кто-нибудь сказать мне, почему следующий поиск 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 — переменные и могут быть чем угодно (1 совпадение или больше) в файле $ bin, по крайней мере, мне нужна начальная позиция каждого совпадения.
Мне нужно искать это:
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), ..
Я узнал об этом сейчас, и, похоже, это работает, но действительно ли это «хороший» и быстрый способ сделать это? В моем скрипте уже выделено более 300 МБ ОЗУ, и я хочу, чтобы он был немного более дружественным к ресурсам.
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);
Решение
Вашему последнему регулярному выражению не хватало нескольких пробелов и {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}
208steps: это отдает приоритет краткости, с немного улучшенной проверкой и скоростью
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} 135steps: это самый большой разумный компромисс, когда приоритеты в скорости, краткости и силе проверки в значительной степени затронуты
[A-F\d ]{47} 12steps: _Если валидация нужна только для защиты от вредоносных строк, а не для проверки качества строк, это может быть полезно.
Опять же, если ваш спрос на валидацию такой низкий, то, возможно, избегайте затрат на regex/preg_match_all все вместе. Возможно использовать str_split($str,49) или похожие.
Таким образом, решение остается за вами, но лучше всего сравнить несколько вариантов.
Всякий раз, когда у вас есть вопросы или сомнения по поводу шаблона регулярных выражений, отправляйтесь на regex101.com добавьте несколько примеров данных и поиграйтесь с несколькими шаблонами регулярных выражений. Страница покажет вам ошибки, шаги / скорость и захваченные данные — это очень удобно.
Другие решения
Других решений пока нет …