Lembar Contekan Regex Gratis

Sejarah singkat bahasa pola

Ekspresi reguler bermula sebagai bagian ilmu komputer teoritis. Stephen Kleene mendefinisikan "himpunan reguler" dalam makalah 1956 tentang jaringan saraf; Ken Thompson menanamnya di Unix pada 1968 lewat grep. Pustaka regex sumber terbuka Henry Spencer (pertengahan 1980-an) menjadi dasar banyak implementasi setelahnya. Larry Wall memperluas sintaks secara drastis di Perl, dan "Perl-compatible regular expressions" (PCRE) ciptaannya menjadi standar de facto yang diikuti sebagian besar bahasa modern. Hari ini terdapat beberapa varian regex yang sangat terkait namun berbeda halus, dan pola yang berfungsi di satu mesin tidak selalu berfungsi sama persis di mesin lain.

Mesin tempat pola Anda hidup

Sintaks yang sama dapat berarti hal berbeda di mesin yang berbeda. Keluarga besar:

• POSIX BRE (Basic Regular Expressions), digunakan oleh mode bawaan grep dan sed. Banyak metakarakter membutuhkan escape backslash: (, ), {, }, +, ?, | bersifat literal kecuali di-escape.
• POSIX ERE (Extended Regular Expressions), digunakan oleh egrep dan awk. Metakarakter di atas berfungsi tanpa escape.
• PCRE (Perl-Compatible Regular Expressions), memperluas ERE dengan lookaround, kelompok atomik, tangkapan bernama, dan referensi balik. Digunakan oleh PHP dan sebagian besar bahasa modern. Singkatan kelas turunan Perl \d, \w, \s umum di PCRE, JavaScript, .NET, Java, dan Python.
• JavaScript RegExp, mirip PCRE tetapi dengan perbedaan penting. ES2018 menambahkan lookbehind, kelompok tangkap bernama, flag dotall s, dan escape properti Unicode lewat flag u. Flag v untuk notasi himpunan tiba di ES2024.
• Python re dan Python regex, re berada di pustaka standar; modul pihak ketiga regex menambahkan fitur peka Unicode, lookbehind lebar variabel, dan peningkatan ala PCRE lainnya.
• RE2 (pustaka Google, dipakai di Go), menjamin waktu linier tetapi tidak mendukung referensi balik atau lookaround. Kompensasinya: performa yang dapat diprediksi, fitur lebih sedikit.

Penguji interaktif lembar contekan ini berjalan di JavaScript, jadi pola dievaluasi oleh mesin JS peramban. Pola yang berfungsi di sini mungkin berperilaku berbeda di Python atau PHP. Sebagian besar perbedaan berada pada fitur lanjutan (lookbehind, escape properti Unicode, referensi balik), bukan sintaks dasar.

Blok bangunan inti

Hampir setiap pola regex dibangun dari unsur-unsur berikut:

• Literal, cocok dengan dirinya sendiri. cat cocok dengan substring "cat".
• Jangkar, ^ (awal string atau baris), $ (akhir), \b (batas kata), \B (bukan batas kata).
• Kelas karakter, [abc] mencocokkan a, b, atau c. [^abc] menegasikan. [a-z] adalah rentang. Singkatan: \d (digit), \w (karakter kata: huruf, digit, garis bawah), \s (spasi putih), dan versi huruf besar untuk negasi (\D, \W, \S).
• Kuantor, ? (0 atau 1), * (0 atau lebih), + (1 atau lebih), {n}, {n,}, {n,m}. Bawaannya tamak (mencocokkan sebanyak mungkin); tambahkan ? untuk malas: *?, +?, ??.
• Kelompok, (...) menangkap, (?:...) tidak menangkap, (?<name>...) bernama (PCRE, JS, Python).
• Alternasi, cat|dog mencocokkan salah satunya.
• Lookaround, (?=...) lookahead positif, (?!...) lookahead negatif, (?<=...) lookbehind positif, (?<!...) lookbehind negatif. Mencocokkan tanpa memakan karakter.
• Referensi balik, \1, \2 (bernomor), \k<name> (bernama). Mencocokkan teks yang sama dengan apa yang ditangkap oleh kelompok terkait.
• Flag, g (global), i (tidak peka huruf besar/kecil), m (multilinear: ^ dan $ cocok pada batas baris), s (dotall: . cocok dengan newline), u (Unicode), y (sticky di JS).

Pola yang layak diingat

Beberapa pola sering muncul, sehingga layak untuk diingat:

Catatan tentang regex email: validasi email penuh RFC 5322 memerlukan regex raksasa 6.000 karakter. Bentuk sederhana di atas menerima 99% alamat email asli dan tidak menolak satu pun yang sah; untuk produksi, kirim email konfirmasi alih-alih mencoba memvalidasi sintaks dengan sempurna.

Tamak vs malas: kejutan yang sering muncul

Secara bawaan, kuantor bersifat tamak: mereka mencocokkan sebanyak mungkin selama pola keseluruhan masih bisa cocok. Jadi <.+> terhadap <a>text</a> mencocokkan seluruh string, bukan hanya <a>, karena .+ menarik sebanyak yang bisa. Untuk mencocokkan string sekecil mungkin, tambahkan ? pada kuantor: <.+?> mencocokkan <a> lalu </a> secara terpisah. Pilihan tamak/malas adalah salah satu sumber bug terbanyak yang berbentuk "kenapa regex saya tidak mencocokkan yang saya harapkan".

Backtracking katastrofik dan ReDoS

Beberapa pola regex dapat memakan waktu eksponensial untuk gagal pada input tertentu, sebuah kelas kerentanan denial-of-service bernama ReDoS (Regular Expression Denial of Service). Pelaku klasiknya adalah kuantor bersarang seperti (a+)+ atau (a|aa)+ yang diterapkan pada untaian panjang a diikuti karakter yang tidak cocok. Mesin mencoba setiap kemungkinan cara membagi string sebelum menyerah, dan jumlah caranya eksponensial.

Insiden dunia nyata: gangguan Cloudflare 2019 dipicu oleh regex yang dipasang di aturan WAF, yang katastrofik melakukan backtracking pada input tertentu. Stack Overflow mengalami insiden serupa pada Juli 2016: sebuah regex post-trim (^[\s‌]+|[\s‌]+$) menemui backtracking eksponensial pada satu komentar berisi kira-kira 20.000 karakter spasi berturut-turut dan mematikan situs selama 34 menit. Kebiasaan defensif: hindari kuantor bersarang, lebih suka kelompok atomik ((?>...)) bila didukung, dan pertimbangkan memakai RE2 atau mesin waktu linier untuk input tidak tepercaya.

Keanehan per bahasa yang layak diketahui

• JavaScript: backslash butuh escape ganda di literal string ("\\d") tetapi tidak di literal regex (/\d/). Gunakan bentuk literal regex jika memungkinkan.
• Python: pakai raw string (r"\d+") untuk menghindari masalah backslash. Modul re di pustaka standar; regex di PyPI menambahkan fitur ekstra.
• Java: backslash butuh escape empat kali ("\\\\d" untuk \d) karena literal string Java memakai \ sebagai escape lalu compiler regex melihat \\d.
• Bash: pencocokan regex di [[ string =~ pattern ]] memakai POSIX ERE. Aturan kutipnya rumit; lihat man bash.
• Go: memakai RE2, jadi referensi balik dan lookaround tidak tersedia. Kompensasinya: jaminan waktu linier.

Kapan TIDAK menggunakan regex

Kalimat terkenal Jamie Zawinski tahun 1997: "Sebagian orang, saat dihadapkan pada masalah, berpikir 'aku tahu, aku akan pakai ekspresi reguler.' Sekarang mereka punya dua masalah."

• Jangan parsing HTML atau XML dengan regex. Gunakan parser sungguhan (DOMParser di peramban, BeautifulSoup di Python, jsoup di Java, dll.). Struktur bersarang HTML pada dasarnya di luar yang bisa diungkapkan regex secara rapi.
• Jangan parsing JSON dengan regex. Gunakan JSON.parse atau parser JSON pustaka standar.
• Jangan validasi email secara ketat dengan regex. Kirim email konfirmasi; itulah satu-satunya uji yang andal.
• Jangan menulis parser CSV sebagai regex. Bidang berkutip dengan koma di dalamnya, kutip yang di-escape, dan nilai multi-baris cepat melampaui apa yang dapat ditangani regex dengan rapi.
• Jangan coba mencocokkan tanda kurung berpasangan. Regex standar tidak bisa (itu bahasa bebas konteks); beberapa mesin PCRE punya fitur rekursi yang "curang", tetapi parser sungguhan lebih rapi.

Kesalahan umum

1. Lupa meng-escape karakter khusus. ., *, ?, +, (, ), [, ], {, }, \, ^, $, |, / semuanya memiliki makna khusus. Untuk mencocokkannya secara literal, awali dengan backslash.
2. Kuantor tamak menelan terlalu banyak. Tambahkan ? untuk pencocokan malas ketika menginginkan kecocokan terkecil.
3. Lupa flag global dan bertanya-tanya kenapa hanya kecocokan pertama yang muncul. String.prototype.match() di JavaScript hanya mengembalikan kecocokan pertama tanpa flag g.
4. Backtracking katastrofik pada input panjang. Kuantor bersarang seperti (a+)+ bisa macet pada input tertentu. Uji dengan kasus tepi.
5. Mengasumsikan regex yang sama berperilaku sama di setiap bahasa. Lookbehind, escape Unicode, dan singkatan kelas karakter semua berbeda.
6. Mencoba memvalidasi email terlalu ketat. Regex RFC 5322 yang benar secara teknis tidak dapat dipelihara; regex sederhana ditambah email konfirmasi saat pendaftaran adalah pola yang berhasil.
7. Memakai regex pada HTML, JSON, atau CSV. Gunakan parser yang tepat; waktu yang dihemat di muka akan hilang oleh bug.

Pertanyaan lain yang sering diajukan

Kenapa pola saya berfungsi di sini tetapi gagal di kode saya?

Penyebab paling umum adalah perbedaan mesin. RegExp JavaScript tidak mendukung beberapa fitur yang dimiliki PCRE (dan sebaliknya). Jebakan umum: lookbehind ditambahkan terlambat ke JS (ES2018), sintaks kelompok bernama sedikit berbeda, escape properti Unicode memerlukan flag u, dan kelas karakter POSIX seperti [[:alpha:]] umumnya tidak ada di JS. Uji di mesin yang akan Anda gunakan untuk produksi.

Adakah cara "global" untuk mencocokkan lintas banyak baris?

Dua flag bekerja bersama. Flag m (multilinear) membuat ^ dan $ cocok di awal dan akhir setiap baris alih-alih seluruh string. Flag s (dotall) membuat . juga cocok dengan karakter newline. Dipadu dengan g untuk global, Anda bisa menulis pola lintas-baris yang menemukan setiap kecocokan: /^foo.+$/gms.

Apakah pola dan teks uji saya dikirim ke mana pun?

Tidak. Pencocokan pola memakai mesin JavaScript RegExp bawaan peramban; tidak ada yang diunggah ke server mana pun. Ini penting saat Anda menguji pola terhadap data log produksi nyata, respons API internal, atau konten sensitif.

Apakah saya perlu mempelajari lookbehind?

Berguna tetapi tidak esensial. Lookbehind memungkinkan Anda mencocokkan teks yang didahului oleh sesuatu tanpa memasukkan "sesuatu" itu ke dalam kecocokan. Contoh: (?<=\$)\d+ mencocokkan digit setelah tanda dolar tanpa menelan tanda dolar. Didukung di PCRE, JavaScript modern (ES2018+), dan modul regex Python. Jika menulis pola portabel, periksa mesin target terlebih dahulu.

Mengapa memakai (?:...) alih-alih (...)?

Kelompok tanpa penangkapan ((?:...)) sedikit lebih cepat, tidak menempati slot dalam larik tangkap, dan menjaga hasil pencocokan tetap rapi. Gunakan kapanpun Anda butuh mengelompokkan untuk alternasi atau kuantifikasi tetapi tidak butuh mengekstrak teks yang cocok. (http|https):// membuat tangkapan yang mungkin tak diperlukan; (?:http|https):// tidak.

Apa cara yang tepat untuk mencocokkan karakter Unicode?

Di JavaScript, tambahkan flag u dan gunakan escape properti Unicode: /\p{Letter}+/gu mencocokkan rangkaian huruf di aksara mana pun. Tanpa flag u, \w hanya mencocokkan karakter kata ASCII. Modul re Python peka Unicode secara bawaan di Python 3. Java butuh Pattern.UNICODE_CHARACTER_CLASS. Sebagian besar mesin punya cara untuk peka Unicode; lihat dokumentasi mesin Anda.