Before using a regular expression to validate the number, first think carefully about what to do with full-width characters.

This paper uses synthetic samples to demonstrate the processing method. The code has been verified using examples in an isolated environment; this does not guarantee effectiveness for all real files or products. Before processing important files, please retain the original copies and verify them against the boundaries and acceptance criteria outlined in this document. number AB-1234 looks simple, but the actual input may contain prefixes, trailing line breaks, or full-width characters. Writing just one regular expression and allowing it to pass as long as “match succeeds” can easily lead to mistakenly treating a substring match as the entire field complying with the protocol. length is constrained separately from the pattern JSON Schema's pattern typically indicates that a regular expression can find a match within a string, without implying a full-string match. This paper specifies two uppercase Latin letters, a hyphen, and four ASCII digits, for a total length of seven characters. At the same time, by setting both the length and the pattern, we can clearly define the scope of this particular protocol. Regular expression implementations vary across different languages, particularly with respect to anchors, Unicode character classes, and escaping. Do not assert that a language-specific construct is universally supported by all JSON Schema implementations. Test with seemingly close counterexamples 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") This rule chooses to reject full-width characters rather than performing automatic normalization. Another system might opt to validate after normalization, but should simultaneously retain both the original value and the conversion log. Both approaches represent clear-cut strategies, which are easier to troubleshoot than splitting the workload between different modules. not conforming to the format does not mean it can be arbitrarily modified input This example's result subsequent optional actions AB-1234 via then checks whether this ID exists in the business system with a line break at the end rejects Whether to remove it is determined according to the explicit input protocol. full-width alphanumeric rejects The normalization strategy should be defined separately. case mismatch rejects is not automatically capitalized under unknown rules is correctly formatted—this is only the first check for regular expression cannot prove the existence of the ID, nor can it verify that it belongs to the current customer or corresponds to the current document. OCR converts O becomes 0 Afterward, the string may still satisfy some broad pattern. High-risk fields require source-location and business validation; the format-checking result must not be directly displayed as “extraction successful.” treats the identifier as protected content during translation In the document translation workflow, numbering typically needs to be preserved exactly as is. Evaluate OmniDoc (Product Entry) When outputting, you may use such contracts to check whether identifiers have been converted to full-width characters, undergone case changes, or experienced character omissions, and then return to the original text for verification. The checking rules outlined in this document are part of your delivery agreement, not an internal implementation guideline of the platform. Reference: JSON Schema string pattern 。 - 1 -