Thư Viện Mẫu Biểu Thức Chính Quy

Về thư viện này

Đây là một bộ sưu tập có tổ chức và có thể tìm kiếm gồm hơn 60 mẫu biểu thức chính quy thường dùng, được sắp xếp theo danh mục. Mỗi mẫu bao gồm mô tả, biểu thức và các ví dụ khớp. Nhấp vào một mẫu để sao chép, hoặc sử dụng bảng kiểm tra nhanh để xác thực văn bản với nó trực tiếp trên trang này.

Mọi thứ chạy trong trình duyệt của bạn · không có mẫu hay văn bản kiểm tra nào được gửi đi. Sử dụng các mẫu này trong JavaScript, Python, PHP, Java, Go hoặc bất kỳ ngôn ngữ nào hỗ trợ biểu thức chính quy. Để kiểm tra nâng cao hơn với cờ và nhóm chụp, hãy thử Bộ Kiểm Tra & Gỡ Lỗi Biểu Thức Chính Quy của chúng tôi.

Biểu thức chính quy đến từ đâu

Ý tưởng toán học về «tập hợp chính quy» được hình thức hóa bởi Stephen Cole Kleene vào năm 1951 trong bản ghi nhớ nghiên cứu RAND Representation of Events in Nerve Nets and Finite Automata. Toán tử * trên trang này vẫn được gọi là sao Kleene để tôn vinh ông. Ken Thompson đã biến lý thuyết thành thuật toán trong bài báo tháng 6 năm 1968 trên Communications of the ACM, Programming Techniques: Regular Expression Search Algorithm, và phát hành cài đặt regex đầu tiên trong trình soạn thảo QED tại Bell Labs. Đến năm 1973, cùng một engine cung cấp năng lượng cho ed, sau đó là grep (mở rộng theo nghĩa đen là «globally search for regular expression and print»), sed, và awk. Perl (1987) của Larry Wall và đặc biệt là Perl 5 (1994) đã thêm các nhóm có tên, lookaround, lượng từ không tham lam và xử lý Unicode, trở thành phương ngữ trên thực tế được gọi là PCRE, được chuyển sang C dưới dạng thư viện bởi Philip Hazel vào năm 1997.

Các biến thể engine và những gì thay đổi giữa chúng

Một mẫu chạy sạch trong JavaScript có thể thất bại lặng lẽ trong Go và bị từ chối hoàn toàn trong POSIX. Năm biến thể mà một nhà phát triển có khả năng gặp nhất:

• POSIX BRE / ERE (IEEE Std 1003.2-1992): phương ngữ của grep, sed, và awk trên hệ thống Unix tiêu chuẩn. Không có lookaround, không có nhóm có tên, không có escape thuộc tính Unicode. BRE ngoài ra yêu cầu thoát (, ), {, }, và |.
• PCRE2 (Philip Hazel, 1997, phiên bản chính hiện tại 10.x): phương ngữ đầy đủ tính năng nhất. Lookaround, nhóm có tên (?<name>...), nhóm nguyên tử, lượng từ sở hữu, đệ quy. Được sử dụng bởi PHP preg_*, Apache, nginx, R.
• Regex ECMAScript (ECMA-262, phần regex 22.2): phương ngữ JavaScript. ES2018 đã thêm nhóm có tên, lookbehind, và các flag s (dotAll) và u (Unicode). ES2022 đã thêm flag d cho các chỉ số khớp. ES2024 đã thêm flag v với các lớp ký hiệu tập hợp.
• Python re: gần với PCRE, nhưng sử dụng (?P<name>...) cho các nhóm có tên (PEP 433) và chế độ verbose khác re.X. Module bên thứ ba mới hơn regex thêm các mẫu đệ quy và ngữ nghĩa khớp dài nhất POSIX.
• RE2 (Russ Cox, 2010): engine đằng sau regexp của Go và crate regex của Rust. Không lookaround, không backreference, không lượng từ sở hữu, có chủ ý. Đánh đổi: thời gian tuyến tính đảm bảo, không có backtracking thảm khốc. Nếu một mẫu từ thư viện này sử dụng (?=...) hoặc \1, nó sẽ không biên dịch trong Go.

Backtracking thảm khốc và ReDoS

Hầu hết các engine regex trong các ngôn ngữ chính (PCRE, Java, JS V8 / SpiderMonkey / JavaScriptCore, Python re, .NET) là các engine backtracking. Khi một mẫu với lượng từ lồng nhau như (a+)+ gặp đầu vào gần khớp, engine có thể thử số lượng đường dẫn thay thế theo cấp số nhân trước khi bỏ cuộc. Đây là backtracking thảm khốc, và là cơ sở của lớp tấn công ReDoS (Regular expression Denial of Service) được liệt kê bởi OWASP.

Stack Overflow, 20 tháng 7 năm 2016: một mẫu được thiết kế để cắt khoảng trắng đầu và cuối, áp dụng cho nội dung câu hỏi chứa 20 000 ký tự khoảng trắng liên tiếp, mất 11 phút CPU cho mỗi yêu cầu và khiến trang web không phản hồi trong 34 phút. Báo cáo sự cố trên blog chính thức Stack Status khuyến nghị thay thế regex cắt bằng trim chuỗi gốc.

Cloudflare, 2 tháng 7 năm 2019: một quy tắc WAF chứa mẫu lượng từ lồng nhau .*(?:.*=.*) đã được triển khai toàn cầu và tiêu thụ 100% CPU trên mỗi máy chủ biên trong 27 phút, đưa các phần lớn của internet công cộng offline. Báo cáo sự cố của Cloudflare trên blog của họ ghi nhận việc chuyển sang crate regex của Rust (một engine dựa trên RE2, thời gian tuyến tính) để ngăn chặn tái diễn.

Bài học phòng thủ: tránh lượng từ lồng nhau ((a+)+, (a*)*, (a|aa)+); tránh cắt kiểu \s+$ trên đầu vào do kẻ tấn công kiểm soát; ưu tiên nhóm nguyên tử (?>...) hoặc lượng từ sở hữu a++ trong PCRE; và đối với dịch vụ thông lượng cao, hãy xem xét engine dựa trên RE2.

Email, URL, điện thoại, ngày, thẻ tín dụng: khi không dùng regex

Email. Toàn bộ ngữ pháp của RFC 5322 (tháng 10 năm 2008) biên dịch thành regex khoảng 3 000 ký tự. Đặc tả HTML5 của W3C cho xác thực <input type="email"> sử dụng regex ngắn hơn nhiều «liệu-đây-có-vẻ-là-email» là điểm khởi đầu đúng cho các gợi ý phía máy khách. RFC 6531 (tháng 2 năm 2012) cho phép các địa chỉ không phải ASCII như 用户@example.com, mà regex chỉ ASCII sẽ từ chối sai. Đồng thuận của ngành kể từ RFC 6532: không xác thực email bằng regex, gửi email xác minh thay vào đó.

URL. RFC 3986 (tháng 1 năm 2005) là đặc tả cú pháp URI chung, nhưng WHATWG URL Living Standard cố ý khác biệt với nó để phù hợp với những gì trình duyệt thực sự chấp nhận. Sử dụng new URL("...") trong JavaScript hoặc urllib.parse trong Python thay vì regex cho bất cứ điều gì ngoài kiểm tra thị giác nhanh.

Số điện thoại. Khuyến nghị E.164 của ITU-T (sửa đổi hiện tại tháng 11 năm 2010) cho phép tối đa 15 chữ số với tiền tố + tùy chọn, nhưng các quy tắc cụ thể của quốc gia thay đổi rất nhiều. Thư viện mã nguồn mở của Google libphonenumber mã hóa các quy tắc theo quốc gia cho từng lãnh thổ và là trình xác thực đáng tin cậy duy nhất giữa các quốc gia.

Ngày. Một regex như ^\d{4}-\d{2}-\d{2}$ khớp với định dạng lịch ISO 8601-1:2019, nhưng nó cũng chấp nhận 2026-02-31. Tính hợp lệ của ngày yêu cầu logic lịch, không phải khớp mẫu; sử dụng Date.parse() hoặc thư viện ngày.

Thẻ tín dụng. Một regex có thể khớp với độ dài chữ số và tiền tố IIN (Visa bắt đầu bằng 4, Mastercard bằng 51-55 hoặc 2221-2720, Amex bằng 34 hoặc 37) nhưng không thể xác minh kiểm tra Luhn (Hans Peter Luhn, IBM, Bằng sáng chế Hoa Kỳ 2 950 048 được cấp tháng 8 năm 1960). Luhn yêu cầu tổng từng chữ số modulo 10.

Các cách phổ biến mà nhà phát triển sử dụng thư viện này

• Gợi ý biểu mẫu phía máy khách, với sự hiểu biết rằng việc bắt regex là một gợi ý, không phải xác thực cuối cùng.
• Quét log, kéo các dấu thời gian, IP, mã lỗi và URL từ log ứng dụng vào một pipeline.
• Dọn dẹp dữ liệu một lần: chuẩn hóa khoảng trắng, loại bỏ các thẻ HTML, chuyển đổi giữa các định dạng ngày, slugify tiêu đề.
• Tìm và thay thế trong trình soạn thảo trong VS Code, Sublime, vim, IntelliJ nơi biến thể regex gần với PCRE.
• Mẫu khớp router và URL trong Express, Flask, FastAPI, Rails.
• Quy tắc WAF và phát hiện xâm nhập, với sự cẩn thận cực độ về ReDoS như sự cố Cloudflare năm 2019 đã chứng minh.
• Kiểm tra chuỗi nhanh trong bảng kiểm tra ở cuối trang này, trước khi cam kết mẫu vào mã.

Những sai lầm phổ biến

• Quên các neo. Không có ^ và $ (hoặc \A và \z trong PCRE), một regex xác thực khớp nếu mẫu xuất hiện ở bất kỳ đâu trong chuỗi. /\d{4}/ khớp với «year 2026 was good», điều mà hầu như không bao giờ là điều bạn muốn.
• Tin cậy .* qua nhiều thứ. <a href=".*"> trên đầu vào <a href="a"><a href="b"> bắt qua cả hai thẻ vì .* là tham lam. Sử dụng .*? cho lazy, hoặc tốt hơn, phân tích cú pháp bằng trình phân tích thực sự.
• Giả sử dấu chấm khớp với dòng mới. Theo mặc định . khớp với mọi thứ ngoại trừ các bộ kết thúc dòng. Sử dụng flag s (dotAll) trong JS, hoặc re.DOTALL trong Python, hoặc modifier inline (?s) trong PCRE.
• Giả sử \w bao gồm các chữ cái không phải ASCII. Trong chế độ ASCII, \w là [a-zA-Z0-9_]. Thêm flag u trong JS (ES2018+) và sử dụng \p{L} cho bất kỳ chữ cái Unicode nào; trong Python thêm re.UNICODE (mặc định trong Python 3).
• Backreference trong Go. regexp của Go là RE2 và từ chối \1 tại thời gian biên dịch. Lỗi «error parsing regexp: invalid escape sequence: \1» có nghĩa là mẫu cần được chia thành cách tiếp cận không phải regex.
• Phân tích HTML bằng regex. Nổi tiếng là không khả thi: HTML không phải là ngôn ngữ chính quy. Sử dụng trình phân tích DOM (DOMParser tích hợp của trình duyệt, cheerio, BeautifulSoup, lxml).

Thêm câu hỏi thường gặp

Tại sao một số mẫu sử dụng (?:...) thay vì (...)?

(?:...) là một nhóm không bắt: nó nhóm để lặp lại hoặc thay thế nhưng không phân bổ khe backreference. Nó nhanh hơn và tránh làm ô nhiễm $1, $2 trong mảng kết quả. Sử dụng (...) khi bạn cần trích xuất văn bản đã bắt; sử dụng (?:...) chỉ để nhóm.

Các flag regex phổ biến nhất là gì?

i không phân biệt chữ hoa chữ thường, g toàn cầu (tìm tất cả, hành vi đặc thù JS), m nhiều dòng (để ^ và $ khớp với ranh giới dòng), s dotAll (để . khớp với dòng mới, ES2018+), u Unicode (ES2015+), y sticky (ES2015+), d hasIndices (ES2022+), v các lớp ký hiệu tập hợp (ES2024+). Kết hợp dưới dạng /pattern/gimsu.

Làm thế nào để khớp một ký tự đặc biệt theo nghĩa đen?

Thoát nó bằng dấu gạch chéo ngược. Các siêu ký tự regex cần thoát để khớp theo nghĩa đen là: . ^ $ * + ? ( ) [ ] { } | \ /. Bên trong một lớp ký tự [...] tập hợp các ký tự đặc biệt nhỏ hơn: chỉ ] \ ^ - cần thoát, tùy thuộc vào vị trí.

Tôi có thể sử dụng các mẫu của thư viện này trong script shell không?

Có, với các lưu ý. grep sử dụng POSIX BRE theo mặc định; grep -E sử dụng ERE; grep -P sử dụng PCRE trên các hệ thống nơi libpcre được liên kết (GNU grep, macOS grep với Homebrew). Các mẫu sử dụng lookaround, nhóm có tên hoặc escape Unicode yêu cầu grep -P hoặc ripgrep (sử dụng engine RE2-based của Rust và từ chối lookaround).

Các mẫu này có được gửi đến máy chủ không?

Không. Mỗi regex trên trang này, mỗi tìm kiếm bạn nhập và mỗi chuỗi bạn kiểm tra trong bảng kiểm tra nhanh được xử lý trong engine JavaScript của trình duyệt của bạn. Không có cuộc gọi mạng nào được thực hiện. Dữ liệu mẫu bản thân được phát hành dưới dạng tệp JSON tĩnh trong bundle trang. Mở tab Mạng trong DevTools để xác minh.