Dekoder Unicode

Tool ini mendukung \uXXXX (BMP), \UXXXXXXXX (Unicode penuh), &#DDDD; (entitas HTML desimal), &#xHHHH; (entitas HTML heksadesimal), dan U+XXXX (notasi code point) untuk dekoding.

UTF-8 mengenkode setiap code point Unicode dengan 1 sampai 4 byte. Karakter ASCII (U+0000 sampai U+007F) memakai 1 byte, karakter Latin dan umum lainnya 2 byte, sebagian besar karakter CJK 3 byte, dan emoji serta karakter langka 4 byte.

\uXXXX memakai 4 digit heksadesimal dan dapat merepresentasikan karakter di Basic Multilingual Plane (U+0000 sampai U+FFFF). \UXXXXXXXX memakai 8 digit heksadesimal dan dapat merepresentasikan karakter Unicode mana pun termasuk yang melampaui BMP.

Itu tanda mojibake: byte UTF-8 didekode sebagai Windows-1252/Latin-1. "é" berarti dua byte UTF-8 dari "é" (0xC3 0xA9) ditampilkan sebagai dua karakter terpisah. Gunakan mode Perbaiki Teks Kacau untuk memperbaikinya. "�" adalah U+FFFD, karakter pengganti yang dihasilkan saat byte sudah tidak valid - informasi itu hilang dan tidak bisa dipulihkan.

UTF-8 mengenkode karakter dalam 1–4 byte dan sepenuhnya kompatibel ASCII, menjadikannya default untuk web, JSON, dan sebagian besar API. UTF-16 mengenkode karakter dalam 2 atau 4 byte (memakai pasangan surrogate untuk karakter melampaui U+FFFF) dan dipakai secara internal oleh JavaScript, Java, dan Windows. Untuk sebagian besar teks di web, UTF-8 lebih kecil dan lebih aman.

Code point adalah angka yang diberikan kepada sebuah karakter dalam standar Unicode (U+00E9 untuk e-aksen-tajam); code unit adalah unit penyimpanan yang dipakai sebuah encoding. Code unit UTF-8 adalah byte 8-bit - U+00E9 membutuhkan dua - sedangkan code unit UTF-16 16-bit, dan karakter melampaui U+FFFF butuh dua di antaranya (pasangan surrogate). String JavaScript adalah UTF-16, jadi 'hello'.length adalah 5 tetapi .length sebuah emoji adalah 2.

Karakter yang tampak sama bisa punya beberapa rangkaian byte: e-aksen-tajam sebagai satu karakter praterekam (NFC) atau e plus aksen penggabung (NFD). NFC menyusun, NFD menguraikan, dan NFKC/NFKD tambahan melipat karakter kompatibilitas (bentuk lebar-penuh, ligatur). Membandingkan atau meng-hash input pengguna tanpa menormalkan lebih dulu adalah sumber klasik akun duplikat dan pencarian gagal - ligatur fi vs f+i.

Byte order mark adalah U+FEFF yang dienkode di awal stream (EF BB BF dalam UTF-8) untuk menandakan encoding. Editor biasanya menyembunyikannya, tetapi di hilir ia menjadi karakter pertama yang tak terlihat: header CSV mendapat kunci hantu, parsing JSON gagal pada token liar, dan sesi PHP memancarkannya sebelum header. UTF-8 tidak butuh BOM karena tidak memiliki ambiguitas urutan byte - simpan tanpa BOM.