Bộ Kiểm Tra & Gỡ Lỗi Biểu Thức Chính Quy

Kiểm tra biểu thức chính quy với tô sáng thời gian thực và các nhóm bắt.

Không có dữ liệu nào rời khỏi thiết bị của bạn

Chuỗi thử nghiệm

Thay thế bằng

Kết quả khớp được tô sáng

Chi tiết kết quả khớp

0 matches

Tham khảo nhanh

.Bất kỳ ký tự nào ngoại trừ dòng mới \dChữ số (0-9) \wKý tự từ (a-z, A-Z, 0-9, _) \sKhoảng trắng (dấu cách, tab, dòng mới) ^Bắt đầu chuỗi (hoặc dòng với cờ m) $Kết thúc chuỗi (hoặc dòng với cờ m) *0 hoặc nhiều ký tự trước đó +1 hoặc nhiều ký tự trước đó ?0 hoặc 1 ký tự trước đó {n,m}Từ n đến m ký tự trước đó [abc]Lớp ký tự: a, b hoặc c [^abc]Không phải a, b hoặc c (abc)Nhóm bắt (?:abc)Nhóm không bắt a|ba hoặc b \bRanh giới từ (?=abc)Lookahead dương (?!abc)Lookahead âm

Về biểu thức chính quy

Biểu thức chính quy (regex) là các mẫu được sử dụng để so khớp các tổ hợp ký tự trong chuỗi. Chúng là công cụ thiết yếu trong lập trình, xử lý văn bản, xác thực dữ liệu và các thao tác tìm kiếm. Mọi ngôn ngữ lập trình chính đều hỗ trợ regex · JavaScript, Python, Java, PHP, Ruby, Go và nhiều ngôn ngữ khác.

Trình kiểm tra này sử dụng bộ máy RegExp tích hợp của JavaScript, hỗ trợ cú pháp regex ECMAScript bao gồm lookahead, lớp ký tự, bộ định lượng và các cờ g, i, m và s. Các kết quả khớp được tô sáng theo thời gian thực khi bạn nhập, và các nhóm bắt được hiển thị trong bảng chi tiết kết quả khớp.

Các ứng dụng phổ biến

Xác thực địa chỉ email, số điện thoại và các trường nhập liệu biểu mẫu
Trích xuất dữ liệu từ tệp nhật ký, CSV hoặc HTML
Tìm và thay thế các mẫu văn bản trong trình soạn thảo mã
Phân tích URL, đường dẫn tệp và văn bản có cấu trúc
Viết các bộ chọn cho web scraping và bộ lọc tìm kiếm

Câu hỏi thường gặp

Các cờ g, i, m và s có tác dụng gì?

g (global) tìm tất cả các kết quả khớp thay vì dừng ở cái đầu tiên. i (không phân biệt chữ hoa/thường) bỏ qua phân biệt chữ hoa với chữ thường. m (nhiều dòng) làm cho ^ và $ khớp với đầu/cuối của mỗi dòng. s (dotAll) làm cho . cũng khớp với các ký tự dòng mới.

Regex này có hoạt động trong Python / Java / PHP không?

Hầu hết cú pháp regex được chia sẻ giữa các ngôn ngữ. Tuy nhiên, có sự khác biệt · ví dụ, JavaScript không hỗ trợ lookbehind trong tất cả các trình duyệt (mặc dù các trình duyệt hiện đại có hỗ trợ), và Python sử dụng cú pháp nhóm có tên khác. Đối với các mẫu cơ bản, những gì hoạt động ở đây sẽ hoạt động ở mọi nơi.

Dữ liệu thử nghiệm của tôi có được gửi đi đâu không?

Không. Tất cả việc so khớp regex diễn ra cục bộ trong trình duyệt của bạn bằng bộ máy RegExp gốc của JavaScript. Không có gì được gửi đến bất kỳ máy chủ nào.

Trình kiểm tra regex là gì?

Trình kiểm tra regex là một trình chỉnh sửa tương tác chạy một biểu thức chính quy đối với một chuỗi mẫu và hiển thị cho bạn chính xác những gì đã khớp, những gì không khớp, và các nhóm bắt giữ chứa những gì. Trình kiểm tra cho phép bạn lặp lại nhanh chóng: gõ mẫu, xem các điểm nổi bật, điều chỉnh, lặp lại. Nó thay thế vòng lặp chậm của việc chỉnh sửa mã nguồn, chạy một script và đọc đầu ra console.

Biểu thức chính quy bản thân chúng là một cú pháp mẫu được phát minh bởi Stephen Cole Kleene vào năm 1956 để mô tả các tập hợp chuỗi. Các triển khai regex hiện đại (PCRE, RegExp của JavaScript, re của Python, System.Text.RegularExpressions của .NET, java.util.regex của Java) chia sẻ phần lớn cú pháp của chúng nhưng khác nhau trong các trường hợp cạnh như lookbehind, các nhóm có tên, xử lý Unicode và hành vi định lượng.

Trình kiểm tra này sử dụng động cơ RegExp JavaScript bản địa của trình duyệt của bạn, triển khai regex ECMAScript 2024 bao gồm tất cả các cờ tiêu chuẩn (g, i, m, s, u, y, d) và các lookbehind hiện đại. Đầu ra chính xác là những gì mã front-end của bạn sẽ thấy lúc runtime, điều này làm cho trình kiểm tra đặc biệt hữu ích khi gỡ lỗi xác thực phía client, các bộ chọn scraping hoặc các phép biến đổi replace-with-callback.

Bên trong trình kiểm tra có gì

Hàng trên cùng chứa đầu vào mẫu được bao quanh bởi dấu gạch chéo, theo sau là các nút bật/tắt cho bốn cờ được sử dụng nhiều nhất (g, i, m, s). Một nút Patterns mở thư viện các đoạn mã regex phổ biến (email, URL, điện thoại, ngày) mà bạn có thể nhấp để điền vào trường mẫu. Đằng sau hậu trường, đầu vào được debounce để gõ lại không làm rung chuyển matcher.

Bên dưới mẫu, textarea Test String là nơi bạn dán văn bản mẫu. Các kết quả khớp được tô sáng với nền vàng trong bảng Highlighted Matches được cập nhật khi bạn gõ. Trường Replace with chấp nhận một chuỗi thay thế với backreference ($1, $2, v.v.) và hiển thị văn bản kết quả trực tiếp, hoàn hảo để kiểm tra các phép biến đổi thay thế chuỗi trước khi dán chúng vào mã của bạn.

Danh sách Match Details hiển thị từng kết quả khớp với chỉ số dựa trên không của nó trong nguồn, chuỗi con đã khớp và mọi nhóm bắt giữ. Một thẻ Quick Reference ở dưới cùng tóm tắt cú pháp cho các lớp ký tự, định lượng, neo và lookaround, vì vậy bạn không phải chuyển ngữ cảnh sang tab tài liệu cho những điều cơ bản.

Lịch sử và bối cảnh

Stephen Cole Kleene định nghĩa các sự kiện thông thường (1956)

Nhà toán học Stephen Cole Kleene đã xuất bản bài báo Representation of Events in Nerve Nets and Finite Automata vào năm 1956, giới thiệu cái mà ông gọi là các sự kiện thông thường: các mẫu mô tả tập hợp các chuỗi được chấp nhận bởi một otomat hữu hạn. Sao Kleene (toán tử *) mang tên ông. Ký hiệu đại số của ông là tổ tiên trực tiếp của mọi cú pháp regex được sử dụng ngày nay.

Ken Thompson ra mắt grep (1968)

Ken Thompson tại Bell Labs đã triển khai một động cơ regex vào năm 1968 bên trong trình chỉnh sửa QED và một lần nữa trong grep (1973), tiện ích Unix có tên xuất phát từ lệnh QED g/regular-expression/p. Động cơ dựa trên NFA của Thompson chạy trong thời gian tuyến tính mỗi ký tự, một sự đảm bảo mà các động cơ backtracking đã mất sau này khi họ thêm các tính năng như backreference.

Perl 5 giới thiệu regex mở rộng (1994)

Larry Wall đã phát hành Perl 5 vào năm 1994 với một hương vị regex thêm lookahead, lookbehind, bắt giữ có tên (sau này), bộ điều chỉnh nội tuyến và backreference. Regex Perl 5 trở nên thống trị đến mức các ngôn ngữ khác đã sao chép cú pháp của nó. Philip Hazel đã tạo ra PCRE (Perl Compatible Regular Expressions) vào năm 1997 như một thư viện C, và PCRE ngày nay cung cấp năng lượng cho regex trong PHP, Apache, NGINX và nhiều công cụ khác.

JavaScript ra mắt RegExp (1995, được chính thức hóa vào năm 1999)

JavaScript 1.0 của Brendan Eich vào năm 1995 đã ra mắt với một đối tượng RegExp được mô hình theo Perl 5. Ấn bản thứ 3 của ECMAScript (1999) đã chính thức hóa cú pháp. Các ấn bản tiếp theo đã thêm cờ Unicode u (ES2015), cờ sticky y (ES2015), nhóm có tên (ES2018), lookbehind (ES2018) và cờ indices d (ES2022). Các trình duyệt đã bắt kịp theo thời gian, và các động cơ hiện đại (V8, SpiderMonkey, JavaScriptCore) triển khai đặc tả ES2024 đầy đủ.

ReDoS, từ chối dịch vụ regex (2003 trở đi)

Các nhà nghiên cứu nhận thấy rằng các động cơ regex backtracking có thể mất thời gian theo cấp số nhân trên một số đầu vào nhất định, một loại lỗ hổng được gọi là ReDoS (Regular expression Denial of Service). Một sự cố Cloudflare năm 2019 đã được truy nguồn về một regex với backtracking thảm khốc. Các công cụ như rxxr và node-re2 đã xuất hiện để phát hiện hoặc tránh vấn đề, và các động cơ bắt đầu thực thi ngân sách thời gian trên các kết quả khớp chạy dài.

Các ký tự thoát thuộc tính Unicode hạ cánh trong ECMAScript (2018)

ES2018 đã thêm các ký tự thoát thuộc tính Unicode như \p{Script=Latin} hoặc \p{Letter}, cho phép bạn khớp theo danh mục Unicode mà không cần liệt kê các điểm mã. Kết hợp với cờ u, regex bây giờ có thể phân biệt emoji với chữ cái, các script với nhau và xử lý đúng các cặp surrogate. Điều này làm cho regex JavaScript cuối cùng phù hợp cho việc khớp văn bản quốc tế, một vấn đề mà cú pháp chỉ-ASCII cũ không thể giải quyết.

Quy trình thực tế

Xác thực email

Thả một mẫu email hợp lệ và không hợp lệ vào khu vực thử nghiệm, gõ regex ứng cử của bạn (một điểm khởi đầu phổ biến là ^[^@\s]+@[^@\s]+\.[^@\s]+$), và điều chỉnh cho đến khi email hợp lệ được tô sáng và email không hợp lệ thì không. Hãy lưu ý rằng đặc tả email RFC 5321 đầy đủ phức tạp đến mức regex email hoàn hảo dài hàng trăm ký tự. Một regex thực dụng bắt lỗi chính tả; xác thực cuối cùng nên đi vòng qua SMTP thực tế.

Phân tích cú pháp và trích xuất URL

Dán một trang HTML hoặc văn bản thuần và viết một regex để trích xuất URL. Một mẫu khởi đầu như https?:\/\/\S+ bắt được hầu hết các trường hợp. Đối với mã sản xuất, hãy ưu tiên constructor URL (new URL(string)) xử lý mọi trường hợp cạnh; regex tốt nhất cho các trích xuất nhanh một lần hoặc phân tích log.

Scraping tệp log

Log Apache và NGINX tuân theo định dạng cố định. Dán một vài dòng log, viết một regex với bắt giữ có tên ((?\S+) (?\S+ \S+) \"(?[^"]+)\" ...), và bạn có một parser sẵn sàng để cung cấp vào một bộ phân tích log có cấu trúc. Kiểm tra trên một mẫu log thực tế của bạn trước khi triển khai.

Tìm và thay thế trong trình chỉnh sửa mã

VSCode, Sublime Text, các IDE JetBrains và vim đều chấp nhận regex trong hộp thoại find-replace của họ. Lặp lại mẫu ở đây trước, với bộ làm nổi bật trực tiếp hiển thị chính xác những gì khớp, sau đó dán regex vào hộp thoại của trình chỉnh sửa. Tự cứu bản thân khỏi nỗi đau của những lần bắn nhầm trên một codebase 5.000 dòng.

Web scraping các tên lớp CSS

Khi bạn cần trích xuất dữ liệu từ HTML mà không có parser (một script một lần, không phải sản xuất), một regex như class="([^"]+)" rút ra các thuộc tính class. Đối với bất cứ điều gì vượt quá việc khám phá nhanh, hãy chuyển sang một thư viện DOM thích hợp; HTML không phải là một ngôn ngữ thông thường và regex bỏ lỡ các trường hợp cạnh.

Xác thực chuỗi semantic version

Semver tuân theo ^\d+\.\d+\.\d+(-[\w.]+)?(\+[\w.]+)?$. Thả một danh sách các phiên bản (1.0.0, 1.2.3-beta.1+build.456) vào khu vực thử nghiệm để kiểm tra regex bắt được metadata pre-release và build một cách chính xác. Điều này hữu ích khi xác thực các phụ thuộc trong các script CI.

Cạm bẫy phổ biến

Định lượng greedy vs lazy

Theo mặc định *, +, và ? là greedy: chúng khớp càng nhiều càng tốt, sau đó backtrack nếu phần còn lại của regex thất bại. Các phiên bản lazy *?, +?, ?? khớp ít nhất có thể. Ví dụ kinh điển là <.*> trên text khớp toàn bộ chuỗi, trong khi <.*?> chỉ khớp và riêng biệt. Chọn cái phù hợp để tránh những bất ngờ over-matching.

Backtracking thảm khốc (ReDoS)

Các định lượng lồng nhau như (a+)+ hoặc (.*)* trên một đầu vào không khớp dài có thể mất thời gian theo cấp số nhân khi động cơ thử mọi kết hợp. Tab trình duyệt có thể bị treo hoặc sập. Tránh các nhóm định lượng chồng chéo, ưu tiên các nhóm nguyên tử (?>...) nơi được hỗ trợ, hoặc xác thực trước độ dài đầu vào. Thư viện npm safe-regex tự động đánh dấu các mẫu rủi ro.

Các ký tự đặc biệt cần được escape

Các ký tự có ý nghĩa đặc biệt trong regex (. * + ? ^ $ ( ) [ ] { } | \) phải được escape bằng dấu gạch chéo ngược để khớp theo nghĩa đen. Vì vậy \. khớp một dấu chấm, trong khi . khớp bất kỳ ký tự nào. Quên escape là nguyên nhân phổ biến nhất của các kết quả dương tính giả khi xác thực IP, phần mở rộng tệp, hoặc số phiên bản có dấu chấm.

Neo và cờ multiline

Không có cờ m, ^ và $ chỉ khớp đầu và cuối của toàn bộ chuỗi. Với m, chúng khớp đầu và cuối của mỗi dòng. Nếu regex của bạn hoạt động trên các dòng đơn nhưng thất bại trên đầu vào nhiều dòng, hãy chuyển đổi m. Ngược lại, nếu nó khớp quá nhiều trên đầu vào nhiều dòng, hãy xóa m.

Sự khác biệt cú pháp giữa các động cơ

Trình kiểm tra này sử dụng regex JavaScript. re của Python sử dụng (?P) cho bắt giữ có tên thay vì (?), .NET cho phép backreference \k khác đi, và PCRE có các tính năng như subpattern đệ quy (?R) mà JavaScript thiếu. Nếu mục tiêu cuối cùng của bạn là Python hoặc Java, hãy xác thực trên các động cơ đó trước khi vận chuyển.

Unicode không có cờ u

Không có cờ u, regex JavaScript coi các cặp surrogate (emoji, bổ sung CJK) là hai đơn vị mã riêng biệt. \u{1F600} (emoji mặt cười) không hoạt động nếu không có u. Với cờ u, regex trở thành Unicode-aware, các ký tự thoát thuộc tính như \p{Letter} trở nên có sẵn, và xử lý cặp surrogate là chính xác. Luôn đặt u khi khớp văn bản quốc tế.

Quyền riêng tư và xử lý dữ liệu

Mỗi regex được biên dịch và thực thi bởi động cơ RegExp của trình duyệt của bạn. Chúng tôi không gửi mẫu của bạn, chuỗi thử nghiệm của bạn, hoặc mẫu thay thế của bạn đến bất kỳ máy chủ nào. Matcher chạy cục bộ, các điểm nổi bật được render cục bộ, và danh sách Match Details được tính toán cục bộ. Không có analytics nào liên kết với nội dung đầu vào của bạn.

Sau khi trang được tải, trình kiểm tra hoạt động ngoại tuyến. Bạn có thể ngắt kết nối khỏi mạng, dán các dòng log nhạy cảm hoặc PII, và chạy các mẫu chống lại chúng mà không có dữ liệu nào rời thiết bị của bạn. Điều này làm cho công cụ an toàn để kiểm tra regex chống lại dữ liệu sản xuất mà không gửi nó qua dịch vụ bên thứ ba.

Khi không sử dụng regex

Phân tích cú pháp HTML hoặc XML

HTML không phải là một ngôn ngữ thông thường. Bạn không thể tin cậy phân tích các thẻ lồng nhau với regex; câu trả lời Stack Overflow nổi tiếng về Zalgo và Cthulhu đưa ra điểm này một cách đầy màu sắc. Sử dụng DOMParser hoặc một thư viện như cheerio (Node.js) hoặc BeautifulSoup (Python) thay thế. Regex phù hợp cho các trích xuất một lần nhưng bị phá vỡ trên các trường hợp cạnh như thẻ self-closing, comment, CDATA và đầu vào không đúng định dạng.

Bất cứ điều gì thực sự đệ quy (JSON, mã nguồn, biểu thức toán học)

Dấu ngoặc nhọn cân bằng, dấu ngoặc cân bằng, các lệnh gọi hàm lồng nhau, ưu tiên số học, tất cả đều yêu cầu ngữ pháp không có ngữ cảnh, không phải ngữ pháp thông thường. Sử dụng một parser combinator (Parsimmon, nom) hoặc một generator (pegjs, antlr). Regex có thể khớp các token mở hoặc đóng nhưng không thể theo dõi cân bằng.

Khi một thao tác chuỗi đơn giản đủ rồi

Nếu bạn cần kiểm tra xem một chuỗi có bắt đầu bằng prefix-, hãy sử dụng str.startsWith("prefix-"), không phải /^prefix-/. Các phương thức chuỗi nhanh hơn, rõ ràng hơn và không thể bị sai với các định lượng. Dành regex cho các mẫu mà các phương thức chuỗi không thể diễn đạt.

Xác thực schema phức tạp

Xác thực rằng một tài liệu JSON có một hình dạng cụ thể (các trường bắt buộc, các loại lồng nhau, phạm vi giá trị) tốt hơn nhiều khi được thực hiện với một trình xác thực JSON Schema (ajv, zod, joi) so với regex. Regex có thể kiểm tra định dạng nhưng không phải cấu trúc, và một regex cố gắng xác thực một tài liệu JSON là một cơn ác mộng bảo trì.

Thêm câu hỏi

Khi nào tôi nên sử dụng lookahead vs lookbehind?

Lookahead (?=...) khẳng định rằng những gì theo sau khớp mà không tiêu thụ nó; lookbehind (?<=...) làm điều tương tự cho những gì đứng trước. Sử dụng lookahead khi bối cảnh tiếp theo xác định liệu có khớp hay không, lookbehind khi bối cảnh đứng trước xác định. JavaScript đã hỗ trợ cả hai từ năm 2018 (ES2018), và tất cả các trình duyệt hiện đại đều như vậy. Các phiên bản Safari cũ hơn trước 16.4 thiếu hỗ trợ lookbehind.

Lookbehind có được hỗ trợ trong tất cả các trình duyệt không?

Lookbehind (tích cực và phủ định) được hỗ trợ trong Chrome từ phiên bản 62 (2017), Firefox từ 78 (2020), Edge từ 79 (2020) và Safari từ 16.4 (2023). Nếu khán giả của bạn có thể sử dụng Safari cũ hơn, hãy tránh lookbehind hoặc polyfill với một mẫu thay thế. Đối với Node.js, lookbehind đã được hỗ trợ từ 10.0.

Cờ Unicode (u) làm gì?

Cờ u bật chế độ Unicode: các cặp surrogate được coi là một ký tự duy nhất, các ký tự thoát \u{...} hoạt động, và các ký tự thoát thuộc tính \p{...} trở nên có sẵn. Không có u, một emoji như mặt cười được tính là hai đơn vị mã và . chỉ khớp nửa đầu tiên. Luôn đặt u khi làm việc với văn bản ngoài ASCII.

Động cơ regex nhanh như thế nào?

Động cơ RegExp của V8 sử dụng triển khai Irregexp được biên dịch sang mã native. Đối với các mẫu đơn giản, nó khớp hàng triệu ký tự mỗi giây. Các mẫu bệnh lý (các định lượng lồng nhau trên đầu vào đối kháng) có thể nổ tung lên thời gian theo cấp số nhân, đó là lý do ReDoS là một vector tấn công thực sự. Các động cơ hiện đại áp dụng heuristic để phát hiện và hủy bỏ các kết quả khớp chạy mất kiểm soát, nhưng bạn vẫn nên tránh các mẫu rủi ro.

Regex JavaScript và Python khác nhau như thế nào?

Các nhóm có tên sử dụng cú pháp khác nhau (? trong JS, ?P trong Python). Python thiếu cờ y (sticky); JavaScript thiếu chế độ verbose của Python. Python hỗ trợ đệ quy thông qua module regex của bên thứ ba nhưng không có re tích hợp. Cách viết tắt lớp ký tự khác nhau một chút (\d có nghĩa là [0-9] trong cả hai, nhưng \w trong Python bao gồm dấu gạch dưới ở chế độ Unicode trong khi JS yêu cầu cờ u cho hành vi tương tự).

Tôi có thể sử dụng AI để tạo regex thay thế không?

Các LLM giỏi đề xuất các mẫu regex ban đầu nhưng thường xuyên tạo ra đầu ra sai tinh tế (greedy nơi cần lazy, thiếu escape, cờ sai). Sử dụng AI cho các bản nháp đầu tiên, sau đó xác thực bằng cách chạy regex chống lại các mẫu thực trong trình kiểm tra này. Lặp lại cho đến khi các điểm nổi bật khớp chính xác với những gì bạn mong đợi. Vòng lặp phản hồi tương tác bắt được các lỗi LLM trước khi chúng được vận chuyển đến sản xuất.