OmniDocTrước khi sử dụng biểu thức chính quy để xác minh số, trước tiên hãy nghĩ xem phải làm gì với các ký tự có độ rộng đầy đủ.
Số `AB-1234` trông đơn giản nhưng dữ liệu đầu vào thực sự có thể có tiền tố, dòng mới ở cuối hoặc ký tự có độ rộng đầy đủ. Chỉ cần viết một quy tắc thông thường và sau đó bỏ qua nó khi bạn thấy "khớp thành công". Rất dễ nhầm lần truy cập chuỗi con là toàn bộ trường tuân theo giao thức.
Khi viết số kiểm tra thông thường, đầu vào có thể chứa tiền tố, dòng mới ở cuối hoặc ký tự có độ rộng đầy đủ. Nếu bạn chỉ thấy "khớp thành công" và để nó vượt qua, thì rất dễ coi lần truy cập chuỗi con là toàn bộ trường tuân thủ giao thức. Bài viết này phù hợp với những nhà phát triển cần xác minh các con số như AB-1234, cũng như những người bảo vệ mã định danh trong quá trình dịch tài liệu hoặc xử lý dữ liệu. Sau khi đọc, bạn sẽ có thể phân biệt giữa kiểm tra định dạng và xác minh toàn bộ chuỗi, đồng thời đặt chiến lược xử lý rõ ràng cho các tình huống có độ rộng đầy đủ, dòng mới, viết hoa, v.v.
Các ví dụ trong bài viết này sử dụng các mẫu tổng hợp và mã đã được kiểm tra mẫu trong môi trường biệt lập nhưng điều này không thể hiện sự đảm bảo về tất cả các tệp thực hoặc hiệu ứng sản phẩm. Trước khi xử lý các văn bản quan trọng, vui lòng giữ lại bản chính và xem xét theo ranh giới và các mục chấp nhận trong văn bản.
Sử dụng biểu thức chính quy để xác minh số, phải làm gì với ký tự có độ rộng đầy đủ? Một câu kết luận
Đầu tiên hãy làm rõ các quy tắc: hai chữ cái Latinh viết hoa, một dấu gạch ngang và bốn chữ số ASCII, với tổng chiều dài là bảy ký tự. Các ký tự có độ rộng đầy đủ sẽ bị từ chối trực tiếp và sau đó quyết định xem có bình thường hóa hay không.
| hoàn cảnh của bạn | Các phương pháp được đề xuất | lý do |
|---|---|---|
| Cần xác nhận rằng toàn bộ chuỗi tuân thủ đầy đủ giao thức đánh số | Hạn chế độ dài và chế độ đồng thời | pattern của Lược đồ JSON theo mặc định chỉ yêu cầu có thể tìm thấy kết quả khớp trong chuỗi |
| Đầu vào có thể có dòng mới hoặc tiền tố | Xác định xem có nên gỡ bỏ theo giao thức đã nhập rõ ràng hay không và không tự động giải phóng nó. | Lần truy cập chuỗi con không bằng toàn bộ trường tuân theo giao thức |
| Nhập các chữ cái hoặc số có độ rộng đầy đủ | Từ chối trước, chiến lược chuẩn hóa được xác định riêng | Việc từ chối dễ khắc phục sự cố hơn so với chuyển đổi tự động |
| Các mô-đun khác nhau, mỗi mô-đun xử lý một nửa công việc | Thống nhất thành một bộ chiến lược rõ ràng | Xử lý phi tập trung sẽ khiến việc khắc phục sự cố trở nên khó khăn hơn |
Độ dài và chế độ phải được hạn chế riêng
pattern trong Lược đồ JSON thường chỉ ra rằng biểu thức chính quy có thể tìm thấy kết quả khớp trong chuỗi và không ngụ ý khớp toàn bộ chuỗi. Bài viết này yêu cầu hai chữ cái Latinh viết hoa, một dấu gạch ngang và bốn chữ số ASCII để có tổng chiều dài bảy ký tự. Việc đặt đồng thời độ dài và chế độ có thể làm rõ phạm vi của giao thức cụ thể này.
Việc triển khai thường xuyên khác nhau giữa các ngôn ngữ, đặc biệt là các neo, các lớp ký tự Unicode và lối thoát. Không trực tiếp khai báo một biểu thức theo ngôn ngữ cụ thể sẽ được hỗ trợ bởi tất cả quá trình triển khai Lược đồ JSON.
Thử nghiệm với các phản ví dụ tương tự
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")Quy tắc này chọn từ chối các ký tự có độ rộng đầy đủ thay vì tự động chuẩn hóa chúng. Một hệ thống khác có thể chọn chuẩn hóa rồi xác minh nhưng phải giữ lại cả giá trị ban đầu và bản ghi chuyển đổi. Cả hai phương pháp đều là những chiến lược rõ ràng, dễ khắc phục sự cố hơn so với thực hiện một nửa trong số chúng trong các mô-đun khác nhau.
Chỉ vì nó không phù hợp với định dạng không có nghĩa là nó có thể được sửa chữa một cách ngẫu nhiên.
| đi vào | Kết quả của ví dụ này | Các hành động tiếp theo tùy chọn |
|---|---|---|
| AB-1234 | vượt qua | Kiểm tra lại xem con số này có tồn tại trong doanh nghiệp không |
| với dòng mới ở cuối | từ chối | Xác định xem có nên xóa theo giao thức đầu vào rõ ràng hay không |
| Chữ và số có độ rộng đầy đủ | từ chối | Chiến lược bình thường hóa nên được xác định riêng |
| Trường hợp không khớp | từ chối | Không tự động viết hoa theo quy tắc không xác định |
Định dạng đúng chỉ là lần kiểm tra đầu tiên
Biểu thức chính quy không thể chứng minh rằng số đó thực sự tồn tại, cũng như không thể chứng minh rằng nó thuộc về khách hàng hiện tại hoặc tương ứng với tài liệu hiện tại. Sau khi OCR nhận dạng O là 0, chuỗi vẫn có thể đáp ứng một mẫu rộng nhất định. Các trường có rủi ro cao cần kiểm tra vị trí nguồn và dữ liệu kinh doanh, đồng thời kết quả kiểm tra định dạng không thể được coi trực tiếp là "trích xuất chính xác".
Coi số nhận dạng là nội dung được bảo vệ khi dịch
Trong quy trình dịch tài liệu, việc đánh số thường cần được giữ nguyên. Khi đánh giá đầu ra của OmniDoc (cổng thông tin sản phẩm), bạn có thể sử dụng loại hợp đồng này để kiểm tra xem mã định danh có độ rộng đầy đủ, thay đổi kiểu chữ hay ký tự bị thiếu, sau đó quay lại văn bản gốc để xác nhận. Các quy tắc kiểm tra trong bài viết này thuộc về thỏa thuận phân phối của bạn chứ không phải hướng dẫn triển khai nội bộ của nền tảng.
Tham khảo: Lược đồ chuỗi lược đồ JSON
📊 So sánh cốt lõi
| chiến lược xử lý | luyện tập | Điểm áp dụng |
|---|---|---|
| Từ chối toàn bộ chiều rộng | Khi đầu vào chứa các ký tự có độ rộng đầy đủ, nó sẽ bị đánh giá trực tiếp là không thành công. | Các quy tắc rất đơn giản và dễ kiểm tra |
| Xác minh sau khi chuẩn hóa | Chuyển đổi thành nửa chiều rộng trước rồi xác minh | Cần giữ lại cả giá trị ban đầu và bản ghi chuyển đổi |
| Tạo một nửa mỗi mô-đun | Mỗi mô-đun xử lý một số quy tắc riêng biệt | Không khuyến nghị, khó kiểm tra thống nhất |
🎯 Phương pháp nào phù hợp với bạn?
Nếu bạn cần xác minh nghiêm ngặt số lượng
Đồng thời đặt độ dài và chế độ, đồng thời xác nhận hành vi của lớp ký tự và neo của biểu thức chính quy trong quá trình triển khai mục tiêu.
Nếu đầu vào của bạn có thể chứa các ký tự có độ rộng đầy đủ
Đầu tiên hãy chọn chiến lược từ chối hoặc bình thường hóa và viết nó vào tài liệu.
Nếu bạn đang xử lý kết quả quét hoặc OCR
Sau khi định dạng được thông qua, nó vẫn cần được trả về vị trí nguồn để xác minh và các trường có rủi ro cao cần phải được xác minh doanh nghiệp.
❓ Câu hỏi thường gặp (FAQ)
1. pattern của Lược đồ JSON có yêu cầu phải khớp toàn bộ chuỗi không?
Đây không phải là giá trị mặc định, điều này thường có nghĩa là có thể tìm thấy kết quả khớp trong chuỗi, do đó cần sử dụng giới hạn độ dài để giới hạn phạm vi tổng thể.
2. Có nên loại bỏ trực tiếp dấu ngắt dòng khỏi các số có dấu ngắt dòng ở cuối không?
Nó không nên được phát hành tự động và việc loại bỏ phải được quyết định theo một giao thức đầu vào rõ ràng.
3. Nên loại bỏ hay chuẩn hóa các ký tự có độ rộng đầy đủ?
Cả hai đều là những chiến lược rõ ràng. Ví dụ trong bài viết này chọn từ chối và hệ thống khác có thể chuẩn hóa nhưng phải giữ lại các giá trị ban đầu và bản ghi chuyển đổi.
4. Kiểm tra định dạng đã đạt, có nghĩa là số đó đúng?
không thể. Biểu thức chính quy chỉ có thể kiểm tra định dạng chứ không thể chứng minh rằng số đó thực sự tồn tại hoặc thuộc về khách hàng và tài liệu hiện tại.
📝 Tóm tắt
Xác minh số trước tiên phân biệt kiểm tra định dạng và xác minh toàn bộ chuỗi, sau đó đặt chiến lược thống nhất cho toàn bộ chiều rộng, ngắt dòng và viết hoa chữ thường. Sau khi format xong, bạn vẫn phải quay lại nguồn và kiểm tra dữ liệu nghiệp vụ.
Thử ngay: Tải tài liệu lên để bắt đầu dịch, giữ nguyên bố cục ban đầu
