Unicode, Unicode Big Endian atau UTF-8? Apa bedanya? Format mana yang lebih baik?


19

Ketika saya mencoba menyimpan file teks dengan teks non-Inggris di Notepad, saya mendapatkan opsi untuk memilih antara Unicode , Unicode Big Endian, dan UTF-8 . Apa perbedaan antara format ini?

Dengan asumsi saya tidak menginginkan kompatibilitas ke belakang (dengan versi OS atau aplikasi yang lebih lama) dan saya tidak peduli dengan ukuran file, format mana yang lebih baik?

(Asumsikan bahwa teks dapat dalam bahasa seperti Cina atau Jepang, selain bahasa lain.)

Catatan: Dari jawaban dan komentar di bawah ini, tampaknya di Notepad lingo, Unicode adalah UTF-16 (Little Endian), Unicode Big Endian adalah UTF-16 (Big Endian) dan UTF-8 adalah UTF-8 yang baik.


Jawaban:


19

Tidak tahu Mana yang lebih baik: gergaji atau palu? :-)

Unicode bukan UTF

Ada sedikit dalam artikel yang sedikit lebih relevan dengan subjek yang ada:

  • UTF-8 berfokus pada meminimalkan ukuran byte untuk representasi karakter dari set ASCII (representasi panjang variabel: setiap karakter direpresentasikan pada 1 hingga 4 byte, dan karakter ASCII semuanya sesuai dengan 1 byte). Seperti yang dikatakan Joel:

“Lihat semua angka nol itu!” Kata mereka, karena mereka orang Amerika dan mereka melihat teks bahasa Inggris yang jarang menggunakan titik kode di atas U + 00FF. Juga mereka hippies liberal di California yang ingin menghemat (mencibir). Jika mereka orang Texas, mereka tidak akan keberatan menelan dua kali lipat jumlah byte. Tetapi para pengecut California itu tidak tahan membayangkan menggandakan jumlah penyimpanan yang diperlukan untuk string

  • UTF-32 berfokus pada ketelitian dan representasi panjang tetap, menggunakan 4 byte untuk semua karakter. Ini adalah terjemahan yang paling mudah, memetakan langsung titik kode Unicode ke 4 byte. Jelas, ukurannya tidak terlalu efisien.

  • UTF-16 adalah kompromi, menggunakan 2 byte sebagian besar waktu, tetapi memperluas ke 2 * 2 byte per karakter untuk mewakili karakter tertentu, yang tidak termasuk dalam Basic Multilingual Plane (BMP).

Juga lihat Minimum Mutlak Setiap Pengembang Perangkat Lunak Sepenuhnya, Pasti Harus Tahu Tentang Unicode dan Karakter (Tidak Ada Alasan!)


4
Masalahnya berasal dari fakta bahwa Unicode adalah 'pengkodean', tetapi tidak dalam arti angka-ke-byte. UTF-8/16/32 semuanya adalah penyandian Unicode, tetapi Unicode sendiri adalah pemetaan dari simbol ke angka. Mereka bisa menggunakan terminologi yang lebih unik untuk menghindari kebingungan ini saya pikir.
jerryjvl

4
Namun demikian, untuk OP pertanyaan, kemungkinan besar aplikasi tersebut berarti 'UTF-16' di mana dikatakan 'Unicode'.
jerryjvl

3
Saya tidak yakin bahwa tujuan UTF-8 adalah "konservasi" sebagai lawan dari kompatibilitas ke belakang dengan ASCII.
Tn. Shiny dan Baru 安 宇

@Johannes: Konsorsium Unicode telah memutuskan untuk tidak pernah memberikan poin kode di atas U + 10FFFF karena mereka tidak dapat diwakili dalam UTF-16. Ini memiliki efek membatasi UTF-8 hingga 4 byte.
user46971

1
"Unicode bukan UTF" - bagi banyak orang, itu adalah WTF;)
mlvljr

4

Untuk bahasa Eropa, UTF-8 lebih kecil. Untuk bahasa-bahasa Oriental, perbedaannya tidak begitu jelas.

Keduanya akan menangani semua karakter Unicode yang mungkin, jadi itu seharusnya tidak membuat perbedaan dalam kompatibilitas.


3

Ada lebih banyak pengkodean karakter Unicode daripada yang Anda bayangkan.

  • UTF 8

    Pengkodean UTF-8 adalah lebar variabel, mulai dari 1-4 byte, dengan bit atas setiap byte dicadangkan sebagai bit kontrol. Bit terkemuka dari byte pertama menunjukkan jumlah total byte yang digunakan untuk karakter itu. Nilai skalar dari titik kode karakter adalah gabungan dari bit-bit yang tidak terkontrol. Dalam tabel ini, xmewakili 8 bit terendah dari nilai Unicode, ymewakili 8 bit lebih tinggi berikutnya, dan zmewakili bit lebih tinggi dari itu.

    Unicode              Byte1     Byte2     Byte3     Byte4
    U+0000-U+007F       0xxxxxxx            
    U+0080-U+07FF       110yyyxx  10xxxxxx          
    U+0800-U+FFFF       1110yyyy  10yyyyxx  10xxxxxx    
    U+10000-U+10FFFF    11110zzz  10zzyyyy  10yyyyxx  10xxxxxx
    
  • UCS-16
  • UCS-16BE
  • UCS-16LE

  • UTF-16
  • UTF-16BE
  • UTF-16LE

  • UTF-32
  • UTF-32-BE

1
Ada lebih banyak penyandian karakter Unicode daripada yang Anda daftarkan. Misalnya UTF-1 , UTF-7 , UTF-EBCDIC , GB-18030 , MIME , UTF-9 dan UTF-18 ... Anda juga dapat menggunakan skema penyandian biner apa pun untuk menyandikan data Unicode. Baca selengkapnya Perbandingan penyandian Unicode
phuclv

1

"Unicode" adalah istilah lain untuk "UTF-16", yang merupakan pengkodean dari karakter Unicode yang diatur ke dalam enam belas-bit per karakter. UTF-8 mengkodekannya menjadi delapan bit per karakter.

Dalam kedua kasus, setiap luapan dialokasikan ke 16 atau delapan bit lainnya.


Yang mana yang lebih baik?
R. Martinho Fernandes

"Itu tergantung" pada situasi.
John Saunders

Meskipun untuk pertanyaan khusus ini tampaknya "Unicode" memang DILARANG sebagai istilah lain untuk "UTF-16", itu tidak secara umum - lihat jawaban Jason.
Arjan

1
Maksud Anda "per unit kode", bukan "per karakter"; baik UTF-8 dan UTF-16 dapat menggunakan beberapa unit kode untuk mewakili karakter. Dan "Unicode" dan "UTF-16" BUKAN hal yang sama, kecuali dalam terminologi Microsoft.
user46971

1

Satu-satunya keuntungan nyata dengan file kecil seperti file teks adalah ukuran file yang dihasilkan. UTF-8 umumnya menghasilkan file yang lebih kecil. Tetapi perbedaan ini mungkin kurang diucapkan dengan teks Cina / Jepang.


Ingatlah bahwa ada juga perbedaan dalam bandwidth jaringan dan penggunaan memori.
Jason Baker

1
"UTF-8 umumnya menghasilkan file yang lebih kecil": Tidak umumnya. UTF-8 menghasilkan file yang lebih kecil untuk file ASCII. Jika file hanya terdiri dari titik kode Unicode di atas U + 0800, itu akan lebih besar di UTF-8 daripada di UTF-16.
sleske

0

Singkatnya, Unicode adalah rangkaian karakter , sementara Unicode Big Endian dan utf-8 adalah dua penyandian , yang digunakan untuk menyimpan karakter sebagai 01 di komputer.


Dan perbedaannya adalah ...?
David Richerby
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.