Než použijete regulární výrazy k ověření čísel, nejprve se zamyslete nad tím, co dělat se znaky s plnou šířkou.
Číslo `AB-1234` vypadá jednoduše, ale skutečný vstup může mít předpony, koncové nové řádky nebo znaky plné šířky. Stačí napsat běžné pravidlo a poté jej nechat být, když uvidíte „shoda úspěšně“. Je snadné zaměnit podřetězcový zásah jako celé pole vyhovující protokolu.
Při psaní běžného kontrolního čísla může vstup obsahovat předpony, koncové nové řádky nebo znaky s plnou šířkou. Pokud vidíte pouze „shoda úspěšně"a necháte to být, je snadné považovat zásah podřetězce za celé pole vyhovující protokolu. Tento článek je vhodný pro vývojáře, kteří potřebují ověřit čísla, jako jeAB-1234, a také pro ty, kteří chrání identifikátory během překladu dokumentů nebo zpracování dat. Po přečtení budete schopni rozlišit mezi kontrolou formátu a ověřením celého řetězce a nastavit jasné strategie zpracování pro situace plné šířky, nového řádku, případu atd.
Příklady v tomto článku používají syntetické vzorky a kód byl ukázkově zkontrolován v izolovaném prostředí, ale to nepředstavuje záruku všech skutečných souborů nebo efektů produktu. Před zpracováním důležitých dokumentů si prosím uschovejte originály a zkontrolujte je podle hranic a přejímacích položek v textu.
Použijte regulární výrazy k ověření čísel, co dělat se znaky s plnou šířkou? Závěr jednou větou
Nejprve si ujasněte pravidla: dvě velká latinská písmena, pomlčka a čtyři číslice ASCII o celkové délce sedmi znaků. Znaky plné šířky jsou přímo odmítnuty a poté se rozhodněte, zda je chcete normalizovat.
| vaší situaci | Doporučené postupy | důvod |
|---|---|---|
| Je třeba potvrdit, že celý řetězec plně vyhovuje číslovacímu protokolu | Omezte délku a režim současně | pattern schématu JSON ve výchozím nastavení vyžaduje pouze nalezení shody v řetězci |
| Vstup může mít na konci nový řádek nebo předponu | Podle jasně zadaného protokolu určete, zda odebírat a nepouštějte jej automaticky. | Shoda podřetězce se nerovná celému poli odpovídajícímu protokolu |
| Zadejte písmena nebo čísla plné šířky | Nejprve odmítněte, normalizační strategie je definována samostatně | Odmítnutí se řeší snadněji než automatický převod |
| Různé moduly každý zpracovávají polovinu | Sjednocené do jasné sady strategií | Decentralizované zpracování ztíží odstraňování problémů |
Délka a režim by měly být omezeny samostatně
pattern ve schématu JSON obvykle označuje, že regulární výraz může najít shodu v řetězci, a neznamená shodu celého řetězce. Tento článek vyžaduje dvě velká písmena latinky, pomlčku a čtyři číslice ASCII o celkové délce sedmi znaků. Nastavení délky a režimu současně může objasnit rozsah tohoto specifického protokolu.
Běžné implementace se mezi jazyky liší, zejména kotvy, třídy znaků Unicode a escapování. Nedeklarujte přímo výraz specifický pro daný jazyk, který bude podporován všemi implementacemi schématu JSON.
Test s podobnými protipříklady
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("AB-1234")
assert not valid("AB-1234")
assert not valid("ab-1234")
Toto pravidlo se rozhodne odmítnout znaky s plnou šířkou namísto jejich automatické normalizace. Jiný systém se může rozhodnout pro normalizaci a následné ověření, ale měl by zachovat jak původní hodnotu, tak záznam o převodu. Obě metody jsou jasné strategie, které se snáze řeší než polovina z nich v různých modulech.
To, že to neodpovídá formátu, neznamená, že to může být náhodně opraveno.
| vstoupit | Výsledek tohoto příkladu | Volitelné následné akce |
|---|---|---|
| AB-1234 | přihrávka | Znovu zkontrolujte, zda toto číslo ve firmě existuje |
| s koncovým novým řádkem | odmítnout | Určete, zda chcete odebrat podle explicitního vstupního protokolu |
| Alfanumerický v plné šířce | odmítnout | Normalizační strategie by měly být definovány samostatně |
| Neshoda případu | odmítnout | Nepište velká písmena automaticky podle neznámých pravidel |
Správný formát je pouze první kontrolou
Regulární výraz nemůže prokázat, že číslo skutečně existuje, ani nemůže prokázat, že patří aktuálnímu zákazníkovi nebo odpovídá aktuálnímu dokladu. Poté, co OCR rozpozná O jako 0, může řetězec stále splňovat určitý široký vzor. Vysoce riziková pole potřebují zkontrolovat zdrojové umístění a obchodní data a výsledky kontroly formátu nelze přímo považovat za „správně extrahované".
Při překladu zacházejte s identifikátory jako s chráněným obsahem
V pracovních postupech překladu dokumentů je často třeba zachovat číslování tak, jak je. Při vyhodnocování výstupu OmniDoc (produktový portál) můžete tento typ smlouvy použít ke kontrole, zda má identifikátor plnou šířku, změněná velká a malá písmena nebo chybějící znaky, a pak se vrátit k původnímu textu pro potvrzení. Pravidla kontroly v tomto článku patří k vaší smlouvě o dodání, nikoli k interním implementačním pokynům platformy.
Zdroje: Schéma řetězce JSON Schema
📊 Srovnání jádra
| strategii zpracování | praxe | Použitelné body |
|---|---|---|
| Odmítněte celou šířku | Pokud vstup obsahuje znaky plné šířky, bude přímo posouzen jako neúspěšný. | Pravidla jsou jednoduchá a snadno se řeší |
| Ověření po normalizaci | Nejprve převeďte na poloviční šířku a poté ověřte | Je třeba zachovat původní hodnotu i záznam o převodu |
| Udělejte polovinu každého modulu | Každý modul zpracovává některá pravidla samostatně | Nedoporučuje se, je obtížné jednotně zkontrolovat |
🎯 Která metoda je pro vás vhodná?
Pokud potřebujete přísně ověřit číslo
Nastavte také délku a režim a potvrďte chování kotvy a znakové třídy regulárního výrazu v cílové implementaci.
Pokud váš vstup může obsahovat znaky plné šířky
Nejprve zvolte strategii odmítnutí nebo normalizace a zapište ji do dokumentace.
Pokud zpracováváte skeny nebo výsledky OCR
Po předání formátu je stále nutné jej vrátit do zdrojového umístění k ověření a vysoce riziková pole vyžadují ověření firmy.
❓ Často kladené otázky (FAQ)
1. Bude pattern schématu JSON vyžadovat shodu celého řetězce?
Toto není výchozí nastavení, obvykle to znamená, že v řetězci lze najít shodu, takže k omezení celkového rozsahu je třeba použít omezení délky.
2. Měly by být konce řádků odstraněny přímo z čísel se zalomením na konci?
Nemělo by se uvolňovat automaticky a o odstranění by mělo být rozhodnuto podle jasného vstupního protokolu.
3. Měly by být znaky plné šířky odmítnuty nebo normalizovány?
Obě jsou jasné strategie. Příklad v tomto článku se rozhodne odmítnout a jiný systém se může normalizovat, ale musí být zachovány původní hodnoty a záznamy převodu.
4. Kontrola formátu proběhla úspěšně, znamená to, že je číslo správné?
nemůže. Regulární výrazy mohou pouze zkontrolovat formát, ale nemohou prokázat, že číslo skutečně existuje nebo patří aktuálnímu zákazníkovi a dokumentu.
📝 Shrnutí
Ověření čísel nejprve rozlišuje kontrolu formátu a ověření celého řetězce a poté nastaví jednotnou strategii pro plnou šířku, zalomení řádků a velká a malá písmena. Po předání formátu se stále musíte vrátit ke zdroji a zkontrolovat obchodní data.
Vyzkoušejte to hned: Nahrajte dokument a začněte překládat při zachování původního rozvržení


