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: . Để cho ngắn gọn, tôi sẽ gọi nó là trong bài viết này. Về sự vô ích của việc xác thực Regex qua email Futility 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ị, không phải là hướng dẫn hữu ích cho lập trình viên thực tế. Futility Đ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. được tham chiếu trong 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ệ. Bộ kiểm tra Futility Đ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 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ụ. báo cáo 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ư ?) 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. @ imagefile@2x.png 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, "redacted@example.com", 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à 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ì?” lời khuyên 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à: Hộp thư nhân vật pháp lý Chấm đơn (chấm kép không hợp pháp) Khoảng trắng được gấp lại (RFC 5322 điên rồ) (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ó.) Dấu phân cách (@) tên miền Tên miền có thể phân tích cú pháp dns tiêu chuẩn Địa chỉ IPv4 bằng chữ Địa chỉ IPv6 bằng chữ IPv6 đầy đủ IPv6-comp (để nén) Dạng thứ nhất (2+ nhóm 16-bit số 0 ở giữa) Dạng thứ 2 (2+ nhóm 16-bit của số 0 ở đầu) dạng thứ 3 (2 nhóm 16-bit của số 0 ở cuối) Dạng thứ 4 (8 nhóm 16-bit của số 0) IPv6v4 đầy đủ IPv6v4-comp (nén) hình thức đầu tiên mẫu thứ 2 mẫu thứ 3 mẫu thứ 4 Bây giờ cho regex. Hộp thư ^(? (\[a-zA-Z0-9\\+\\!\\#\\$\\%\\&\\'\\\*\\-\\/\\=\\?\\+\\\_\\\{\\}\\|\\\~]|(? (? \\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ó . 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 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. (? khớp thay thế | 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 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. ngoại trừ Lý do tại sao chúng tôi loại trừ chúng là vì chúng chỉ hợp pháp , 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. có điều kiện chấm đơn (? (?<!\.)(?<!^)\.(?!\.)) 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 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ó. giao diện phủ định (? \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 làm đối sánh thay thế. Khoảng trắng được gấp 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 ) các ký tự thường là bất hợp pháp. thoát 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 . Điều này có nghĩa là phải có một cặp ký tự, một ký tự và một ký tự . cân bằng mở đóng Tôi rất muốn viết rằng tôi đã phát hiện ra một , 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. cuộc biểu tình mirablem 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ự trọng là độ dài tối đa của hộp thư: 64 ký tự. quan 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 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. bộ định lượng atSign \s?(? (?<!\-)(?<!\.)\@(?!\@)) Đoạn dấu phân cách bắt đầu với bởi vì theo 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ó. trường hợp đặc biệt \s? Futility, Phần còn lại của nhóm chụp theo mô hình tương tự như ; 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. singleDot @ 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 (? [[: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 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. Futility, 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(\:[0-9a-fA-F]{1,4}){8}\]))|(? \[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}?\]))|(? (\[IPv6\:\:(\:[0-9a-fA-F]{1,4}){1,6}\]))|(? (\[IPv6\:([0-9a-fA-F]{1,4}\:){1,6}\:\]))|(? (\[IPv6\:\:\:)\])|(? (\[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]?)\])|(? \[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]?))\]))|(? (\[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]?))\]))|(? (\[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]?))\]))|(? (\[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 . 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. Regex101 AZW