OmniDocПрежде чем использовать регулярные выражения для проверки чисел, сначала подумайте, что делать с полноширинными символами.
Число `AB-1234` выглядит просто, но реальный ввод может иметь префиксы, конечные символы новой строки или символы полной ширины. Просто напишите обычное правило, а затем отпустите его, когда увидите «сопоставление успешно». Легко принять попадающуюся подстроку за все поле, соответствующее протоколу.
При написании обычного контрольного номера входные данные могут содержать префиксы, конечные символы новой строки или символы полной ширины. Если вы видите только «успешное совпадение» и отпускаете его, легко считать попадание подстроки всем полем, соответствующим протоколу. Эта статья подойдет разработчикам, которым необходимо проверять номера, такие как AB-1234, а также тем, кто защищает идентификаторы во время перевода документов или обработки данных. После прочтения вы сможете различать проверку формата и проверку всей строки, а также устанавливать четкие стратегии обработки для ситуаций полной ширины, новой строки, регистра и т. д.
В примерах в этой статье используются синтетические образцы, а код был проверен на образцах в изолированной среде, но это не является гарантией всех реальных файлов или эффектов продукта. Перед обработкой важных документов, пожалуйста, сохраните оригиналы и просмотрите их по границам и пунктам приема в тексте.
Используйте регулярные выражения для проверки чисел. Что делать с символами полной ширины? Вывод в одно предложение
Сначала уточним правила: две заглавные латинские буквы, тире и четыре цифры ASCII, общей длиной семь символов. Полноширинные символы напрямую отклоняются, а затем решается, нормализовать ли их.
| твоя ситуация | Рекомендуемые практики | причина |
|---|---|---|
| Необходимо подтвердить, что вся строка полностью соответствует протоколу нумерации. | Ограничить длину и режим одновременно | pattern схемы JSON по умолчанию требует только того, чтобы совпадение было найдено в строке. |
| Ввод может иметь завершающую новую строку или префикс. | Определите, следует ли удалять по четко введенному протоколу и не освобождать его автоматически. | Попадание подстроки не равно всему полю, соответствующему протоколу. |
| Введите полноразмерные буквы или цифры. | Сначала отклонить, стратегия нормализации определяется отдельно | Отклонение легче устранить, чем автоматическое преобразование. |
| Различные модули обрабатывают каждый половину | Объединены в четкий набор стратегий | Децентрализованная обработка затруднит устранение неполадок. |
Длина и режим должны ограничиваться отдельно
pattern в схеме JSON обычно указывает, что регулярное выражение может найти совпадение в строке, и не подразумевает совпадение всей строки. Для этой статьи требуются две заглавные латинские буквы, тире и четыре цифры ASCII общей длиной семь символов. Одновременная установка длины и режима может прояснить область действия этого конкретного протокола.
Обычные реализации различаются в зависимости от языка, особенно привязки, классы символов Юникода и экранирование. Не объявляйте напрямую выражение для конкретного языка, которое будет поддерживаться всеми реализациями схемы JSON.
Тест с похожими контрпримерами
from jsonschema import Draft202012Validator
schema = {"type": "string", "minLength": 7, "maxLength": 7,
"pattern": "[A-Z]{2}-[0-9]{4}"}
validator = Draft202012Validator(schema)
valid = lambda x: not list(validator.iter_errors(x))
assert valid("AB-1234")
assert not valid("prefix-AB-1234")
assert not valid("AB-1234\n")
assert not valid("ＡＢ-1234")
assert not valid("AB-１２３４")
assert not valid("ab-1234")Это правило отклоняет полноширинные символы вместо их автоматической нормализации. Другая система может выбрать нормализацию, а затем проверку, но должна сохранить как исходное значение, так и запись преобразования. Оба метода представляют собой четкие стратегии, в которых легче устранить неполадки, чем выполнять половину из них в разных модулях.
Тот факт, что файл не соответствует формату, не означает, что его можно случайно исправить.
| входить | Результат этого примера | Необязательные последующие действия |
|---|---|---|
| АБ-1234 | проходить | Проверьте еще раз, существует ли этот номер в компании. |
| с завершающей новой строкой | отклонять | Определите, следует ли удалять в соответствии с явным протоколом ввода |
| Полноразмерный буквенно-цифровой | отклонять | Стратегии нормализации должны определяться отдельно. |
| Несоответствие регистра | отклонять | Не используйте автоматическую капитализацию по неизвестным правилам |
Правильный формат — это только первая проверка
Регулярное выражение не может доказать, что номер действительно существует, а также не может доказать, что он принадлежит текущему клиенту или соответствует текущему документу. После того как OCR распознает O как 0, строка все еще может соответствовать определенному широкому шаблону. Поля с высоким риском должны проверять местоположение источника и бизнес-данные, а результаты проверки формата не могут напрямую рассматриваться как «правильно извлеченные».
Считайте идентификаторы защищенным контентом при переводе
В рабочих процессах перевода документов нумерацию часто необходимо сохранять как есть. При оценке вывода OmniDoc (портал продуктов) вы можете использовать этот тип контракта, чтобы проверить, является ли идентификатор полной шириной, изменен ли регистр или отсутствуют ли символы, а затем вернуться к исходному тексту для подтверждения. Правила проверки в этой статье относятся к вашему соглашению о доставке, а не к внутренним инструкциям по реализации платформы.
Источники: Строковая схема JSON Schema
📊 Сравнение ядра
| стратегия обработки | упражняться | Применимые точки |
|---|---|---|
| Отказаться от полной ширины | Если входные данные содержат символы полной ширины, они будут напрямую оценены как неудачные. | Правила просты и позволяют легко устранить неполадки. |
| Проверка после нормализации | Сначала преобразуйте в половинную ширину, а затем проверьте | Необходимо сохранить как исходное значение, так и запись о конверсии. |
| Сделайте половину каждого модуля. | Каждый модуль обрабатывает некоторые правила отдельно. | Не рекомендуется, сложно равномерно проверить |
🎯 Какой метод подходит вам?
Если вам нужно строго проверить номер
Также установите длину и режим и подтвердите привязку регулярного выражения и поведение класса символов в целевой реализации.
Если ваш ввод может содержать символы полной ширины
Сначала выберите стратегию отклонения или нормализации и запишите ее в документации.
Если вы обрабатываете результаты сканирования или распознавания текста
После передачи формата его все равно необходимо вернуть в исходное местоположение для проверки, а поля с высоким риском требуют бизнес-проверки.
❓ Часто задаваемые вопросы (FAQ)
1. Будет ли pattern в схеме JSON требовать сопоставления всей строки?
Это не значение по умолчанию. Обычно это означает, что совпадение можно найти в строке, поэтому необходимо использовать ограничение длины для ограничения общего диапазона.
2. Следует ли удалять разрывы строк непосредственно из чисел с конечными разрывами строк?
Его не следует выпускать автоматически, а решение об удалении должно приниматься в соответствии с четким входным протоколом.
3. Следует ли отклонять или нормализовать полноширинные символы?
Обе стратегии ясны. Пример в этой статье выбирает отклонение, и другая система может нормализовать, но исходные значения и записи преобразования должны быть сохранены.
4. Проверка формата пройдена, значит ли это, что номер правильный?
не могу. Регулярные выражения могут только проверять формат, но не могут доказать, что номер действительно существует или принадлежит текущему клиенту и документу.
📝 Резюме
Проверка номера сначала различает проверку формата и проверку всей строки, а затем устанавливает единую стратегию для полной ширины, разрывов строк и регистра. После того, как формат будет передан, вам все равно придется вернуться к источнику и проверить бизнес-данные.
Попробуйте сейчас: загрузите документ, чтобы начать перевод, сохранив исходный макет.
