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

Bugs Produksi Pukul 3 Pagi yang Mengubah Cara Saya Berpikir Tentang Regex

Saya masih ingat malam saat saya mendapat telepon. Itu pukul 3:17 pagi, dan sistem pemrosesan pembayaran kami baru saja menolak 847 transaksi kartu kredit yang sah dalam waktu 12 menit. Sebagai insinyur backend utama di sebuah startup fintech yang memproses $2,3 juta dalam transaksi harian, saya segera mengenakan hoodie dan membuka laptop saya dengan tangan yang bergetar. Penyebabnya? Satu karakter yang salah letak dalam pola regex yang telah ada di repositori kode kami selama delapan bulan.

Insiden itu mengakibatkan kerugian sebesar $43.000 bagi kami dan hampir menghancurkan kemitraan yang telah kami bangun selama enam bulan. Tetapi itu mengajarkan saya sesuatu yang tak ternilai: regex bukan hanya alat lain dalam toolkit pengembang Anda—ini adalah instrumen presisi yang membutuhkan penghormatan, pemahaman, dan praktik yang konstan. Selama 12 tahun saya membangun sistem di tiga startup dan dua perusahaan Fortune 500, saya telah menulis ribuan pola regex. Saya telah mendebug regex yang membuat pengembang senior menangis. Saya telah mengoptimalkan pola yang mengurangi waktu pemrosesan dari 4,2 detik menjadi 180 milidetik.

Ini bukan lembar contekan regex biasa dengan penjelasan sintaksis yang membosankan. Ini adalah panduan yang saya harap saya miliki saat saya mendebug sistem pembayaran itu pada pukul 3 pagi. Ini dibangun dari skenario produksi nyata, tolok ukur kinerja yang sebenarnya, dan kebijaksanaan praktis yang hanya bisa didapat dari membuat kesalahan mahal. Apakah Anda memvalidasi masukan pengguna, mem-parsing file log, atau membangun saluran data, pola dalam panduan ini akan menghemat jam untuk debugging dan berpotensi ribuan dolar dalam insiden produksi.

Memahami Dasar-Dasar Regex: Di Luar Dasar-Dasar

Sebelum kita masuk ke pola-pola spesifik, mari kita buat model mental yang benar-benar bekerja. Kebanyakan pengembang menganggap regex sebagai alat pencocokan, tetapi itu seperti menganggap pisau Swiss Army hanya sebagai bilah. Regex adalah bahasa pemrograman deklaratif untuk pengenalan pola, dan memahami perbedaan ini mengubah segala sesuatu tentang cara Anda menghadapi masalah.

Regex bukan hanya pencocokan pola—ini adalah bahasa deklaratif di mana setiap karakter adalah kontrak dengan mesin. Perbedaan antara pola yang baik dan yang hebat bukanlah kompleksitas, tetapi presisi.

Blok bangunan inti lebih sederhana daripada yang Anda pikirkan. Karakter literal mencocokkan dirinya sendiri—pola "kucing" mencocokkan string "kucing". Tetapi kekuatan sebenarnya datang dari metakarakter: simbol yang mewakili kelas karakter atau posisi. Titik (.) mencocokkan karakter tunggal apa pun kecuali baris baru. Asterisk (*) berarti "nol atau lebih dari elemen sebelumnya". Plus (+) berarti "satu atau lebih". Tanda tanya (?) berarti "nol atau satu".

Di sinilah sebagian besar tutorial gagal memberi Anda pemahaman: mereka tidak menjelaskan bahwa mesin regex bekerja secara berbeda. PCRE (Perl Compatible Regular Expressions) mendukung PHP, modul re Python, dan banyak bahasa lainnya. JavaScript menggunakan rasanya sendiri dengan beberapa keanehan. Java memiliki implementasi yang lain. Perbedaan ini penting saat Anda mendebug mengapa pola bekerja dalam skrip Python lokal Anda tetapi gagal dalam kode Node.js produksi.

Kelas karakter adalah alat kekuatan pertama Anda. Alih-alih menulis (a|e|i|o|u) untuk mencocokkan vokal, Anda menulis [aeiou]. Notasi bracket lebih cepat dan lebih mudah dibaca. Ingin mencocokkan angka? Gunakan \d alih-alih [0-9]. Karakter kata apa pun (huruf, angka, atau garis bawah)? Itu \w. Ruang kosong? \s. Versi huruf kapital adalah negasi: \D mencocokkan bukan angka, \W mencocokkan bukan karakter kata, \S mencocokkan bukan spasi.

Jangkar mengontrol di mana pencocokan terjadi. Tanda caret (^) menjepit ke awal string atau baris. Tanda dolar ($) menjepit ke akhir. Pola ^Hello$ hanya mencocokkan string "Hello" yang tepat tanpa ada yang sebelum atau sesudah. Batas kata (\b) lebih halus tetapi sangat berguna—mereka mencocokkan posisi antara karakter kata dan karakter non-kata. Pola \bcat\b mencocokkan "cat" tetapi tidak "kategori" atau "scat".

Kuantifier menentukan berapa kali elemen harus diulang. Kita telah membahas *, +, dan ?, tetapi masih ada lebih banyak presisi yang tersedia. Braces kurung membiarkan Anda menentukan jumlah yang tepat: {3} berarti tepat tiga, {3,} berarti tiga atau lebih, {3,7} berarti antara tiga dan tujuh. Ini sangat penting untuk pola validasi di mana Anda memerlukan persyaratan panjang yang tepat.

Validasi Email: Pola yang Salah Dipahami Oleh Semua Orang

Izinkan saya berbagi pendapat yang kontroversial: sebagian besar pola regex validasi email terlalu ketat atau terlalu longgar. Saya telah melihat sistem produksi menolak email yang sah dari pengguna internasional karena seseorang menyalin pola dari Stack Overflow tanpa memahaminya. Saya juga telah melihat sistem menerima "user@domain" sebagai valid, yang mengakibatkan ribuan email yang gagal terkirim dan pelanggan yang marah.

Spesifikasi RFC 5322 untuk alamat email sepanjang 3.500 kata dan memungkinkan kasus tepi seperti string yang dikutip, komentar, dan alamat IP dalam tanda kurung. Pola regex yang sepenuhnya sesuai lebih dari 6.000 karakter panjangnya dan sama sekali tidak dapat dipelihara. Jangan gunakan itu. Sebagai gantinya, gunakan pola pragmatis yang menangkap 99,8% email di dunia nyata sambil tetap dapat dibaca.

Inilah pola yang saya gunakan di sistem produksi yang menangani lebih dari 50.000 pendaftaran harian:

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

Mari kita uraikan ini. Pola dimulai dengan ^ untuk menjepit di awal. Kemudian [a-zA-Z0-9._%+-]+ mencocokkan satu atau lebih karakter yang merupakan huruf, angka, atau simbol yang biasa digunakan dalam bagian lokal email (bagian sebelum @). Simbol @ adalah literal. Setelah itu, [a-zA-Z0-9.-]+ mencocokkan nama domain, yang dapat berisi huruf, angka, titik, dan tanda hubung. Yang \. mencocokkan titik literal (kita melarikan diri karenanya . adalah metakarakter). Akhirnya, [a-zA-Z]{2,} mencocokkan domain tingkat atas—setidaknya dua huruf. Yang $ menjepit di akhir.

Pola ini menolak sampah yang jelas seperti "user@" atau "@domain.com" sambil menerima domain internasional dan penugasan-plus ([email protected]). Ini tidak akan menangkap setiap kasus tepi, tetapi kasus tepi adalah tepat itu—jarang. Dalam pengalaman saya, 0,2% email yang mungkin ditolak pola ini jauh lebih kecil dibandingkan dengan beban pemeliharaan pola yang lebih kompleks.

Satu pelajaran penting: selalu validasi alamat email dengan mengirim tautan konfirmasi, bukan hanya dengan regex. Saya belajar ini setelah kami menghabiskan tiga minggu mendebug mengapa email tertentu tidak menerima konfirmasi, hanya untuk menemukan bahwa domain tersebut ada tetapi memiliki catatan MX yang salah konfigurasi. Regex memvalidasi format, bukan kemampuan mengirim.

Parsing dan Validasi URL: Menangani Web Modern

URL sangat kompleks. Mereka dapat memiliki protokol, subdomain, port, jalur, parameter kueri, dan fragmen. Mereka dapat menggunakan nama domain internasional dengan karakter Unicode. Mereka dapat bersifat relatif atau absolut. Pola URL yang kuat perlu menangani kompleksitas ini sambil tetap berkinerja baik.

Saya telah melihat pengembang menghabiskan berjam-jam mendebug logika aplikasi ketika masalah sebenarnya adalah pola regex yang 99% benar. Dalam sistem produksi, 1% itu akan menemui Anda pada pukul 3 pagi.

Untuk validasi URL dasar di mana Anda hanya perlu memastikan sesuatu terlihat seperti URL, pola ini bekerja dengan baik:

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

Ini mencocokkan http atau https (s? membuat 's' opsional), diikuti oleh ://, lalu nama domain, lalu opsional jalur. Yang [^\s]* mencocokkan karakter non-spasi untuk bagian jalur. Ini sederhana, cepat, dan menangkap kesalahan yang jelas.

Tapi bagaimana jika Anda perlu mengekstrak komponen dari sebuah URL? Di situlah grup tangkap bersinar. Kurung dalam regex membuat