Bagi manusia, "Indowebsite", "INDOWEBSITE", dan "indowebsite" adalah kata yang sama. Kita membaca ketiganya tanpa berpikir dua kali, karena otak kita memperlakukan bentuk huruf sebagai hiasan, bukan sebagai isi. Komputer tidak selalu sepakat dengan cara pandang itu.
Perbedaan cara pandang inilah yang memunculkan sekumpulan masalah yang terasa akrab. Password ditolak berulang kali padahal Anda yakin sudah mengetiknya dengan benar. Gambar yang normal di komputer sendiri mendadak hilang setelah website diunggah ke server. Halaman yang jelas-jelas ada justru dijawab dengan pesan 404.
Semua gejala tersebut berakar pada satu sifat yang punya nama sendiri, yaitu case sensitive.
Apa Itu Case Sensitive?
Case sensitive adalah sifat sebuah sistem yang memperlakukan huruf besar dan huruf kecil sebagai karakter yang berbeda. Dalam bahasa Indonesia, sifat ini bisa disebut peka huruf besar-kecil. Pada sistem yang memiliki sifat ini, teks "Admin" dan "admin" bukan dua penulisan dari satu kata yang sama, melainkan dua nilai yang sama sekali berbeda.
Jadi apa yang dimaksud dengan case sensitive? Singkatnya, sistem tersebut menganggap kapitalisasi sebagai bagian dari isi data, bukan sekadar gaya penulisan.
Kata case di sini bukan berarti "kasus". Istilahnya diwarisi dari zaman percetakan huruf logam. Penata huruf menyimpan huruf kapital di kotak (case) rak bagian atas dan huruf kecil di kotak bagian bawah. Dari situlah lahir istilah uppercase dan lowercase yang terbawa ke dunia komputer.
Lawannya adalah case insensitive, yaitu sistem yang menganggap huruf besar dan kecil setara. Case insensitive adalah perilaku yang Anda temui saat mengetik alamat website dengan huruf kapital tetapi tetap sampai ke halaman yang benar.
Kenapa Komputer Membedakan Huruf Besar dan Kecil?
Pertanyaan ini lebih menarik daripada definisinya, dan jawabannya menjelaskan hampir semua perilaku aneh yang akan kita bahas selanjutnya.
Komputer tidak menyimpan huruf. Yang disimpan adalah angka. Standar pengkodean karakter yang menjadi fondasi hampir semua sistem modern bernama ASCII (American Standard Code for Information Interchange). Di dalam tabelnya, huruf A disimpan sebagai angka 65 dan huruf a sebagai angka 97. Selisihnya tepat 32.
Diagram kode ASCII: huruf A bernilai 65 dan huruf a bernilai 97, dengan selisih 32 di antara keduanya.
Artinya, saat program membandingkan dua teks, yang sebenarnya dibandingkan adalah dua deretan angka. Bagi program tersebut, 65 dan 97 sama berbedanya seperti 65 dan 12. Tidak ada yang istimewa dari pasangan huruf besar dan kecil kecuali kita sengaja memberitahunya.
Di sinilah kesalahpahaman yang paling umum terjadi. Banyak orang mengira sifat peka huruf adalah tambahan yang dipasang demi keamanan. Kenyataannya justru terbalik.
Peka huruf adalah perilaku bawaan. Perbandingan apa adanya antar-angka memang menghasilkan hasil yang membedakan huruf besar dan kecil. Perilaku case insensitive-lah yang butuh kerja tambahan, karena sistem harus menyeragamkan dulu semua huruf sebelum membandingkannya. Proses penyeragaman itu disebut case folding.
Konsekuensinya sederhana. Di balik setiap sistem yang tidak peka huruf, ada seseorang yang sengaja menuliskan kode untuk membuatnya begitu. Ketika kode itu lupa ditulis, sistem kembali ke perilaku bawaan.
Case Sensitive, Case Insensitive, dan Case Preserving
Ada tiga perilaku yang perlu Anda bedakan di sini, bukan dua. Kategori ketiga adalah yang paling sering Anda pakai sehari-hari tanpa menyadarinya, dan justru kategori itulah yang menyembunyikan masalah sampai terlambat.
- Case sensitive (peka huruf): sistem membedakan huruf besar dan kecil.
Laporan.pdfdanlaporan.pdfadalah dua berkas berbeda yang bisa hidup berdampingan dalam satu folder. Ini perilaku filesystem Linux. - Case insensitive (tidak peka huruf): sistem menganggap keduanya sama. Mengetik
LAPORAN.PDFakan membuka berkaslaporan.pdf. - Case preserving (mempertahankan kapitalisasi): sistem tidak membedakan huruf besar dan kecil saat mencari berkas. Namun kapitalisasi yang Anda ketik saat menyimpan tetap diingat dan ditampilkan apa adanya.
Windows dengan NTFS dan macOS dengan APFS bawaan berada di kategori ketiga. Keduanya sekaligus case insensitive dan case preserving. Kami mengujinya langsung di macOS. Sebuah berkas bernama logo.png tetap terbuka ketika dipanggil sebagai LOGO.PNG, sementara namanya tetap ditampilkan sebagai logo.png.
Tiga kartu berlabel Peka Huruf, Tidak Peka Huruf, dan Mempertahankan Kapitalisasi beserta ikon berkasnya.
Kombinasi itulah yang berbahaya. Anda bisa menuliskan Logo.PNG di dalam kode padahal nama berkasnya logo.png, lalu semuanya berjalan mulus berbulan-bulan di komputer sendiri. Ketidakcocokan itu tersimpan rapi tanpa gejala, sampai berkas tersebut pindah ke sistem yang benar-benar peka huruf.
Peta Cepat: Bagian Mana yang Peka Huruf, Mana yang Tidak
Kesalahan berikutnya adalah menganggap sebuah alamat itu satu kesatuan yang punya satu perilaku. Kenyataannya, satu URL bisa berisi bagian yang peka huruf dan bagian yang tidak, secara bersamaan.
Ambil contoh alamat berikut:
https://www.Indowebsite.co.id/Blog/Case-Sensitive-Adalah| Bagian | Contoh | Peka huruf? | Dasar aturan |
|---|---|---|---|
| Skema | https | Tidak | RFC 3986 |
| Nama host / domain | www.Indowebsite.co.id | Tidak | RFC 4343 (aturan DNS) |
| Path | /Blog/Case-Sensitive-Adalah | Tergantung server | Tidak diatur standar |
| Parameter query | ?id=Abc | Tergantung aplikasi | Tidak diatur standar |
Dua bagian pertama aman. Anda boleh mengetik HTTPS://WWW.INDOWEBSITE.CO.ID dan tetap sampai ke tujuan yang sama. Masalahnya selalu dimulai setelah nama domain berakhir.
Tiga baris alamat web: https:// dan contoh.co.id ditandai tidak peka huruf, sedangkan /Blog/Artikel peka huruf.
Path pada server berbasis Linux bersifat peka huruf, sementara pada server berbasis Windows umumnya tidak. Karena mayoritas hosting di dunia berjalan di atas Linux, aturan praktisnya: anggap saja seluruh bagian setelah nama domain itu peka huruf.
Alamat email punya pembagian yang mirip tetapi dengan kejutan tersendiri. Pada alamat Nama.Pengguna@Contoh.co.id, bagian setelah tanda @ mengikuti aturan DNS sehingga tidak peka huruf. Bagian sebelum @, yang disebut local-part, justru sebaliknya.
RFC 5321, standar pengiriman email, menyatakan bahwa local-part wajib diperlakukan sebagai peka huruf. Namun standar yang sama menyebut bahwa memanfaatkan kepekaan huruf tersebut merusak interoperabilitas dan sebaiknya dihindari. Karena itulah hampir semua penyedia email besar memperlakukan alamat secara tidak peka huruf, meskipun standar mengizinkan sebaliknya.
Gmail bahkan melangkah lebih jauh. Selain mengabaikan huruf besar-kecil, Gmail juga mengabaikan titik pada nama pengguna. Alamat namapengguna@gmail.com dan nama.pengguna@gmail.com sampai ke kotak masuk yang sama. Perlu dicatat, itu kebijakan Google, bukan sifat semua layanan email.
Password punya cerita berbeda karena hampir selalu peka huruf. Penyebabnya, password tidak disimpan sebagai teks melainkan sebagai hash, yaitu hasil pengacakan satu arah. Mengubah satu huruf menghasilkan hash yang sepenuhnya berbeda, sehingga kesalahan kapitalisasi tidak mungkin dimaafkan tanpa merusak keamanannya.
Case Sensitive dalam Bahasa Pemrograman
Mayoritas bahasa pemrograman modern bersifat peka huruf sepenuhnya. Python, JavaScript, Java, C, dan Go semuanya menganggap nama dan Nama sebagai dua variabel yang tidak berhubungan.
Jadi ketika seseorang mengatakan Python bersifat case sensitive, artinya persis itu. Setiap nama variabel, fungsi, dan kelas harus dituliskan dengan kapitalisasi yang sama setiap kali dipanggil. Memanggil variabel nama dengan penulisan Nama bukan menghasilkan nilai kosong, melainkan error:
nama = "Indowebsite"
print(Nama)Hasilnya:
NameError: name 'Nama' is not definedPesan error tersebut sebenarnya kabar baik. Kesalahan kapitalisasi langsung berhenti di tempat, bukan diam-diam menghasilkan data yang salah.
Yang paling membingungkan pemula justru PHP, karena perilakunya campuran di dalam satu bahasa yang sama. Sebagian nama peka huruf, sebagian lagi tidak. Kami mengujinya pada PHP 8.5:
<?php
function halo() { echo "fungsi tetap jalan\n"; }
HALO(); // berhasil — nama fungsi tidak peka huruf
$var = "Bob";
$Var = "Joe";
echo "$var $Var\n"; // menghasilkan: Bob Joe — variabel peka hurufPotongan kode di atas berjalan tanpa error sama sekali. Pemanggilan HALO() berhasil menjalankan fungsi halo(), sedangkan $var dan $Var tetap menyimpan dua nilai berbeda. Aturannya bisa diringkas sebagai berikut:
- Peka huruf: nama variabel dan nama konstanta. Memanggil konstanta
SITUSdengan penulisansitusmenghasilkan fatal error. - Tidak peka huruf: nama fungsi, nama kelas, nama method, dan kata kunci bahasa. Menulis
IF,ECHO, atauTRUEdengan huruf kapital tetap dieksekusi normal.
Pembagian serupa juga muncul di dunia web front-end. Nama tag HTML tidak peka huruf, sehingga <DIV> dan <div> sama saja bagi browser. Sebaliknya, nilai atribut class dan id yang dirujuk dari CSS maupun JavaScript bersifat peka huruf. Selector .menuUtama tidak akan pernah cocok dengan class="menuutama".
Kelonggaran HTML itu tidak berlaku pada XML, meskipun keduanya sama-sama bahasa markup. Penulisan tag XML bersifat peka huruf, sehingga <Nama> tidak dapat ditutup dengan </nama>. Parser akan langsung menolaknya sebagai tag yang tidak cocok.
Ada pula bahasa yang menjadikan kapitalisasi sebagai penentu makna, bukan sekadar pembeda nama. Spesifikasi resmi Golang menyatakan sebuah identifier bersifat exported, yaitu dapat diakses dari paket lain, apabila huruf pertamanya kapital. Menulis Hitung dan hitung di Go bukan sekadar menghasilkan dua nama berbeda, melainkan menentukan mana yang boleh dipakai paket lain dan mana yang tetap privat.
Case Sensitive di Database MySQL
Di MySQL, pertanyaan tentang kepekaan huruf punya dua jawaban yang harus dipisahkan: soal nama objek, dan soal isi data.
Untuk nama objek, pembagiannya cukup tegas. Nama kolom, nama indeks, dan alias kolom tidak pernah peka huruf di platform mana pun. Sementara nama database, tabel, dan trigger bergantung pada sistem operasi, karena semuanya diwakili oleh berkas di disk.
Perilaku itu dikendalikan oleh variabel lower_case_table_names dengan tiga nilai yang mungkin:
| Nilai | Cara menyimpan nama | Cara membandingkan | Default di |
|---|---|---|---|
0 | Apa adanya | Peka huruf | Unix / Linux |
1 | Diubah jadi huruf kecil | Tidak peka huruf | Windows |
2 | Apa adanya | Tidak peka huruf | macOS |
Nilai
lower_case_table_nameshanya bisa ditentukan saat server MySQL diinisialisasi pertama kali. Setelah itu nilainya tidak bisa diubah. Karena itu memperbaiki kebiasaan penamaan jauh lebih murah daripada berharap bisa menyetel ulang server di kemudian hari.
Jawaban kedua menyangkut isi data, dan ini yang lebih sering mengejutkan. Perbandingan isi kolom teks ditentukan oleh collation, yaitu aturan pengurutan dan pembandingan karakter yang melekat pada kolom tersebut. Collation berakhiran _ci (case insensitive) memperlakukan huruf besar dan kecil sebagai sama, sedangkan _bin membandingkan byte demi byte sehingga peka huruf.
Karena MySQL memakai collation _ci secara bawaan, query berikut akan menemukan baris dengan username admin:
SELECT * FROM pengguna WHERE username = 'AdMiN';Inilah sebabnya banyak aplikasi menerima login "Admin" padahal yang terdaftar di database adalah "admin". Perilaku ini nyaman untuk username, tetapi menjadi celah kalau Anda memakainya untuk membandingkan token, kode verifikasi, atau nilai lain yang seharusnya cocok persis.
Ketika Kode Jalan di Laptop tapi Rusak di Hosting
Semua bagian di atas kini bisa disatukan menjadi satu skenario yang mungkin pernah Anda alami sendiri.
Anda membangun website di laptop bersistem Windows atau macOS. Berkas gambarnya bernama logo.png, tetapi di dalam kode Anda menuliskannya sebagai Logo.png. Di laptop semuanya tampil sempurna, karena filesystem-nya tidak peka huruf dan memaafkan perbedaan itu.
Kemudian seluruh berkas diunggah ke server hosting yang berjalan di atas Linux. Filesystem Linux peka huruf, dan bagi server tersebut Logo.png tidak pernah ada. Gambar berubah menjadi ikon rusak, meskipun berkasnya jelas terlihat di dalam folder.
Berkas yang lolos di laptop bertanda centang lalu gagal di server bertanda silang setelah dipindahkan.
Pola yang sama menimbulkan gejala berbeda tergantung apa yang salah nama:
- Gambar dan aset tidak muncul: nama berkas di kode tidak cocok dengan nama berkas sesungguhnya.
- Halaman menjawab 404: nama folder atau nama berkas halaman berbeda kapitalisasinya dengan yang ditulis di tautan.
- Class not found: nama berkas kelas tidak cocok dengan nama kelas yang dicari oleh autoloader.
Yang membuat masalah ini melelahkan adalah waktu kemunculannya. Kesalahan sudah dibuat sejak hari pertama, tetapi baru menampakkan diri pada saat website dipindahkan ke layanan web hosting yang sesungguhnya. Karena itu langkah paling penting justru dilakukan jauh sebelum proses pemindahan, yaitu saat Anda memberi nama.
Cara Aman Menghindari Masalah Case Sensitive
Berikut kebiasaan yang menghilangkan hampir seluruh kelas masalah di atas, diurutkan dari yang paling besar dampaknya.
-
Pakai huruf kecil untuk semua nama berkas dan folder. Aturan ini tidak punya pengecualian yang sepadan. Kalau butuh pemisah kata, gunakan tanda hubung, misalnya
logo-utama.png, bukanLogoUtama.png. Dokumentasi MySQL juga menyarankan hal yang sama untuk nama database dan tabel demi portabilitas antar sistem operasi. -
Terapkan aturan yang sama pada slug URL. Alamat berhuruf kecil mencegah satu halaman diakses lewat beberapa versi alamat yang berbeda.
-
Buat Git ikut peka huruf. Pada sistem yang tidak peka huruf, Git bawaannya mengabaikan perbedaan kapitalisasi sehingga perubahan nama berkas bisa tidak ikut tercatat. Ubah dengan perintah berikut, dan sadari bahwa opsi ini dapat memunculkan konflik palsu pada filesystem yang memang tidak peka huruf:
Bashgit config core.ignorecase false -
Uji di lingkungan yang peka huruf sebelum mengunggah. Pada Windows 10 build 17107 ke atas, satu folder kosong dapat ditandai agar bersifat peka huruf. Salin proyek ke dalamnya, lalu jalankan perintah berikut dari PowerShell dengan hak administrator:
POWERSHELLfsutil.exe file setCaseSensitiveInfo D:\uji-proyek enableFolder harus kosong saat perintah dijalankan, dan folder baru di dalamnya akan mewarisi sifat tersebut.
-
Simpan identitas pengguna dalam bentuk yang sudah diseragamkan. Ubah email dan username menjadi huruf kecil sebelum disimpan, dan lakukan hal yang sama saat login. Perilakunya jadi tidak lagi bergantung pada collation database.
-
Jangan seragamkan huruf pada password, token, dan kode verifikasi. Ketiganya harus dibandingkan persis seperti aslinya.
Sisi Lain: Kenapa Tidak Semua Dibuat Tidak Peka Huruf
Setelah membaca sederet masalah di atas, wajar kalau muncul pertanyaan: kenapa tidak semua sistem dibuat tidak peka huruf saja supaya aman? Pilihan itu punya konsekuensi tersendiri.
Aturan huruf besar berbeda antar bahasa. Menyeragamkan huruf terdengar sepele, sampai Anda bertemu bahasa Turki. Bahasa itu memiliki i bertitik dan ı tanpa titik sebagai dua huruf berbeda, sehingga huruf besar dari i adalah İ, bukan I. Program yang menyeragamkan teks mengikuti pengaturan bahasa perangkat bisa mengubah "INDOWEBSITE" menjadi "ındowebsite", lalu gagal mencocokkannya dengan data tersimpan.
Ruang tebakan password menyusut drastis. Password 8 karakter yang hanya berisi huruf punya sekitar 53 triliun kombinasi bila kapitalisasi dibedakan. Kalau kapitalisasi diabaikan, jumlahnya turun menjadi sekitar 209 miliar, atau tepat 256 kali lebih sedikit. Bagi mesin penebak otomatis, selisih sebesar itu sangat berarti.
Identitas menjadi lebih mudah dikaburkan. Pada sistem yang tidak peka huruf, "admin" dan "Admin" adalah orang yang sama, dan itu memang yang diinginkan. Namun penyeragaman yang setengah jalan membuka celah baru, ketika dua akun berbeda bisa memiliki nama yang tampak identik di mata pengguna.
Karena itu jawabannya bukan memilih satu perilaku untuk semua hal, melainkan memilih perilaku yang tepat untuk setiap jenis data.
Pertanyaan yang Sering Muncul
Apakah alamat email peka huruf besar-kecil?
Secara standar, bagian sebelum tanda @ bersifat peka huruf, sedangkan bagian domain setelahnya tidak. Dalam praktiknya, hampir semua penyedia memperlakukan seluruh alamat sebagai tidak peka huruf. Meski begitu, biasakan menulisnya dengan huruf kecil karena sistem internal perusahaan tidak selalu mengikuti kebiasaan tersebut.
Apakah Gmail peka huruf besar-kecil?
Tidak. Gmail mengabaikan huruf besar-kecil sekaligus mengabaikan titik pada nama pengguna. Alamat NamaAnda@gmail.com dan nama.anda@gmail.com menuju kotak masuk yang sama. Aturan titik ini khas Gmail dan tidak berlaku di layanan lain.
Apakah password selalu peka huruf besar-kecil?
Hampir selalu, karena password disimpan sebagai hash. Perbedaan satu huruf menghasilkan hash yang sepenuhnya berbeda, sehingga kapitalisasi tidak bisa diabaikan tanpa mengorbankan keamanan.
Apakah alamat website peka huruf besar-kecil?
Bagian domainnya tidak, tetapi bagian setelah domain umumnya iya, khususnya pada server berbasis Linux. Karena itu /Blog/Artikel dan /blog/artikel bisa dianggap dua halaman yang berbeda.
Kesimpulan
Case sensitive adalah sifat sistem yang memperlakukan huruf besar dan huruf kecil sebagai karakter berbeda. Sifat itu merupakan perilaku bawaan, karena yang sesungguhnya dibandingkan komputer adalah angka, bukan huruf. Sistem yang tidak peka huruf justru hasil pekerjaan tambahan yang sengaja ditulis, sehingga perilakunya berbeda-beda antara filesystem, bahasa pemrograman, database, dan protokol.
Aturan praktisnya sederhana. Anggap segala sesuatu yang Anda ketik sendiri sebagai peka huruf, kecuali ada alasan kuat untuk yakin sebaliknya. Biasakan menulis nama berkas, folder, tabel, dan slug URL dengan huruf kecil, lalu seragamkan email dan username sebelum disimpan. Kebiasaan kecil itu menghapus sebagian besar kejutan yang biasanya baru muncul pada hari website dipindahkan ke server sungguhan.
Semoga artikel ini membantu.




