ข้อความ

Regex Tester / Find & Replace

ทดสอบ regular expression กับข้อความจริง: ไฮไลต์ที่ตรงกันและกลุ่มที่จับได้ถูกวิเคราะห์ หรือแทนที่สิ่งที่ตรงกันด้วยข้อความใหม่


                        

                        

A regular expression (regex) is a compact language for describing patterns in text — for searching, validating a format, or replacing matches. This tool highlights matches in real text as you type the pattern, breaks out capture groups, and supports a find-and-replace mode.

How to use it

Common uses

Things to keep in mind

Greedy quantifiers (*, +) grab as many characters as possible — add ? for the minimal match instead (e.g. .*? instead of .*).

Syntax varies slightly between languages — an expression that works here (a JavaScript engine) may need adjusting for PCRE, .NET, or Python.

บทความเกี่ยวกับเครื่องมือนี้: Regular Expression: พื้นฐานและกับดักของการจับคู่แบบโลภ

คำถามที่พบบ่อย

ใช้เอนจิ้น regex แบบใด?

เครื่องมือนี้ใช้เอนจิ้น regex ของ JavaScript ไม่ใช่ PCRE ดังนั้นไวยากรณ์เฉพาะของ PCRE บางอย่าง (เช่น assertion แบบเรียกซ้ำหรือโหมดจับคู่แบบ possessive บางอย่าง) จะไม่ทำงานที่นี่; รองรับแฟล็กทั่วไป เช่น g, i, m, s และ u

ตัวระบุจำนวนแบบ greedy กับ lazy ต่างกันอย่างไร และ Test กับ Replace ต่างกันอย่างไร?

ตัวระบุจำนวนแบบ greedy เช่น * หรือ + จะจับข้อความให้ได้มากที่สุด ในขณะที่เวอร์ชัน lazy (*?, +?) จะหยุดโดยเร็วที่สุด; สำหรับโหมด Test จะไฮไลต์ผลที่ตรงกันและแสดงกลุ่มจับคู่ (รวมถึงกลุ่มที่มีชื่อ) ส่วน Replace จะใช้ข้อความแทนที่ พร้อมการอ้างอิงเช่น $1 กับผลที่ตรงกันแต่ละรายการ

ข้อความและนิพจน์ของฉันถูกส่งไปยังเซิร์ฟเวอร์หรือไม่?

ไม่ การประเมินนิพจน์ปกติเกิดขึ้นทั้งหมดฝั่งไคลเอนต์ในเบราว์เซอร์ของคุณ ไม่มีอะไรถูกส่งออนไลน์

Catastrophic backtracking คืออะไร?

Quantifier ที่ซ้อนกันเช่น (a+)+ อาจทำให้เอนจิ้นต้องไล่ลองความเป็นไปได้จำนวนมหาศาลแบบ exponential กับข้อมูลนำเข้าบางแบบ — หน้าเว็บหรือสคริปต์อาจ "ค้าง" กับนิพจน์ที่ดูเรียบง่าย นี่คือช่องโหว่จริง (ReDoS) ดังนั้น quantifier ที่ซ้อนกันซับซ้อนควรทดสอบกับข้อความยาว ๆ ที่เกือบตรงกัน

ทำไมนิพจน์ของฉันทำงานในภาษาโปรแกรมหนึ่ง แต่ไม่ทำงานในอีกภาษา?

ไวยากรณ์ regex ไม่ได้เป็นมาตรฐานเดียวกันทั้งหมด: PCRE (PHP และอีกหลายภาษา), .NET, Python re และ JavaScript มีความแตกต่างเล็กน้อยในการรองรับบางโครงสร้าง (เช่น look-behind หรือกลุ่มที่มีชื่อ) — นิพจน์ที่เขียนสำหรับเอนจิ้นหนึ่งอาจไม่ทำงานเหมือนเดิมในอีกเอนจิ้นโดยไม่มีการแก้ไข

บทความ: ข้อความ

camelCase, snake_case, kebab-case: ควรใช้รูปแบบไหนเมื่อไหร่

เหตุใดจึงมี camelCase, snake_case และ kebab-case และแต่ละแบบมักใช้ที่ไหน

Text Diff: อัลกอริทึมหาความแตกต่างของข้อความทำงานอย่างไร

อัลกอริทึม diff หาชุดการเปลี่ยนแปลงที่น้อยที่สุดระหว่างข้อความสองเวอร์ชันได้อย่างไร

การเรียงบรรทัด: ทำไมการเรียงตามตัวอักษรถึงต่างจากการเรียงตามตัวเลข

เหตุใดการเรียงตามตัวอักษรจึงปฏิบัติต่อตัวเลขเหมือนข้อความ และต่างจากการเรียงตามตัวเลขอย่างไร

การ Escape สตริง: ทำไมกฎถึงต่างกันใน JS, JSON, shell และ regex

เหตุใดจึงไม่มีกฎการ escape เดียวที่ใช้ได้ทุกที่ — JS, JSON, shell และ regex ต่างก็มีกฎของตัวเอง

CRLF กับ LF: ทำไมการขึ้นบรรทัดใหม่ยังคงสร้างปัญหา

ความแตกต่างระหว่าง CRLF กับ LF มาจากไหน และเหตุใดยังคงสร้างปัญหากับ git และสคริปต์

การนับตัวอักษรและคำ: ทำไม Unicode ทำให้ซับซ้อน

เหตุใดอิโมจิหนึ่งตัวที่เห็นด้วยตาจึงอาจประกอบด้วย code point หลายตัวใน Unicode

Lorem Ipsum: ข้อความหลอกนี้มาจากไหนและทำไมไม่มีความหมาย

ข้อความ Lorem Ipsum มาจากไหนจริง ๆ และเหตุใดจึงใช้ข้อความไร้ความหมายแทนข้อความจริง

Slugify: หัวข้อกลายเป็น URL ที่ใช้งานได้อย่างไร

หัวข้อบทความกลายเป็น URL ที่สะอาดและอ่านง่ายด้วยเครื่องหมายขีดได้อย่างไร

Markdown: ทำไมจึงกลายเป็นมาตรฐานของเอกสาร

เหตุใด Markdown จึงยังอ่านง่ายแม้ในรูปแบบดิบ ต่างจาก HTML

ช่องว่างที่มองไม่เห็น: ทำไมการเปรียบเทียบข้อความที่ดูเหมือนกันจึงล้มเหลว

ช่องว่างที่มองไม่เห็นเพียงตัวเดียวทำให้การเปรียบเทียบข้อความสองชิ้นที่ดูเหมือนกันล้มเหลวได้อย่างไร

การกลับข้อความ: ทำไมจึงพังกับอิโมจิ

เหตุใดการกลับข้อความแบบง่ายจึงทำให้อิโมจิที่ประกอบจาก code point หลายตัวพังไป

การวิเคราะห์ความถี่ข้อความ: จาก word cloud สู่การถอดรหัส

การวิเคราะห์ความถี่ตัวอักษรช่วยถอดรหัสแบบแทนที่อักษรง่าย ๆ ในอดีตได้อย่างไร