FlowingDev

Hantu Tak Kasat Mata di Unicode: Karakter Rahasia yang Membuat Kekacauan di Teks Anda

Temukan bagaimana karakter Unicode tak terlihat dan huruf yang mirip bisa merusak kodemu, menyebabkan risiko keamanan, dan menciptakan bug yang sangat halus dan bikin pusing.

Coba tool-nya: Inspektur Teks Unicode

Dalam satu kalimat

Unicode adalah standar universal untuk teks yang memungkinkan internet global kita, tetapi karena saking luasnya, ia juga mencakup karakter tak terlihat, huruf yang mirip, dan keanehan lainnya yang bisa mengubah string yang tampaknya sederhana menjadi ladang ranjau bug.

Masalah yang dipecahkannya

Di masa purba komputasi, hidup itu sederhana. Kita punya ASCII. Itu memberi kita 127 karakter: huruf kapital, huruf kecil, angka, tanda baca, dan beberapa kode kontrol. Rapi, ringkas, dan pas banget dalam satu byte. Tapi itu juga sangat berpusat pada bahasa Inggris. Kalau kamu mau menulis ¿Qué pasa? atau 你好 atau спасибо, ya wassalam.

Ini mengarah ke era kacau yang dikenal sebagai "neraka codepage". Komputer di berbagai wilayah menggunakan set karakter 8-bit berbeda yang merupakan perluasan dari ASCII. Dokumen yang ditulis dalam Windows-1252 (Eropa Barat) akan berubah menjadi teks acak-acakan (yang kita sebut dengan penuh cinta sebagai mojibake) saat dibuka di sistem yang menggunakan KOI8-R (Rusia). Berbagi teks secara internasional rasanya seperti bermain telepon rusak dengan kabel yang error.

Lalu, Konsorsium Unicode datang bak pahlawan. Misi mereka: satu set karakter tunggal yang terpadu untuk semua sistem penulisan modern dan historis. Satu standar untuk menguasai semuanya. Setiap karakter—dari 'A' hingga '€' hingga emoji 'Tumpukan Kotoran' (💩)—akan mendapatkan nomor uniknya sendiri, sebuah "code point."

Itu adalah pencapaian monumental yang menggerakkan dunia modern kita. Tapi penyatuan besar ini menciptakan serangkaian masalahnya sendiri yang luar biasa nerdy. Untuk mengakomodasi kompleksitas bahasa manusia, Unicode harus menyertakan lebih dari sekadar huruf yang terlihat. Ia butuh:

  • Combining characters: Tanda aksen (´) yang merupakan karakter terpisah, dirancang untuk ditempatkan di atas karakter lain (e).
  • Zero-width characters: Penanda tak terlihat yang bisa menyarankan jeda baris (U+200B Zero-Width Space) atau merekatkan emoji (U+200D Zero-Width Joiner).
  • Karakter ambigu: Puluhan jenis spasi, tanda hubung, dan tanda kutip yang berbeda.
  • Karakter mirip (homoglyph): Huruf Latin a dan huruf Kiril а terlihat identik di banyak font, tetapi bagi komputer, keduanya sama berbedanya dengan a dan b.

Tiba-tiba, apa yang kamu lihat bukanlah apa yang kamu dapatkan. Sebuah string yang terlihat seperti "cat" bisa saja mengandung karakter tak terlihat, membuat panjangnya 4, bukan 3. Nama variabel safeString mungkin menyembunyikan huruf Yunani 'α' alih-alih huruf Latin 'a'. Inilah masalah yang dipecahkan oleh pemeriksa teks: ia memakai kacamata X-ray untuk menunjukkan kebenaran mentah tanpa filter tentang apa sebenarnya isi string-mu, mengungkap hantu-hantu tersembunyi di dalam mesin.

Cara kerjanya di balik layar

Untuk membedah sebuah string, kita perlu memahami tiga lapisan dasarnya: karakter abstrak, representasi byte-nya, dan hal-hal aneh yang bersembunyi di antaranya.

Code Point: Alamat Sebuah Karakter

Pada intinya, Unicode hanyalah sebuah daftar raksasa. Setiap karakter diberi nomor unik yang disebut code point. Ini adalah alamat permanen karakter tersebut di alam semesta Unicode. Kita menuliskannya menggunakan notasi U+XXXX, di mana XXXX adalah angka heksadesimal.

  • U+0041 adalah A (Latin Capital Letter A)
  • U+00E9 adalah é (Latin Small Letter E with Acute)
  • U+20AC adalah € (Euro Sign)
  • U+1F4A9 adalah 💩 (Pile of Poo)

Sebuah code point adalah ide abstrak. Ia bukan byte atau font. Ia hanyalah sebuah nomor yang dipetakan ke sebuah karakter. Cara kita menyimpan nomor itu adalah cerita lain.

Encoding: Menyimpan Code Point dalam Byte

Kamu tidak bisa menyimpan "code point" ke dalam file. Kamu harus menyimpan byte. Sebuah encoding adalah seperangkat aturan untuk mengubah urutan code point menjadi urutan byte.

Raja dari semua encoding saat ini adalah UTF-8. Kejeniusannya terletak pada desainnya yang memiliki panjang variabel.

  • Untuk karakter apa pun yang juga ada di set ASCII asli (seperti A, U+0041), UTF-8 menggunakan satu byte—byte yang persis sama dengan yang digunakan ASCII. Ini membuatnya kompatibel mundur dan mudah diadopsi.
  • Untuk karakter lain, ia menggunakan urutan 2, 3, atau 4 byte. Beberapa bit pertama dari setiap byte bertindak sebagai sinyal, memberitahu komputer berapa banyak byte yang merupakan bagian dari karakter saat ini.

Mari kita lihat ¡Hola!:

Karakter Code Point Byte UTF-8 (Hex)
¡ U+00A1 C2 A1
H U+0048 48
o U+006F 6F
l U+006C 6C
a U+0061 61
! U+0021 21

Pemeriksa teks melakukan proses sebaliknya. Ia membaca byte mentah dari string-mu, menafsirkannya menurut sebuah encoding (biasanya UTF-8), dan menunjukkan urutan code point yang menyusunnya.

Para Pembuat Onar Tak Terlihat

Di sinilah bagian menyenangkannya. Tugas utama pemeriksa teks adalah menyoroti karakter-karakter yang tidak terlihat seperti apa pun.

Kategori Contoh Karakter & Code Point Tujuan Liciknya
Zero-Width Space U+200B Terlihat seperti tidak ada apa-apa. Karakter tak terlihat yang menyarankan tempat yang baik untuk jeda baris pada kata atau URL yang panjang.
Zero-Width Joiner U+200D Lem ajaib untuk emoji. 👨 + ZWJ + 👩 + ZWJ + 👧 = 👨‍👩‍👧. Ini menggabungkan karakter yang biasanya tidak akan terhubung.
Non-Breaking Space U+00A0 Terlihat seperti spasi biasa, tetapi melarang adanya jeda baris. Berguna untuk hal-hal seperti 100 km atau Dr. Strange.
Combining Mark U+0301 (Combining Acute Accent) Sebuah aksen (´) yang merupakan karakter tersendiri. Ia digambar di atas karakter sebelumnya.
Karakter Mirip (Homoglyph) U+0430 (Cyrillic Small Letter A) Terlihat identik dengan huruf Latin a (U+0061) di sebagian besar font, tetapi merupakan code point yang sama sekali berbeda.

Ini mengarah pada konsep normalisasi. Karakter é dapat direpresentasikan dalam dua cara:

  1. Composed (NFC): Satu code point, U+00E9.
  2. Decomposed (NFD): Dua code point, e (U+0065) diikuti oleh aksen penggabung ´ (U+0301).

Secara visual, keduanya identik. Tetapi bagi komputer yang melakukan perbandingan byte-per-byte sederhana, "\u00E9" tidak sama dengan "e\u0301". Pemeriksa teks dapat mengungkapkan bentuk mana yang kamu miliki dan membantumu mengonversi di antara keduanya.

Kisah di dunia nyata

Bencana Copy-Paste

Seorang developer junior sedang lembur, mencoba memperbaiki bug. Dia menemukan solusi di sebuah blog, satu baris JavaScript: const timeout = 100;. Dia menyalinnya, menempelkannya ke editor kodenya, dan menekan simpan. Seluruh proses build aplikasi gagal dengan pesan SyntaxError: Invalid or unexpected token yang misterius.

Dia menatap baris itu. Sempurna. Dia mengetiknya ulang secara manual. Berhasil. Dia menempelkan baris yang disalin lagi. Gagal lagi. Apa dia mulai gila? Setelah satu jam pusing tujuh keliling, seorang developer senior menyipitkan mata ke baris itu dan berkata, "Coba tempel itu ke pemeriksa teks."

Hasilnya: const[U+00A0]timeout[U+00A0]=[U+00A0]100;. CSS blog tersebut telah mempercantik kode, mengganti spasi standar (U+0020) dengan spasi non-breaking (U+00A0). Keduanya terlihat identik, tetapi mesin JavaScript tidak tahu apa itu "spasi non-breaking" dalam konteks itu.

Pelajaran: Teks yang disalin dari web (atau PDF, atau dokumen Word) harus dianggap bersalah sampai terbukti tidak. Seringkali terkontaminasi dengan kutipan "pintar", spasi non-standar, dan dedemit tak terlihat lainnya.

User Misterius yang Gagal Login

Seorang pengguna baru mendaftar ke sebuah layanan dengan nama François. Sistem dengan senang hati membuat akun tersebut. Keesokan harinya, François mencoba login. Dia mengetik namanya, menekan enter... "Username atau password salah." Dia mencoba lagi, dengan hati-hati. Hasil yang sama. Dia terkunci.

Di database, namanya disimpan menggunakan karakter terurai (decomposed): F, r, a, n, c, o, i, s dan sebuah U+0327 (Combining Cedilla). Namun, formulir login mengirimkan karakter yang sudah digabung (precomposed) ç (U+00E7). Secara visual, c + ¸ sama dengan ç. Tetapi server melakukan perbandingan string sederhana: François (decomposed) tidak sama dengan François (composed). Query WHERE username = '...' pun gagal.

Pelajaran: Selalu normalisasi input pengguna ke bentuk yang konsisten (NFC adalah pilihan paling umum) sebelum menyimpannya ke database atau melakukan perbandingan.

Domain yang Menipu

Seorang karyawan menerima email yang sepertinya dari departemen IT perusahaannya. "Pembaruan Keamanan Diperlukan: Silakan login ke microsоft.com/update untuk mengamankan akun Anda." Tautannya terlihat sah. Nama domainnya jelas. Dia mengkliknya, memasukkan kredensialnya di halaman yang terlihat persis seperti aslinya, dan melanjutkan aktivitasnya seperti biasa.

Dia baru saja kena phishing. Domainnya bukan microsoft.com. Domainnya adalah microsоft.com. Huruf 'o' kedua bukanlah 'o' Latin (U+006F) melainkan 'о' Kiril (U+043E). Ini adalah Serangan Homograf IDN. Bagi mata manusia, ini adalah tiruan yang sempurna. Bagi sistem DNS, ini adalah alamat yang sama sekali berbeda, yang mengarah ke server penipu.

Pelajaran: Curigailah secara mendalam pada pengidentifikasi yang mencampur set karakter. Meskipun browser modern memiliki beberapa perlindungan, prinsip serangan homograf adalah ancaman konstan dalam username, aturan validasi, dan di mana pun string digunakan untuk keamanan.

Kesalahan umum dan jebakan

  • Mengasumsikan string.length menghitung karakter. Di banyak bahasa (seperti JavaScript), ia menghitung unit kode, bukan karakter yang terlihat. Misalnya, "👍🏽".length adalah 4 di JS, karena terdiri dari emoji "jempol ke atas" (👍, 2 unit) dan "pengubah warna kulit sedang" (🏽, 2 unit).
  • Menganggap semua spasi putih itu sama. Menjalankan trim() pada sebuah string tidak akan menghapus U+200B Zero-Width Space yang tersembunyi di tengah. Regex untuk \s+ mungkin tidak akan menangkap U+00A0 Non-Breaking Space. Kamu harus tahu apa yang sedang kamu buru.
  • Mengabaikan normalisasi. Seperti yang terlihat pada kasus François, membandingkan string yang terlihat sama tetapi memiliki representasi byte yang berbeda di baliknya adalah bug klasik yang membuat frustrasi. string1.normalize() === string2.normalize() adalah teman baikmu.
  • Mempercayai matamu. Kamu tidak bisa men-debug masalah ini dengan melihat teks yang dirender. Pemeriksa teks yang menunjukkan setiap code point dan namanya adalah satu-satunya cara untuk memastikan apa yang sebenarnya ada di sana.
  • Membuat sendiri penghapus "karakter aneh". Mencoba menulis regex untuk menghapus semua karakter "aneh" adalah pekerjaan sia-sia. Kamu akan melewatkan beberapa, atau lebih buruk lagi, menghapus karakter sah yang diperlukan untuk bahasa lain, merusak nama dan teks pengguna.

Kenapa ini harus kamu waspadai

Kamu harus menggunakan pemeriksa teks Unicode setiap kali teks berperilaku tidak terduga. Ini adalah alat debugging yang sangat diperlukan. Pikirkan untuk menggunakannya ketika:

  • Perbandingan string gagal padahal "jelas" seharusnya berhasil.
  • Kamu mendapatkan error sintaks pada baris kode yang terlihat sangat valid.
  • Kamu sedang memvalidasi input yang diberikan pengguna seperti username, email, atau URL.
  • Kamu sedang bekerja dengan data dari berbagai sistem, terutama jika melibatkan bahasa yang berbeda.
  • Kamu perlu memahami mengapa string.length memberimu angka yang "salah".
  • Kamu sedang membangun sistem apa pun yang harus kuat, aman, dan berfungsi untuk audiens global.

Singkatnya, setiap kali komputer dan manusia tidak setuju tentang apa arti sepotong teks, kemungkinan besar komputer benar tentang byte-nya, dan pemeriksa teks adalah penerjemahmu.

Pelajari lebih dalam

Teori beres. Saatnya praktik — 100% di browser kamu.

Coba tool-nya: Inspektur Teks Unicode