Regex Cheat Sheet 2026: Patterns Every Developer Needs — txt1.ai

Lỗi sản xuất lúc 3 giờ sáng đã thay đổi cách tôi nghĩ về regex

Tôi vẫn nhớ đêm tôi nhận được cuộc gọi. Đó là 3:17 sáng, và hệ thống xử lý thanh toán của chúng tôi vừa từ chối 847 giao dịch thẻ tín dụng hợp pháp trong vòng 12 phút. Là kỹ sư backend chính tại một công ty khởi nghiệp fintech xử lý 2,3 triệu đô la mỗi ngày, tôi đã mặc hoodie và mở máy tính xách tay với đôi tay run rẩy. Thủ phạm? Một ký tự bị đặt sai trong một mẫu regex đã nằm trong mã của chúng tôi được tám tháng.

Vụ việc đó đã khiến chúng tôi thiệt hại 43.000 đô la doanh thu và gần như phá hủy một mối quan hệ đối tác mà chúng tôi đã mất sáu tháng để xây dựng. Nhưng nó đã dạy tôi một điều quý giá: regex không chỉ là một công cụ khác trong bộ công cụ của bạn—mà nó là một công cụ chính xác yêu cầu sự tôn trọng, hiểu biết và thực hành liên tục. Trong 12 năm xây dựng hệ thống tại ba công ty khởi nghiệp và hai công ty Fortune 500, tôi đã viết hàng ngàn mẫu regex. Tôi đã gỡ lỗi regex khiến các lập trình viên cao cấp phải khóc. Tôi đã tối ưu hóa các mẫu giúp giảm thời gian xử lý từ 4,2 giây xuống còn 180 mili giây.

Đây không phải là một bảng cheat regex điển hình với các giải thích cú pháp khô khan. Đây là hướng dẫn mà tôi mong ước đã có khi tôi gỡ lỗi hệ thống thanh toán đó lúc 3 giờ sáng. Nó được xây dựng từ các kịch bản sản xuất thực tế, các tiêu chí hiệu suất thực tế, và kiểu trí tuệ thực tế mà bạn chỉ có được từ những sai lầm tốn kém. Dù bạn đang xác thực đầu vào người dùng, phân tích tệp nhật ký, hay xây dựng đường ống dữ liệu, các mẫu trong hướng dẫn này sẽ tiết kiệm cho bạn hàng giờ gỡ lỗi và có thể hàng ngàn đô la trong các sự cố sản xuất.

Hiểu biết về các nguyên tắc cơ bản của regex: Vượt ra ngoài những điều cơ bản

Trước khi chúng ta đi sâu vào các mẫu cụ thể, hãy thiết lập một mô hình tư duy thực sự hiệu quả. Hầu hết các lập trình viên nghĩ rằng regex là một công cụ so khớp, nhưng điều đó giống như nghĩ rằng dao đa năng Thụy Sĩ chỉ là một lưỡi dao. Regex là một ngôn ngữ lập trình khai báo cho nhận dạng mẫu, và hiểu biết về sự khác biệt này thay đổi mọi thứ về cách bạn tiếp cận các vấn đề.

Regex không chỉ đơn thuần là so khớp mẫu—nó là một ngôn ngữ khai báo mà trong đó mỗi ký tự là một hợp đồng với engine. Sự khác biệt giữa một mẫu tốt và một mẫu tuyệt vời không phải là độ phức tạp, mà là độ chính xác.

Các yếu tố cấu thành chính đơn giản hơn bạn nghĩ. Các ký tự nguyên bản khớp chính chúng—mẫu "cat" khớp với chuỗi "cat". Nhưng sức mạnh thực sự đến từ các ký tự đặc biệt: các ký hiệu đại diện cho các lớp ký tự hoặc vị trí. Dấu chấm (.) khớp với bất kỳ ký tự đơn nào ngoại trừ xuống dòng. Dấu sao (*) có nghĩa là "không hoặc nhiều hơn phần tử trước". Dấu cộng (+) có nghĩa là "một hoặc nhiều". Dấu chấm hỏi (?) có nghĩa là "không hoặc một".

Đây là nơi hầu hết các hướng dẫn thất bại: họ không giải thích rằng các engine regex hoạt động khác nhau. PCRE (Biểu thức chính quy tương thích với Perl) cung cấp sức mạnh cho PHP, mô-đun re của Python, và nhiều ngôn ngữ khác. JavaScript sử dụng loại riêng của nó với một số điều kỳ lạ. Java có một triển khai khác nữa. Những khác biệt này quan trọng khi bạn đang gỡ lỗi lý do một mẫu hoạt động trong script Python cục bộ của bạn nhưng thất bại trong mã Node.js sản xuất.

Các lớp ký tự là công cụ đầu tiên của bạn. Thay vì viết (a|e|i|o|u) để khớp với các nguyên âm, bạn viết [aeiou]. Cú pháp dấu ngoặc vuông nhanh hơn và dễ đọc hơn. Muốn khớp với bất kỳ chữ số nào? Sử dụng \d thay vì [0-9]. Bất kỳ ký tự từ nào (chữ cái, chữ số hoặc dấu gạch dưới)? Đó là \w. Bất kỳ khoảng trắng nào? \s. Các phiên bản viết hoa là phủ định: \D khớp với không phải chữ số, \W khớp với không phải ký tự từ, \S khớp với không phải khoảng trắng.

Các điểm neo điều khiển nơi các khớp xảy ra. Dấu mũ (^) neo vào đầu chuỗi hoặc dòng. Dấu đô la ($) neo vào cuối. Mẫu ^Hello$ chỉ khớp với chuỗi chính xác "Hello" mà không có gì trước hoặc sau. Các ranh giới từ (\b) tinh tế hơn nhưng cực kỳ hữu ích—chúng khớp với vị trí giữa một ký tự từ và một ký tự không phải từ. Mẫu \bcat\b khớp với "cat" nhưng không khớp với "category" hoặc "scat".

Các định lượng chỉ định số lần một phần tử nên lặp lại. Chúng ta đã đề cập đến *, +, và ?, nhưng vẫn còn nhiều độ chính xác hơn. Dấu ngoặc nhắc cho phép bạn chỉ định số lượng chính xác: {3} có nghĩa là chính xác ba, {3,} có nghĩa là ba hoặc nhiều hơn, {3,7} có nghĩa là từ ba đến bảy. Đây là điều thiết yếu cho các mẫu xác thực nơi bạn cần các yêu cầu về chiều dài chính xác.

Xác thực Email: Mẫu mà mọi người đều sai

Hãy để tôi chia sẻ một ý kiến gây tranh cãi: hầu hết các mẫu regex xác thực email hoặc quá nghiêm ngặt hoặc quá cho phép. Tôi đã thấy các hệ thống sản xuất từ chối các email hợp lệ từ người dùng quốc tế chỉ vì ai đó đã sao chép một mẫu từ Stack Overflow mà không hiểu nó. Tôi cũng đã thấy các hệ thống chấp nhận "user@domain" là hợp lệ, dẫn đến hàng ngàn email bị trả lại và khách hàng tức giận.

Thông số RFC 5322 cho địa chỉ email dài 3.500 từ và cho phép các trường hợp ngoại lệ như chuỗi được trích dẫn, chú thích và địa chỉ IP trong dấu ngoặc. Một mẫu regex hoàn toàn tuân thủ sẽ dài hơn 6.000 ký tự và hoàn toàn không thể bảo trì. Đừng sử dụng nó. Thay vào đó, hãy sử dụng một mẫu thực tiễn mà bắt 99,8% các email thực tế trong khi vẫn dễ đọc.

Đây là mẫu tôi sử dụng trong các hệ thống sản xuất xử lý hơn 50.000 lượt đăng ký hàng ngày:

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

Hãy phân tích mẫu này. Mẫu bắt đầu bằng ^ để neo ở đầu. Sau đó, [a-zA-Z0-9._%+-]+ khớp với một hoặc nhiều ký tự là chữ cái, chữ số hoặc các ký hiệu thường được sử dụng trong các phần địa phương email (phần trước @). Ký hiệu @ là nguyên bản. Sau đó, [a-zA-Z0-9.-]+ khớp với tên miền, có thể chứa chữ cái, chữ số, dấu chấm, và dấu gạch nối. Dấu \. khớp với một dấu chấm nguyên bản (chúng ta phải_escape nó vì . là một ký tự đặc biệt). Cuối cùng, [a-zA-Z]{2,} khớp với miền cấp cao nhất—ít nhất hai chữ cái. Dấu $ neo ở cuối.

Mẫu này từ chối rõ ràng các thứ rác như "user@" hoặc "@domain.com" trong khi chấp nhận các miền quốc tế và địa chỉ plus ([email protected]). Nó sẽ không bắt mọi trường hợp ngoại lệ, nhưng các trường hợp ngoại lệ chính xác là vậy—hiếm. Theo kinh nghiệm của tôi, 0,2% các email mà mẫu này có thể từ chối một cách sai lầm bị vượt xa bởi gánh nặng bảo trì của một mẫu phức tạp hơn.

Một bài học quan trọng: luôn xác thực địa chỉ email bằng cách gửi một liên kết xác nhận, không chỉ bằng regex. Tôi đã học được điều này sau khi chúng tôi mất ba tuần để gỡ lỗi lý do tại sao một số email không nhận được xác nhận, chỉ để phát hiện rằng các miền tồn tại nhưng đã cấu hình sai bản ghi MX. Regex xác thực định dạng, không phải khả năng giao hàng.

Phân tích và Xác thực URL: Xử lý Web hiện đại

URLs rất phức tạp một cách lừa đảo. Chúng có thể có giao thức, tên miền phụ, cổng, đường dẫn, tham số truy vấn và đoạn. Chúng có thể sử dụng tên miền quốc tế với ký tự Unicode. Chúng có thể là tương đối hoặc tuyệt đối. Một mẫu URL mạnh mẽ cần phải xử lý sự phức tạp này trong khi vẫn hiệu suất tốt.

Tôi đã thấy các lập trình viên mất hàng giờ để gỡ lỗi logic ứng dụng khi vấn đề thực sự là một mẫu regex mà 99% đúng. Trong các hệ thống sản xuất, 1% đó sẽ tìm đến bạn lúc 3 giờ sáng.

Đối với xác thực URL cơ bản, nơi bạn chỉ cần đảm bảo một cái gì đó trông giống như một URL, mẫu này hoạt động tốt:

^https?://[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}(/[^\s]*)?$

Mẫu này khớp với http hoặc https (s? làm cho 's' là tùy chọn), tiếp theo là ://, sau đó là tên miền, sau đó có thể là một đường dẫn. [^\s]* khớp với bất kỳ ký tự phi khoảng trắng nào cho phần đường dẫn. Nó đơn giản, nhanh chóng, và bắt các lỗi rõ ràng.

Nhưng nếu bạn cần trích xuất các phần từ một URL? Đó là nơi các nhóm bắt giữ tỏa sáng. Dấu ngoặc trong regex tạo