Apa beda Unicode dan UTF-8?

Code point dulu, byte kemudian

Unicode mendefinisikan ruang kode dari U+0000 sampai U+10FFFF, cukup untuk 1.114.112 code point yang dibagi menjadi 17 plane masing-masing berisi 65.536. Lebih dari 150.000 di antaranya sudah ditetapkan untuk karakter, mencakup aksara modern dan kuno, simbol, serta emoji. Code point ditulis sebagai U+ diikuti minimal empat digit heksadesimal.

Code point hanyalah sebuah angka. Untuk menyimpan atau mengirim teks, angka itu harus diubah menjadi byte, dan ada beberapa cara melakukannya: UTF-8, UTF-16, dan UTF-32 semuanya adalah encoding untuk karakter Unicode yang sama.

Bagaimana UTF-8 memilih 1, 2, 3, atau 4 byte

UTF-8, yang dispesifikasikan dalam RFC 3629, adalah encoding dengan lebar variabel. Bit-bit awal pada byte pertama menunjukkan berapa byte yang menyusul, dan setiap byte lanjutan diawali bit 10. Hal ini membuat aliran data dapat menyinkronkan diri: decoder yang mendarat di tengah karakter bisa melompat ke byte awal berikutnya.

Contoh perhitungan: "é" adalah U+00E9, dalam biner 000 1110 1001. Karakter ini butuh pola 2 byte. Lima bit teratas 00011 dimasukkan ke 110xxxxx sehingga menjadi 11000011 (C3), dan enam bit terbawah 101001 dimasukkan ke 10xxxxxx sehingga menjadi 10101001 (A9).

Karena 128 code point pertama di-encode menjadi byte tunggal yang sama dengan ASCII, setiap file ASCII yang valid otomatis juga UTF-8 yang valid. Kompatibilitas mundur inilah alasan utama UTF-8 menjadi default di web, yang dipakai oleh sekitar 98% situs web.

UTF-8 vs UTF-16 vs UTF-32

UTF-16 menyimpan karakter di atas U+FFFF sebagai pasangan surrogate yang terdiri dari dua unit 16-bit. Itulah sebabnya "😀".length bernilai 2 di JavaScript: bahasa ini menghitung unit UTF-16, bukan karakter. Iterasi dengan [..."😀"].length menghasilkan 1.

Untuk teks bahasa Inggris, UTF-8 paling ringkas. Untuk teks yang sebagian besar berbahasa Tionghoa, Jepang, atau Korea, UTF-16 bisa lebih kecil, karena karakter tersebut memakan 3 byte di UTF-8 tetapi 2 byte di UTF-16.

Byte order mark (BOM)

BOM adalah karakter U+FEFF yang diletakkan di awal file. Pada UTF-16 dan UTF-32, BOM memberi tahu pembaca apakah byte-nya big-endian atau little-endian. Pada UTF-8, BOM di-encode sebagai EF BB BF dan hanya berfungsi sebagai penanda, karena UTF-8 tidak punya urutan byte.

FAQ Unicode menyatakan BOM UTF-8 tidak diwajibkan dan tidak disarankan. Sebagian editor Windows tetap menambahkannya, lalu BOM itu merusak skrip shell (baris #! tidak lagi berada paling awal), header CSV, dan parser JSON yang tidak mengharapkannya. Jika sebuah file menampilkan  di bagian atas, itu adalah BOM UTF-8 yang dibaca sebagai Windows-1252.

Mengapa teks berubah menjadi é atau ���

Teks kacau, yang disebut mojibake, muncul saat byte di-decode dengan encoding yang berbeda dari encoding saat ditulis:

• é alih-alih é: byte UTF-8 C3 A9 dibaca sebagai Windows-1252 atau Latin-1, yang memetakan C3 ke Ã dan A9 ke ©.
• � (U+FFFD, karakter pengganti): decoder menemukan byte yang bukan UTF-8 valid, sering kali teks Latin-1 yang dibaca sebagai UTF-8.
• Tanda tanya di database: kolom atau koneksinya memakai charset yang tidak bisa menampung karakter tersebut, sehingga karakter itu diganti saat ditulis dan hilang selamanya.

Solusinya adalah menyatakan encoding di setiap batas: <meta charset="utf-8"> di HTML, Content-Type: text/html; charset=utf-8 di header HTTP, serta UTF-8 untuk kolom dan koneksi database. Di MySQL, gunakan utf8mb4; charset utf8 yang lebih lama hanya menyimpan maksimal 3 byte per karakter dan menolak emoji.