Về tính thực tế của Regex để xử lý địa chỉ email

Một đồng nghiệp gần đây đã chỉ cho tôi một bài đăng trên blog: Về sự vô ích của việc xác thực Regex qua email . Để cho ngắn gọn, tôi sẽ gọi nó là Futility trong bài viết này.

Tôi thừa nhận rằng mặc dù thách thức viết một biểu thức chính quy có thể xác định thành công liệu một chuỗi có tuân theo định nghĩa RFC 5322 của tiêu đề Thư trên Internet hay không là một thách thức thú vị, Futility không phải là hướng dẫn hữu ích cho lập trình viên thực tế.

Điều này là do nó kết hợp các tiêu đề thư RFC 5322 với các ký tự địa chỉ RFC 5321; trong đó, theo ngôn ngữ đơn giản, có nghĩa là những gì cấu thành một địa chỉ email SMTP hợp lệ khác với những gì cấu thành một tiêu đề thư hợp lệ nói chung.

Đó cũng là bởi vì nó kích động người đọc trở nên bận tâm với các trường hợp cạnh mà về mặt lý thuyết là có thể theo quan điểm tiêu chuẩn, nhưng tôi sẽ chứng minh rằng, có xác suất cực nhỏ xảy ra “trong tự nhiên”.

Bài viết này sẽ mở rộng dựa trên cả hai khẳng định này, sẽ thảo luận về một số trường hợp sử dụng có thể có đối với biểu thức chính quy email và sẽ kết thúc bằng các ví dụ “sách dạy nấu ăn” có chú thích về biểu thức chính quy email thực tế.

RFC 5321 Thay thế 5322

Tính phổ biến của SMTP đối với việc truyền email có nghĩa là trên thực tế, không có việc kiểm tra định dạng địa chỉ email nào hoàn tất nếu không đọc kỹ RFC của IETF có liên quan, đó là 5321.

5322 coi địa chỉ email chỉ đơn giản là một tiêu đề thư chung mà không áp dụng quy tắc trường hợp đặc biệt nào cho nó. Điều này có nghĩa là các nhận xét được đặt trong dấu ngoặc đơn là hợp lệ, ngay cả trong một tên miền.

Bộ kiểm tra được tham chiếu trong Futility bao gồm 10 bài kiểm tra chứa nhận xét, dấu phụ hoặc ký tự Unicode và chỉ ra rằng 8 trong số đó đại diện cho địa chỉ email hợp lệ.

Điều này là không chính xác vì RFC 5321 rõ ràng khi tuyên bố rằng các phần tên miền của địa chỉ email “ bị hạn chế cho các mục đích SMTP để bao gồm một chuỗi các chữ cái, chữ số và dấu gạch nối được rút ra từ bộ ký tự ASCII .”

Trong bối cảnh xây dựng một biểu thức chính quy, thật khó để phóng đại mức độ mà ràng buộc này đơn giản hóa các vấn đề, đặc biệt là liên quan đến việc xác định độ dài chuỗi quá mức. Chú thích của các ví dụ sẽ làm nổi bật điều này dưới đây.

Nó cũng ngụ ý một số cân nhắc thực tế khác trong bối cảnh xác thực mà chúng ta sẽ khám phá thêm.

Tên hộp thư trong tự nhiên

Theo cả hai RFC, tên kỹ thuật cho phần địa chỉ email ở bên trái của biểu tượng “@“ là “hộp thư”. Cả hai RFC đều cho phép độ rộng đáng kể trong những ký tự nào được phép trong phần hộp thư.

Hạn chế thực tế quan trọng duy nhất là các dấu ngoặc kép hoặc dấu ngoặc đơn phải được cân bằng, điều gì đó thực sự là một thách thức để xác minh trong biểu thức chính quy vani.

Tuy nhiên, việc triển khai hộp thư trong thế giới thực lại là thước đo mà lập trình viên thực tế nên sử dụng.

Theo quy định, những người trả tiền cho chúng tôi cau mày khi 90% số giờ có thể lập hóa đơn của chúng tôi được hướng đến việc giải quyết 10% các trường hợp cạnh lý thuyết thậm chí có thể không tồn tại trong cuộc sống thực.

Hãy xem xét các nhà cung cấp hộp thư email, người tiêu dùng và doanh nghiệp chiếm ưu thế và xem xét loại địa chỉ email nào họ cho phép.

Đối với email của người tiêu dùng, tôi đã thực hiện một số nghiên cứu sơ bộ, sử dụng danh sách 5.280.739 địa chỉ email đã bị rò rỉ từ các tài khoản Twitter.

Dựa trên 115 triệu tài khoản Twitter, điều này mang lại cho chúng tôi mức độ tin cậy 99% với sai số 0,055% đối với toàn bộ người dùng Twitter, điều này sẽ rất đại diện cho người dùng nói chung của tất cả các địa chỉ email trên Internet. Đây là những gì tôi học được:

• 82% địa chỉ chỉ chứa các ký tự chữ và số ASCII,

• 15% chỉ chứa chữ và số ASCII và dấu chấm (dấu chấm ASCII), cho 97% tất cả các địa chỉ,

• 3% chỉ chứa chữ và số ASCII, dấu chấm và dấu gạch ngang, cho 100% địa chỉ email danh nghĩa.

Tuy nhiên, đây là 100% được làm tròn. Đối với những người yêu thích câu đố ngoài kia, tôi cũng tìm thấy:

• 38 địa chỉ có dấu gạch dưới chiếm 0,00072% tổng số

• 27 với dấu cộng cho 0,00051% và

• 1 với các ký tự Unicode chiếm 0,00002% trên tổng số.

Hiệu quả cuối cùng là giả sử hộp thư địa chỉ email chỉ chứa chữ và số ASCII, dấu chấm và dấu gạch ngang sẽ cung cấp cho bạn độ chính xác cao hơn 5 9 đối với email của người tiêu dùng.

Đối với email doanh nghiệp, Datanyze báo cáo rằng 6.771.269 công ty sử dụng 91 giải pháp lưu trữ email khác nhau. Tuy nhiên, phân phối Pareto vẫn giữ nguyên và 95,19% trong số các hộp thư đó chỉ được lưu trữ bởi 10 nhà cung cấp dịch vụ.

Gmail dành cho Doanh nghiệp (34,35% Thị phần)

Google chỉ cho phép các chữ cái, số và dấu chấm ASCII khi tạo hộp thư. Tuy nhiên, nó sẽ chấp nhận dấu cộng khi nhận email .

Microsoft Exchange trực tuyến (33,60%)

Chỉ cho phép các chữ cái, số và dấu chấm ASCII.

Dịch vụ lưu trữ email của GoDaddy (14,71%)

Sử dụng Microsoft 365 và chỉ cho phép các chữ cái, số và dấu chấm ASCII.

7 Nhà cung cấp khác (12,53%)

Không có tài liệu.

Thật không may, chúng tôi chỉ có thể chắc chắn về 82% doanh nghiệp và chúng tôi không biết có bao nhiêu hộp thư đại diện. Tuy nhiên, chúng tôi biết rằng trong số các địa chỉ email Twitter, chỉ có 400 trong số 173.467 tên miền có hơn 100 hộp thư email riêng lẻ được đại diện.

Tôi tin rằng hầu hết 99% tên miền còn lại là địa chỉ email doanh nghiệp.

Về chính sách đặt tên hộp thư ở cấp máy chủ hoặc cấp miền, tôi đề xuất rằng việc lấy 237.592 địa chỉ email này làm đại diện cho tổng số 1 tỷ địa chỉ email doanh nghiệp với mức độ tin cậy 99% và sai số 0,25% là hợp lý. gần với 3 số 9 khi giả định rằng hộp thư địa chỉ email chỉ chứa chữ và số ASCII, dấu chấm và dấu gạch ngang.

Trường hợp sử dụng

Một lần nữa, với tính thực tế là ưu tiên hàng đầu trong tâm trí của chúng tôi, chúng ta hãy xem xét trong những trường hợp nào chúng ta có thể cần xác định một địa chỉ email hợp lệ theo chương trình.

Tạo tài khoản mới/Đăng ký người dùng

Trong trường hợp sử dụng này, một khách hàng tiềm năng mới đang cố gắng tạo một tài khoản. Có hai chiến lược cấp cao mà chúng ta có thể xem xét. Trong trường hợp đầu tiên, chúng tôi cố gắng xác minh rằng địa chỉ email mà người dùng mới cung cấp là hợp lệ và tiến hành tạo tài khoản một cách đồng bộ.

Có hai lý do tại sao bạn có thể không muốn thực hiện phương pháp này. Đầu tiên là mặc dù bạn có thể xác thực rằng địa chỉ email có dạng hợp lệ, nhưng nó vẫn có thể không tồn tại.

Lý do khác là ở bất kỳ loại quy mô nào, đồng bộ là một từ cờ đỏ, điều này sẽ khiến lập trình viên thực dụng xem xét thay vào đó là mô hình cháy và quên trong đó giao diện người dùng web không trạng thái chuyển thông tin biểu mẫu tới microservice hoặc API sẽ xác thực email không đồng bộ bằng cách gửi một liên kết duy nhất sẽ kích hoạt quá trình tạo tài khoản hoàn tất.

Biểu mẫu liên hệ

Trong trường hợp biểu mẫu liên hệ đơn giản, thuộc loại thường được sử dụng để tải xuống sách trắng, nhược điểm tiềm ẩn của việc chấp nhận các chuỗi trông giống như email hợp lệ nhưng không phải là bạn đang làm giảm chất lượng cơ sở dữ liệu tiếp thị của mình do không xác thực nếu địa chỉ email thực sự tồn tại.

Vì vậy, một lần nữa, mô hình bắn và quên là một lựa chọn tốt hơn so với xác thực theo chương trình của chuỗi được nhập trong một biểu mẫu.

Phân tích nhật ký người giới thiệu và khối lượng dữ liệu lớn khác.

Điều này dẫn chúng ta đến trường hợp sử dụng thực tế để nhận dạng địa chỉ email có lập trình nói chung và regex nói riêng: ẩn danh hoặc khai thác các khối lớn văn bản phi cấu trúc.

Lần đầu tiên tôi bắt gặp trường hợp sử dụng này là hỗ trợ một nhà nghiên cứu bảo mật, người cần tải nhật ký liên kết giới thiệu lên cơ sở dữ liệu phát hiện gian lận. Nhật ký người giới thiệu chứa các địa chỉ email cần được ẩn danh trước khi rời khỏi khu vườn có tường bao quanh của công ty.

Đây là những tệp có hàng trăm triệu dòng và có hàng trăm tệp mỗi ngày. “Dòng” có thể dài gần một nghìn ký tự.

Lặp lại các ký tự trong một dòng, áp dụng các kiểm tra phức tạp (ví dụ: đây có phải là lần xuất hiện đầu tiên của @ trong dòng và nó có phải là một phần của tên tệp chẳng hạn như [email protected] ?) bằng cách sử dụng các vòng lặp và các hàm chuỗi tiêu chuẩn sẽ được tạo một sự phức tạp về thời gian lớn không thể tin được.

Trên thực tế, nhóm phát triển nội bộ của công ty (rất lớn) này đã tuyên bố đây là một nhiệm vụ bất khả thi.

Tôi đã viết regex được biên dịch sau đây:

search_pattern = re.compile("[a-zA-Z0-9\!\#\$\%\'\*\+\-\^\_\`\{\|\}\~\.]+@|\%40(?!(\w+\.)**(jpg|png))(([\w\-]+\.)+([\w\-]+)))")

Và thả nó vào phần hiểu danh sách Python sau:

results = [(re.sub(search_pattern, "[email protected]", line)) for line in file]

Tôi không thể nhớ nó nhanh như thế nào, nhưng nó rất nhanh. Bạn tôi có thể chạy nó trên máy tính xách tay và hoàn thành trong vài phút. Đó là chính xác. Chúng tôi đã xem xét nó ở mức 5 giờ 9 khi xem xét cả âm tính giả và dương tính giả.

Công việc của tôi trở nên dễ dàng hơn nhờ nhật ký người giới thiệu; chúng chỉ có thể chứa các ký tự "hợp lệ" của URL, vì vậy tôi có thể vạch ra bất kỳ xung đột nào mà tôi đã ghi lại trong repo readme .

Ngoài ra, tôi thậm chí có thể làm cho nó đơn giản hơn (và nhanh hơn) nếu tôi đã thực hiện phân tích địa chỉ email và biết được với sự đảm bảo rằng tất cả những gì cần thiết để đến đích của 5 9 là chữ và số ASCII, dấu chấm và dấu gạch ngang.

Tuy nhiên, đây là một ví dụ tốt về tính thực tế và xác định phạm vi của giải pháp để phù hợp với vấn đề thực tế cần giải quyết.

Một trong những câu trích dẫn hay nhất trong lịch sử và truyền thuyết lập trình là lời khuyên của Ward Cunningham vĩ đại rằng hãy dành một giây để ghi nhớ chính xác những gì bạn đang cố gắng hoàn thành, sau đó tự hỏi bản thân “Điều đơn giản nhất có thể hoạt động là gì?”

Trong trường hợp sử dụng phân tích cú pháp (và tùy chọn chuyển đổi) một địa chỉ email từ một lượng lớn văn bản phi cấu trúc, giải pháp này chắc chắn là điều đơn giản nhất mà tôi có thể nghĩ ra.

Sách dạy nấu ăn có chú thích

Như tôi đã nói lúc đầu, tôi thấy ý tưởng xây dựng một biểu thức chính quy tuân thủ RFC 5322 rất thú vị, vì vậy tôi sẽ chỉ cho bạn các khối biểu thức chính có thể kết hợp để giải quyết các khía cạnh khác nhau của tiêu chuẩn và giải thích cách chính sách biểu thức chính quy đó. Cuối cùng, tôi sẽ cho bạn thấy tất cả được lắp ráp trông như thế nào.

Cấu trúc của một địa chỉ email là:

1. Hộp thư
2. nhân vật pháp lý
3. Chấm đơn (chấm kép không hợp pháp)
4. Khoảng trắng được gấp lại (RFC 5322 điên rồ)
5. (Một giải pháp regex hoàn chỉnh cũng sẽ bao gồm dấu ngoặc đơn cân bằng và/hoặc dấu ngoặc kép, nhưng tôi chưa có. Và rất có thể sẽ không bao giờ có.)
6. Dấu phân cách (@)
7. tên miền
8. Tên miền có thể phân tích cú pháp dns tiêu chuẩn
9. Địa chỉ IPv4 bằng chữ
10. Địa chỉ IPv6 bằng chữ
11. IPv6 đầy đủ
12. IPv6-comp (để nén)
13. Dạng thứ nhất (2+ nhóm 16-bit số 0 ở giữa)
14. Dạng thứ 2 (2+ nhóm 16-bit của số 0 ở đầu)
15. dạng thứ 3 (2 nhóm 16-bit của số 0 ở cuối)
16. Dạng thứ 4 (8 nhóm 16-bit của số 0)
17. IPv6v4 đầy đủ
18. IPv6v4-comp (nén)
19. hình thức đầu tiên
20. mẫu thứ 2
21. mẫu thứ 3
22. mẫu thứ 4

Bây giờ cho regex.

Hộp thư

^(?<mailbox>(\[a-zA-Z0-9\\+\\!\\#\\$\\%\\&\\'\\\*\\-\\/\\=\\?\\+\\\_\\\{\\}\\|\\\~]|(?<singleDot>(?<!\\.)(?<!^)\\.(?!\\.))|(?<foldedWhiteSpace>\\s?\\&\\#13\\;\\&\\#10\\;.))\{1,64})

Đầu tiên, chúng ta có ^ which “neo” ký tự đầu tiên ở đầu chuỗi. Điều này được sử dụng nếu xác thực một chuỗi được cho là không chứa gì ngoài một email hợp lệ. Nó đảm bảo rằng ký tự đầu tiên là hợp lệ.

Thay vào đó, nếu trường hợp sử dụng là tìm một email trong một chuỗi dài hơn, hãy bỏ qua dấu neo.

Tiếp theo, chúng ta có (?<mailbox> . Cái này đặt tên cho nhóm chụp để thuận tiện. Bên trong nhóm chụp là ba khối biểu thức chính quy được phân tách bằng ký hiệu khớp thay thế | có nghĩa là một ký tự có thể khớp với bất kỳ một trong ba biểu thức.

Một phần của việc viết biểu thức chính quy tốt (hiệu quả và có thể dự đoán được) là đảm bảo rằng ba biểu thức loại trừ lẫn nhau. Điều đó có nghĩa là một chuỗi con khớp với một, chắc chắn sẽ không khớp với một trong hai chuỗi còn lại. Để làm điều này, chúng tôi sử dụng các lớp ký tự cụ thể thay vì .* đáng sợ.

Nhân vật hợp pháp vô điều kiện

[a-zA-Z0-9\+\!\#\$\%\&\'\*\-\/\=\?\+\_\{\}\|\~]

Khớp thay thế đầu tiên là một lớp ký tự được đặt trong dấu ngoặc vuông, ghi lại tất cả các ký tự ASCII hợp lệ trong hộp thư email ngoại trừ dấu chấm, “khoảng trắng được gấp lại”, dấu ngoặc kép và dấu ngoặc đơn.

Lý do tại sao chúng tôi loại trừ chúng là vì chúng chỉ hợp pháp có điều kiện , nghĩa là có các quy tắc về cách bạn có thể sử dụng chúng phải được xác thực. Chúng tôi xử lý chúng trong 2 trận luân phiên tiếp theo.

chấm đơn

(?<singleDot>(?<!\.)(?<!^)\.(?!\.))

Quy tắc đầu tiên như vậy liên quan đến dấu chấm (dấu chấm). Trong hộp thư, dấu chấm chỉ được phép làm dấu phân cách giữa hai chuỗi ký tự hợp pháp, vì vậy hai dấu chấm liên tiếp là không hợp lệ.

Để ngăn khớp nếu có hai dấu chấm liên tiếp, chúng tôi sử dụng giao diện phủ định regex (?<!\.) chỉ định rằng ký tự tiếp theo (dấu chấm) sẽ không khớp nếu có dấu chấm trước nó.

Regex nhìn xung quanh có thể được xâu chuỗi. Có một cái nhìn tiêu cực khác trước khi chúng ta đến dấu chấm (?!^) thực thi quy tắc rằng dấu chấm không thể là ký tự đầu tiên của hộp thư.

Sau dấu chấm, có một look_ahead_ _(?!\.)_ phủ định , điều này ngăn không cho một dấu chấm được khớp nếu ngay sau nó là một dấu chấm.

gấp lạiTrắngSpace

(?<foldedWhiteSpace>\s?\&\#13\;\&\#10\;.)

Đây là một số RFC 5322 vô nghĩa về việc cho phép các tiêu đề nhiều dòng trong thư. Tôi sẵn sàng cá rằng trong lịch sử địa chỉ email, chưa từng có ai nghiêm túc tạo địa chỉ với hộp thư nhiều dòng (họ có thể làm điều đó như một trò đùa).

Nhưng tôi đang chơi trò chơi 5322 nên đây là chuỗi ký tự Unicode tạo ra Khoảng trắng được gấp làm đối sánh thay thế.

Dấu ngoặc kép cân bằng và dấu ngoặc đơn

Cả RFC đều cho phép sử dụng dấu ngoặc kép như một cách để bao quanh (hoặc thoát ) các ký tự thường là bất hợp pháp.

Chúng cũng cho phép đặt các nhận xét trong ngoặc đơn để chúng có thể đọc được bằng con người nhưng không được tác nhân chuyển thư (MTA) xem xét khi diễn giải địa chỉ.

Trong cả hai trường hợp, các ký tự chỉ hợp pháp nếu cân bằng . Điều này có nghĩa là phải có một cặp ký tự, một ký tự mở và một ký tự đóng .

Tôi rất muốn viết rằng tôi đã phát hiện ra một cuộc biểu tình mirablem , tuy nhiên, điều này có lẽ chỉ hoạt động sau khi di cảo. Sự thật là điều này không tầm thường trong biểu thức chính quy vani.

Tôi có trực giác rằng bản chất đệ quy của biểu thức chính quy “tham lam” có thể bị lợi dụng, tuy nhiên, tôi không có khả năng dành thời gian cần thiết để tấn công vấn đề này trong vài năm tới, và vì vậy, theo truyền thống tốt nhất, tôi để nó như một bài tập cho người đọc.

Chiều dài hộp thư

{1,64}

Điều thực sự quan trọng là độ dài tối đa của hộp thư: 64 ký tự.

Vì vậy, sau khi chúng tôi đóng nhóm chụp hộp thư bằng dấu ngoặc đơn đóng cuối cùng, chúng tôi sử dụng bộ định lượng giữa các dấu ngoặc nhọn để chỉ định rằng chúng tôi phải khớp với bất kỳ lựa chọn thay thế nào của chúng tôi ít nhất một lần và không quá 64 lần.

atSign

\s?(?<atSign>(?<!\-)(?<!\.)\@(?!\@))

Đoạn dấu phân cách bắt đầu với trường hợp đặc biệt \s? bởi vì theo Futility, một khoảng trắng là hợp pháp ngay trước dấu phân cách và tôi chỉ tin lời họ cho nó.

Phần còn lại của nhóm chụp theo mô hình tương tự như singleDot ; nó sẽ không khớp nếu đứng trước dấu chấm hoặc dấu gạch ngang hoặc nếu ngay sau đó là @ khác.

Tên miền

Ở đây, cũng như trong hộp thư, chúng tôi có 3 trận đấu thay thế. Và trận cuối cùng trong số này đã lồng vào đó 4 trận luân phiên khác.

DNS tiêu chuẩn có thể phân tích cú pháp

(?<dns>[[:alnum:]]([[:alnum:]\-]{0,63}\.){1,24}[[:alnum:]\-]{1,63}[[:alnum:]])

Điều này sẽ không vượt qua một số bài kiểm tra trong Futility, nhưng như đã đề cập trước đó, nó tuân thủ nghiêm ngặt RFC 5321 có quyết định cuối cùng.

IPv4

(?<IPv4>\[((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\])

Không có quá nhiều điều để nói về điều này. Đây là một regex nổi tiếng và dễ dàng có sẵn cho các địa chỉ IPv4.

IPv6

(?<IPv6>(?<IPv6Full>(\[IPv6(\:[0-9a-fA-F]{1,4}){8}\]))|(?<IPv6Comp1>\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,3}(\:([0-9a-fA-F]{1,4})){1,5}?\])|\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,5}(\:([0-9a-fA-F]{1,4})){1,3}?\]))|(?<IPv6Comp2>(\[IPv6\:\:(\:[0-9a-fA-F]{1,4}){1,6}\]))|(?<IPv6Comp3>(\[IPv6\:([0-9a-fA-F]{1,4}\:){1,6}\:\]))|(?<IPv6Comp4>(\[IPv6\:\:\:)\])|(?<IPv6v4Full>(\[IPv6(\:[0-9a-fA-F]{1,4}){6}\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3})(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\])|(?<IPv6v4Comp1>\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,3}(\:([0-9a-fA-F]{1,4})){1,5}?(\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\])|\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,5}(\:([0-9a-fA-F]{1,4})){1,3}?(\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\]))|(?<IPv6v4Comp2>(\[IPv6\:\:(\:[0-9a-fA-F]{1,4}){1,5}(\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\]))|(?<IPv6v4Comp3>(\[IPv6\:([0-9a-fA-F]{1,4}\:){1,5}\:(((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\]))|(?<IPv6v4Comp4>(\[IPv6\:\:\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3})(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\]))

Tôi không thể tìm thấy biểu thức chính quy tốt cho địa chỉ IPv6 (và IPv6v4), vì vậy tôi đã viết địa chỉ của riêng mình, cẩn thận tuân theo các quy tắc được ký hiệu Backus/Naur từ RFC 5321.

Tôi sẽ không chú thích mọi nhóm con của biểu thức chính quy IPv6, nhưng tôi đã đặt tên cho mọi nhóm con để dễ dàng tách ra và xem điều gì đang xảy ra.

Thực sự không có gì quá thú vị ngoại trừ cách tôi kết hợp khớp tham lam ở bên “trái” và không tham lam ở “bên phải” trong nhóm chụp IUPv6Comp1.

Toàn bộ Monty

Tôi đã lưu biểu thức chính quy cuối cùng, cùng với dữ liệu thử nghiệm từ Futility và được tăng cường bởi một số trường hợp thử nghiệm IPv6 của riêng tôi, vào Regex101 . Tôi hy vọng bạn thích bài viết này và nó tỏ ra hữu ích và tiết kiệm thời gian cho nhiều bạn.

AZW