The 20 Regex Patterns I Actually Use (After Mass-Deleting the Other 200)

# 20 Mẫu Regex Tôi Thực Sự Sử Dụng (Sau Khi Xóa Đại Hàng 200 Mẫu Khác)

Trước đây tôi đã viết một regex dài 847 ký tự để xác thực email. Nó đã lấy đi ba giờ cuộc đời của tôi mà tôi sẽ không bao giờ lấy lại được, với các lookahead lồng nhau, ngoại lệ lớp ký tự và đủ dấu gạch chéo để làm mắt tôi ứa nước. Tôi rất tự hào về nó. Tôi đã đăng nó trong Slack của đội với thông điệp kiêu ngạo "Cái này xử lý tất cả các trường hợp ngoại lệ".

Rồi ai đó đã gửi cho tôi liên kết đến RFC 5322.

Đối với những ai hoàn toàn không biết, RFC 5322 là đặc tả địa chỉ email chính thức. Mẫu regex thực sự, hoàn chỉnh mà xác thực mọi địa chỉ email hợp lệ về mặt kỹ thuật dài hơn 6.000 ký tự. Nó bao gồm những thứ như chú thích trong ngoặc đơn, chuỗi được trích dẫn với các ký tự thoát, và các hằng số miền trong dấu ngoặc vuông. Về mặt kỹ thuật, `"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com` là một địa chỉ email hợp lệ theo đặc tả.

Tôi nhìn chằm chằm vào mẫu 847 ký tự của mình. Sau đó là RFC. Rồi quay lại nhìn mẫu của mình. Sau đó tôi đã làm điều mà bất kỳ lập trình viên hợp lý nào cũng sẽ làm: Tôi thay thế nó bằng `/.+@.+\..+/` và tiếp tục cuộc sống của mình. Bởi vì — không ai thực sự sử dụng những trường hợp ngoại lệ đó. Và nếu họ làm, họ xứng đáng với bất cứ điều gì hỏng hóc.

Đó là cách đây năm năm. Kể từ đó, tôi đã viết hàng trăm mẫu regex. Tôi đã gỡ lỗi regex khiến các lập trình viên lâu năm phải khóc. Tôi đã tối ưu hóa những mẫu gây ra tình trạng chậm trong sản xuất. Và qua tất cả, tôi đã học được một điều quan trọng: hầu hết các mẫu regex đều là rác mà bạn không bao giờ cần.

Hành Trình Của Tôi Từ Regex Maximalist Đến Minimalist

Tôi trước kia đã thu thập các mẫu regex như một số người thu thập tem. Tôi có một tệp `regex-library.js` khổng lồ với các mẫu cho mọi thứ tưởng tượng. Địa chỉ IPv6 với ID khu vực. Số thẻ tín dụng có xác thực thuật toán Luhn. Các URL xử lý mọi giao thức obscure. Số an sinh xã hội với kiểm tra mã khu vực từ những năm 1930.

Tệp đã dài 3.200 dòng. Tôi đã tin rằng tôi đang xây dựng một thứ gì đó có giá trị—một thư viện toàn diện sẽ tiết kiệm thời gian cho tôi trong mọi dự án. Tôi thậm chí còn bắt đầu viết tài liệu cho nó, kèm theo ví dụ và các chỉ số hiệu suất.

Rồi tôi đổi việc.

Tại công ty mới của tôi, tôi đã cố gắng nhập thư viện regex quý giá của mình vào mã nguồn của chúng tôi. Kiến trúc sư cao cấp đã nhìn một cái vào đó trong đánh giá mã và hỏi một câu hỏi đơn giản: "Trong số này, bạn đã thực sự sử dụng cái nào trong sáu tháng qua?"

Tôi đã xem qua tệp với một bút đánh dấu. Trong hơn 200 mẫu, tôi có thể đã sử dụng khoảng 15 mẫu. Phần còn lại là các mẫu "chỉ trong trường hợp"—các giải pháp đang tìm kiếm vấn đề. Những mẫu mà tôi đã viết vì chúng thú vị về mặt trí tuệ, không phải vì chúng giải quyết các vấn đề thực sự.

Đó là khi tôi bắt đầu cuộc thanh lọc regex lớn của mình. Tôi đã đi qua từng mẫu và hỏi: "Tôi có cần cái này trong sản xuất không? Không phải 'có thể tôi cần nó một ngày nào đó,' mà là tôi đã thực sự cần nó chưa?" Nếu câu trả lời là không, nó sẽ bị xóa. Không có lòng thương xót. Không có ngoại lệ "nhưng nếu thế này thì sao".

Tệp đã giảm từ 3.200 dòng xuống 400. Sau đó xuống 200. Rồi còn khoảng gần 100 dòng chứa 20 mẫu mà tôi thực sự sử dụng thường xuyên. Và bạn biết không? Tôi chưa bao giờ cảm thấy thiếu các mẫu khác 180 mẫu đó. Không hề một chút nào.

Lần Đó Regex Gần Như Đã Thổi Bay API Của Chúng Tôi

Để tôi kể cho bạn về sự cố trong sản xuất tồi tệ nhất mà tôi đã gây ra với regex. Chúng tôi đã có một điểm cuối API nhận nội dung do người dùng tạo—thực chất là một trường ghi chú nơi người dùng có thể viết bất cứ điều gì họ muốn. Nghe có vẻ đơn giản, đúng không?

Nhưng chúng tôi muốn phát hiện và tự động liên kết các URL trong văn bản. Vì vậy, tôi đã viết một mẫu regex mà tôi nghĩ là thông minh sẽ khớp các URL trong khi tránh được các kết quả giả. Nó có các lookahead để kiểm tra các giao thức hợp lệ, các lớp ký tự cho tên miền, các số cổng tùy chọn, các đoạn đường dẫn, các tham số truy vấn và các định danh đoạn. Nó rất đẹp. Nó rất toàn diện. Đó là một sai lầm thảm khốc.

Mẫu làm việc tốt trong kiểm tra. Tôi đã thử nhiều URL với nó, và nó xử lý chúng hoàn hảo. Tôi đang cảm thấy khá tốt về bản thân mình khi chúng tôi triển khai vào môi trường sản xuất vào một buổi chiều thứ Sáu. (Vâng, tôi biết. Không bao giờ triển khai vào thứ Sáu. Tôi đã học bài học đó một cách khó khăn.)

Trong vòng một giờ, thời gian phản hồi API của chúng tôi đã tăng từ 50ms lên 30 giây. Sau đó, tình trạng timeout bắt đầu xảy ra. Hệ thống giám sát của chúng tôi sáng như cây thông Giáng sinh. Người dùng đang phàn nàn. Điện thoại của tôi rung. Nó thật tệ.

Thủ phạm? Một người dùng đã dán một chuỗi văn bản dài chứa các mẫu kích hoạt việc quay ngược thảm khốc trong regex của tôi. Bộ máy regex đang thử mọi kết hợp có thể của các kết quả, và với chuỗi đầu vào dài 5.000 ký tự, điều đó có nghĩa là hàng tỷ lần thử. Mỗi yêu cầu đã chiếm một lõi CPU ở mức 100% trong hơn 30 giây trước khi timeout.

Chúng tôi đã quay lại ngay lập tức, và tôi đã dành cả cuối tuần để viết lại mẫu đó. Phiên bản mới đơn giản hơn, ít "thông minh" hơn, và có các giới hạn rõ ràng về sự lặp lại. Nó không khớp mọi định dạng URL có thể—nó khớp 99,9% các URL mà mọi người thực sự sử dụng. Và nó chạy trong vài micro giây thay vì vài giây.

Sự cố đó đã dạy tôi một điều quan trọng: độ phức tạp của regex là một gánh nặng, không phải một tài sản. Mẫu của bạn càng phức tạp thì khả năng nó cắn bạn trong sản xuất càng cao. Những mẫu đơn giản xử lý các trường hợp phổ biến hầu như luôn tốt hơn những mẫu phức tạp xử lý mọi trường hợp ngoại lệ.

Phân Tích Những Gì Thực Sự Quan Trọng

Sau nhiều năm viết regex và học hỏi từ những sai lầm của mình, tôi đã phát triển một khung đơn giản để quyết định những mẫu nào đáng giữ lại. Nó phụ thuộc vào ba tiêu chí:

Sử dụng các tiêu chí này, hầu hết các mẫu không đáp ứng yêu cầu. Mẫu fancy cho việc phân tích ngày tháng ISO 8601 với các offset múi giờ và số tuần? Không đạt yêu cầu về tần suất—tôi cần nó có thể hai lần một năm, và khi tôi cần, tôi có thể tìm kiếm. Mẫu để xác thực các số tài khoản ngân hàng IBAN? Không đạt yêu cầu về độ tin cậy—nó phức tạp đến mức tôi không tin mình có thể duy trì. Mẫu đệ quy để khớp các dấu ngoặc lồng nhau? Không đạt yêu cầu về hiệu suất—đó là một cơn ác mộng quay lại đang chờ xảy ra.

Những gì còn lại là các mẫu đơn giản, nhanh chóng và giải quyết các vấn đề mà tôi thường gặp. Chúng không phải là những mẫu thú vị nhất. Chúng không phải là những mẫu khiến bạn cảm thấy thông minh. Nhưng chúng là những gì thực sự quan trọng.

Mẫu regex tốt nhất là mẫu mà bạn có thể hiểu sau sáu tháng vào lúc 2 giờ sáng khi sản xuất đang bị hỏng và bạn đang cố gắng tìm hiểu lý do tại sao đầu vào của người dùng lại phá vỡ xác thực của bạn.

20 Mẫu Đã Sống Sót Qua Lần Xóa Sạch

Dưới đây là danh sách đầy đủ các mẫu regex mà tôi thực sự sử dụng, được tổ chức theo danh mục. Đây là những người sống sót—các mẫu đã chứng minh giá trị của chúng qua việc sử dụng lặp lại trong các dự án thực tế.