PHP регулярное выражение для анализа буквального регулярного выражения, чтобы определить, что искать

Question

Для этого понадобится лучший ум, чем у меня ... как извлечь шаблон, который ищет буквальное регулярное выражение.

Мое приложение взаимодействует с API, который предоставляет регулярные выражения для определенных строк, касающихся пользователя.ввод по конкретным полям.Примером этого могут служить коды почтовых индексов стран:

Canada, {"ValidationRegex" : "^[ABCEGHJKLMNPRSTVXY]\\d[ABCEGHJ-NPRSTV-Z][\\s\\-]?\\d[ABCEGHJ-NPRSTV-Z]\\d$" }
United Kingdom, {"ValidationRegex": "((([A-Za-z][0-9]{1,2})|(([A-Za-z][A-Ha-hJ-Yj-y][0-9]{1,2})|(([AZa-z][0-9][A-Za-z])|([A-Za-z][A-Ha-hJ-Yj-y][0-9]?[A-Za-z]))))[0-9][A-Za-z]{2})|GIR0AA" }

Я пытаюсь проанализировать шаблон Regex, чтобы увидеть, только его буквы, только цифры или смешанные.Затем, основываясь на проверяемых форматах проверки для различных строк, я хочу принудительно отобразить тип клавиатуры, отображаемый пользователю для этого конкретного поля ввода.Типы клавиатуры основаны на TEXT, TEL, NUMBER, а также ограничены длиной или диапазоном <input>, основанными на требованиях проверки.К сожалению, нет никакой другой предоставленной информации, которая позволила бы мне точно определить тип клавиатуры или длину строки или чем пытаться сломать регулярное выражение проверки.

Это для потенциально сотен различных типов проверкирегулярные выражения, поэтому я надеюсь найти универсальный способ извлечения необходимой информации из каждого выражения регулярного выражения, чтобы определить, является ли строковый код только числом или требует символов ... и диапазонов длины.

Answer 1

Хотя вы можете автоматизировать это, создавая свои собственные правила регулярных выражений, для ошибки слишком много пределов, чтобы на нее можно было положиться.Подход, который следует рассмотреть, состоит в том, чтобы сбросить все их строки проверки в таблицу SQL.Затем вы можете отсортировать их так, чтобы каждому уникальному шаблону регулярных выражений был присвоен идентификатор.Затем во второй таблице вы можете сопоставить каждый из этих идентификаторов с классом TEXT, TEL, NUMBER и т. Д.

Таким образом, у вас будут таблицы, которые выглядят так:

tblRegexStrings
id | uniqueID | location         | regex
1    1          'Canada'           "^[ABCEGHJKLMNPRSTVXY]\\d[ABCEGHJ-NPRSTV-Z][\\s\\-]?\\d[ABCEGHJ-NPRSTV-Z]\\d$"
2    2          'United Kingdom'   "((([A-Za-z][0-9]{1,2})|(([A-Za-z][A-Ha-hJ-Yj-y][0-9]{1,2})|(([AZa-z][0-9][A-Za-z])|([A-Za-z][A-Ha-hJ-Yj-y][0-9]?[A-Za-z]))))[0-9][A-Za-z]{2})|GIR0AA"
3    2          'France'           "((([A-Za-z][0-9]{1,2})|(([A-Za-z][A-Ha-hJ-Yj-y][0-9]{1,2})|(([AZa-z][0-9][A-Za-z])|([A-Za-z][A-Ha-hJ-Yj-y][0-9]?[A-Za-z]))))[0-9][A-Za-z]{2})|GIR0AA"

tblRegexClasses
uniqueID | classType
1          'TEXT'
2          'TEL'

Еслисуществует значительное количество повторного использования в шаблонах регулярных выражений (что, я подозреваю, будет), тогда это поможет сократить его до разумного числа классов, которые вы можете назначить вручную.Таким образом, если 50 местоположений используют тот же шаблон регулярных выражений, что и в Соединенном Королевстве, вы можете установить все их классы одновременно, изменив classType строки 2 в tblRegexClasses.

Если это все еще так много данных, которые вам нужныдля регулярного выражения, но есть также многократное использование, тогда я все равно рекомендую использовать это, так как вам все равно придется отслеживать ваши данные.Поскольку ваши функции регулярных выражений могут делать неверные предположения, или вам не нужно делать тонны исключений для каждого дополнительного случая.