Haruskah UTF-16 dianggap berbahaya?

Saya akan bertanya apa yang mungkin merupakan pertanyaan yang cukup kontroversial: "Haruskah salah satu pengkodean paling populer, UTF-16, dianggap berbahaya?"

Mengapa saya menanyakan pertanyaan ini?

Berapa banyak programmer yang menyadari fakta bahwa UTF-16 sebenarnya adalah penyandian panjang variabel? Maksud saya, ada poin kode yang, diwakili sebagai pasangan pengganti, mengambil lebih dari satu elemen.

Aku tahu; banyak aplikasi, kerangka kerja dan API menggunakan UTF-16, seperti Java's String, C #'s String, Win32 APIs, pustaka Qt GUI, pustaka ICU Unicode, dll. Namun, dengan semua itu, ada banyak bug dasar dalam pemrosesan karakter keluar dari BMP (karakter yang harus dikodekan menggunakan dua elemen UTF-16).

Misalnya, coba edit salah satu karakter ini:

• 𝄞 ( U + 1D11E ) SIMBOL MUSIK G CLEF
• 𝕥 ( U + 1D565 ) MATEMATIK GANDA-STRUCK KECIL T
• 𝟶 ( U + 1D7F6 ) NOL DIGITAL MATEMATIKA NOL
• 𠂊 ( U + 2008A ) Karakter Han

Anda mungkin kehilangan beberapa, tergantung pada font apa yang telah Anda instal. Semua karakter ini berada di luar BMP (Basic Multilingual Plane). Jika Anda tidak dapat melihat karakter ini, Anda juga dapat mencoba melihatnya di referensi Karakter Unicode .

Misalnya, coba buat nama file di Windows yang menyertakan karakter ini; coba hapus karakter-karakter ini dengan "backspace" untuk melihat bagaimana mereka berperilaku dalam aplikasi yang berbeda yang menggunakan UTF-16. Saya melakukan beberapa tes dan hasilnya sangat buruk:

• Opera bermasalah dengan pengeditannya (perlu hapus 2 penekanan pada backspace)
• Notepad tidak dapat mengatasinya dengan benar (perlu hapus 2 penekanan pada backspace)
• Pengeditan nama file dalam dialog Window in broken (perlu hapus 2 penekanan pada backspace)
• Semua aplikasi QT3 tidak dapat mengatasinya - tampilkan dua kotak kosong bukan satu simbol.
• Python menyandikan karakter seperti itu secara salah ketika digunakan secara langsung u'X'!=unicode('X','utf-16')pada beberapa platform ketika X dalam karakter di luar BMP.
• Python 2.5 unicodedata gagal mendapatkan properti pada karakter seperti itu ketika python dikompilasi dengan string Unicode UTF-16.
• StackOverflow tampaknya menghapus karakter ini dari teks jika diedit langsung sebagai karakter Unicode (karakter ini ditampilkan menggunakan HTML Unicode escapes).
• WinForms TextBox dapat menghasilkan string yang tidak valid ketika dibatasi dengan MaxLength.

Tampaknya bug seperti itu sangat mudah ditemukan di banyak aplikasi yang menggunakan UTF-16.

Jadi ... Apakah Anda berpikir bahwa UTF-16 harus dianggap berbahaya?

Ini jawaban lama.
Lihat UTF-8 Everywhere untuk pembaruan terbaru.

Opini: Ya, UTF-16 harus dianggap berbahaya . Alasan mengapa hal itu ada adalah karena beberapa waktu lalu dulu ada kepercayaan sesat bahwa widechar akan menjadi seperti apa UCS-4 sekarang.

Meskipun "anglo-sentralisme" dari UTF-8, itu harus dianggap sebagai satu-satunya penyandian teks yang bermanfaat. Orang dapat berargumen bahwa kode sumber program, halaman web dan file XML, nama file OS dan antarmuka teks komputer-ke-komputer lainnya seharusnya tidak pernah ada. Tetapi ketika mereka melakukannya, teks tidak hanya untuk pembaca manusia.

Di sisi lain, overhead UTF-8 adalah harga yang murah untuk dibayar sementara itu memiliki keuntungan yang signifikan. Keuntungan seperti kompatibilitas dengan kode tidak disadari yang baru saja melewati string char*. Ini adalah sesuatu yang bagus. Ada beberapa karakter berguna yang SHORTER di UTF-16 daripada di UTF-8.

Saya percaya bahwa semua pengkodean lainnya akan mati pada akhirnya. Ini melibatkan bahwa MS-Windows, Java, ICU, python berhenti menggunakannya sebagai favorit mereka. Setelah penelitian dan diskusi yang panjang, konvensi pengembangan di perusahaan saya melarang menggunakan UTF-16 di mana pun kecuali panggilan OS API, dan ini terlepas dari pentingnya kinerja dalam aplikasi kami dan fakta bahwa kami menggunakan Windows. Fungsi konversi dikembangkan untuk mengonversi UTF8 yang selalu diasumsikan std::stringmenjadi UTF-16 asli, yang Windows sendiri tidak mendukung dengan benar .

Untuk orang-orang yang mengatakan " gunakan apa yang dibutuhkan di tempat yang dibutuhkan ", saya katakan: ada keuntungan besar untuk menggunakan pengkodean yang sama di mana-mana, dan saya tidak melihat alasan yang cukup untuk melakukan sebaliknya. Secara khusus, saya pikir menambahkan wchar_tke C ++ adalah kesalahan, dan begitu pula penambahan Unicode ke C ++ 0x. Apa yang harus diminta dari implementasi STL adalah bahwa setiap std::stringatau char*parameter akan dianggap kompatibel dengan unicode.

Saya juga menentang pendekatan " gunakan apa yang Anda inginkan ". Saya tidak melihat alasan untuk kebebasan seperti itu. Ada cukup banyak kebingungan pada masalah teks, sehingga semua perangkat lunak yang rusak ini. Setelah mengatakan di atas, saya yakin bahwa programmer akhirnya harus mencapai konsensus tentang UTF-8 sebagai satu cara yang tepat. (Saya berasal dari negara yang tidak menggunakan bahasa Ascii dan dibesarkan di Windows, jadi saya yang terakhir diharapkan menyerang UTF-16 berdasarkan alasan agama).

Saya ingin berbagi informasi lebih lanjut tentang cara saya melakukan teks pada Windows, dan apa yang saya rekomendasikan kepada semua orang untuk diperiksa waktu kompilasi unicode, kemudahan penggunaan dan multi-platformness kode yang lebih baik. Saran ini sangat berbeda dari apa yang biasanya direkomendasikan sebagai cara yang tepat untuk menggunakan Unicode di windows. Namun, penelitian mendalam dari rekomendasi ini menghasilkan kesimpulan yang sama. Jadi begini:

• Jangan gunakan wchar_tatau std::wstringdi tempat lain selain titik yang berdekatan dengan API yang menerima UTF-16.
• Jangan gunakan _T("")atau L""UTF-16 literal (Ini harus IMO dikeluarkan dari standar, sebagai bagian dari penghentian UTF-16).
• Jangan gunakan jenis, fungsi atau turunannya yang sensitif terhadap _UNICODEkonstanta, seperti LPTSTRatau CreateWindow().
• Namun, _UNICODEselalu didefinisikan, untuk menghindari memberikan char*string ke WinAPI dikompilasi secara diam-diam
• std::stringsdan char*di mana saja dalam program dianggap UTF-8 (jika tidak dikatakan sebaliknya)
• Semua string saya std::string, meskipun Anda dapat meneruskan char * atau string literal ke convert(const std::string &).

• hanya menggunakan fungsi Win32 yang menerima widechars ( LPWSTR). Tidak pernah mereka yang menerima LPTSTRatau LPSTR. Lewati parameter dengan cara ini:

  ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())
  

  (Kebijakan tersebut menggunakan fungsi konversi di bawah.)

• Dengan string MFC:

  CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:
  
  std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
  AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);
  

• Bekerja dengan file, nama file, dan aliran pada Windows:

  • Jangan pernah memberikan std::stringatau const char*mengajukan argumen nama kepada fstreamkeluarga. MSVC STL tidak mendukung argumen UTF-8, tetapi memiliki ekstensi non-standar yang harus digunakan sebagai berikut:

  • Konversi std::stringargumen menjadi std::wstringdengan Utils::Convert:

    std::ifstream ifs(Utils::Convert("hello"),
                      std::ios_base::in |
                      std::ios_base::binary);
    

    Kita harus menghapus konversi secara manual, ketika sikap MSVC fstreamberubah.

  • Kode ini bukan multi-platform dan mungkin harus diubah secara manual di masa mendatang
  • Lihat fstreamkasus / penelitian 4215 unicode untuk informasi lebih lanjut.
  • Jangan pernah menghasilkan file output teks dengan konten non-UTF8
  • Hindari penggunaan fopen()karena alasan RAII / OOD. Jika perlu, gunakan _wfopen()dan WinAPI konvensi di atas.

// For interface to win32 API functions
std::string convert(const std::wstring& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

std::wstring convert(const std::string& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

// Interface to MFC
std::string convert(const CString &mfcString)
{
#ifdef UNICODE
    return Utils::convert(std::wstring(mfcString.GetString()));
#else
    return mfcString.GetString();   // This branch is deprecated.
#endif
}

CString convert(const std::string &s)
{
#ifdef UNICODE
    return CString(Utils::convert(s).c_str());
#else
    Exceptions::Assert(false, "Unicode policy violation. See W569"); // This branch is deprecated as it does not support unicode
    return s.c_str();   
#endif
}

Codepoints unicode bukan karakter! Kadang-kadang mereka bahkan bukan mesin terbang (bentuk visual).

Beberapa contoh:

• Codepoint angka romawi seperti "ⅲ". (Karakter tunggal yang terlihat seperti "iii".)
• Karakter beraksen seperti "á", yang dapat direpresentasikan sebagai karakter gabungan tunggal "\ u00e1" atau karakter dan diakritik terpisah "\ u0061 \ u0301".
• Karakter seperti sigma huruf kecil Yunani, yang memiliki bentuk berbeda untuk posisi kata tengah ("σ") dan akhir ("ς"), tetapi yang harus dianggap sinonim untuk pencarian.
• Unicode discretionary hyphen U + 00AD, yang mungkin atau mungkin tidak ditampilkan secara visual, tergantung pada konteksnya, dan yang diabaikan untuk pencarian semantik.

Satu-satunya cara untuk mendapatkan pengeditan Unicode yang benar adalah dengan menggunakan perpustakaan yang ditulis oleh seorang ahli , atau menjadi seorang ahli dan menulis sendiri. Jika Anda hanya menghitung codepoint, Anda hidup dalam keadaan dosa.

Ada aturan sederhana tentang apa yang Unicode Transformation Form (UTF) gunakan: - utf-8 untuk penyimpanan dan komunikasi - utf-16 untuk pemrosesan data - Anda bisa menggunakan utf-32 jika sebagian besar platform API yang Anda gunakan adalah utf-32 (umum di dunia UNIX).

Sebagian besar sistem saat ini menggunakan utf-16 (Windows, Mac OS, Java, .NET, ICU, Qt). Lihat juga dokumen ini: http://unicode.org/notes/tn12/

Kembali ke "UTF-16 sebagai berbahaya", saya akan mengatakan: pasti tidak.

Orang-orang yang takut akan pengganti (berpikir bahwa mereka mengubah Unicode menjadi pengkodean variabel-panjang) tidak memahami kompleksitas (cara yang lebih besar) lainnya yang membuat pemetaan antara karakter dan titik kode Unicode sangat kompleks: menggabungkan karakter, pengikat, pemilih pemilih , mengontrol karakter, dll.

Baca seri ini di sini http://www.siao2.com/2009/06/29/9800913.aspx dan lihat bagaimana UTF-16 menjadi masalah yang mudah.

Ya, tentu saja.

Mengapa? Itu ada hubungannya dengan menggunakan kode .

Jika Anda melihat statistik penggunaan codepoint ini pada sebuah corpus besar oleh Tom Christiansen, Anda akan melihat bahwa codepoint BMP trans-8bit digunakan beberapa pesanan jika besarnya lebih dari pada codepoint non-BMP:

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

Ambil diktum TDD: "Kode yang belum diuji adalah kode yang rusak", dan ulangi kata itu sebagai "kode yang tidak dieksekusi adalah kode yang rusak", dan pikirkan seberapa sering programmer harus berurusan dengan titik-titik kode non-BMP.

Bug yang terkait dengan tidak berurusan dengan UTF-16 sebagai pengodean lebar variabel lebih mungkin tidak diketahui daripada bug yang setara di UTF-8 . Beberapa bahasa pemrograman masih tidak menjamin untuk memberi Anda UTF-16, bukan UCS-2, dan beberapa bahasa pemrograman tingkat tinggi menawarkan akses ke unit kode alih-alih kode-poin (bahkan C seharusnya memberi Anda akses ke codepoints jika Anda gunakan wchar_t, terlepas dari apa yang mungkin dilakukan beberapa platform).

Saya akan menyarankan bahwa berpikir UTF-16 mungkin dianggap berbahaya mengatakan bahwa Anda perlu mendapatkan pemahaman yang lebih besar tentang unicode .

Karena saya telah kalah memilih untuk menyampaikan pendapat saya tentang pertanyaan subyektif, izinkan saya menguraikan. Apa sebenarnya yang mengganggu Anda tentang UTF-16? Apakah Anda lebih suka jika semuanya dikodekan dalam UTF-8? UTF-7? Atau bagaimana dengan UCS-4? Tentu saja aplikasi tertentu tidak dirancang untuk menangani kode karakter setiap orang di luar sana - tetapi mereka diperlukan, terutama dalam domain informasi global saat ini, untuk komunikasi antar batas internasional.

Tapi sungguh, jika Anda merasa UTF-16 harus dianggap berbahaya karena membingungkan atau dapat diimplementasikan secara tidak benar (unicode tentu saja bisa), lalu metode pengkodean karakter apa yang dianggap tidak berbahaya?

EDIT: Untuk memperjelas: Mengapa menganggap implementasi yang tidak tepat dari suatu standar mencerminkan kualitas dari standar itu sendiri? Seperti yang telah dicatat oleh orang lain, hanya karena aplikasi menggunakan alat secara tidak tepat, tidak berarti bahwa alat itu sendiri rusak. Jika itu masalahnya, kita mungkin bisa mengatakan hal-hal seperti "kata kunci var dianggap berbahaya", atau "threading dianggap berbahaya". Saya pikir pertanyaannya membingungkan kualitas dan sifat standar dengan kesulitan yang dimiliki banyak programmer dalam menerapkan dan menggunakannya dengan benar, yang saya rasa lebih berasal dari kurangnya pemahaman mereka tentang bagaimana unicode bekerja, daripada unicode itu sendiri.

Tidak ada yang salah dengan pengkodean Utf-16. Tetapi bahasa yang memperlakukan unit 16-bit sebagai karakter mungkin harus dianggap dirancang dengan buruk. Memiliki tipe bernama ' char' yang tidak selalu mewakili karakter cukup membingungkan. Karena sebagian besar pengembang akan mengharapkan tipe char untuk mewakili titik kode atau karakter, banyak kode mungkin akan rusak ketika terkena karakter di luar BMP.

Perhatikan bahwa meskipun menggunakan utf-32 tidak berarti bahwa setiap titik kode 32-bit akan selalu mewakili karakter. Karena menggabungkan karakter, karakter yang sebenarnya dapat terdiri dari beberapa titik kode. Unicode tidak pernah sepele.

BTW. Mungkin ada kelas bug yang sama dengan platform dan aplikasi yang mengharapkan karakter menjadi 8-bit, yang diberi makan Utf-8.

Pilihan pribadi saya adalah selalu menggunakan UTF-8. Ini standar di Linux untuk hampir semuanya. Ini kompatibel dengan banyak aplikasi lawas. Ada overhead yang sangat minimal dalam hal ruang ekstra yang digunakan untuk karakter non-latin vs format UTF lainnya, dan ada penghematan yang signifikan dalam ruang untuk karakter latin. Di web, bahasa latin berkuasa, dan saya pikir mereka akan melakukannya di masa mendatang. Dan untuk mengatasi salah satu argumen utama dalam posting asli: hampir setiap programmer menyadari bahwa terkadang UTF-8 memiliki karakter multi-byte di dalamnya. Tidak semua orang berurusan dengan ini dengan benar, tetapi mereka biasanya sadar, yang lebih dari yang bisa dikatakan untuk UTF-16. Tapi, tentu saja, Anda harus memilih yang paling sesuai untuk aplikasi Anda. Itu sebabnya ada lebih dari satu.

Ya, ada pengkodean yang menggunakan simbol ukuran tetap. Maksud saya UTF-32. Tetapi 4 byte untuk setiap simbol terlalu banyak ruang terbuang, mengapa kita menggunakannya dalam situasi sehari-hari?

Menurut saya, sebagian besar masalah muncul dari kenyataan bahwa beberapa perangkat lunak berada di belakang standar Unicode, tetapi tidak cepat untuk memperbaiki situasi. Opera, Windows, Python, Qt - semuanya muncul sebelum UTF-16 dikenal luas atau bahkan muncul. Namun, saya dapat mengonfirmasi bahwa di Opera, Windows Explorer, dan Notepad tidak ada masalah dengan karakter di luar BMP lagi (setidaknya pada PC saya). Tapi bagaimanapun, jika program tidak mengenali pasangan pengganti, maka mereka tidak menggunakan UTF-16. Apa pun masalah yang timbul dari berurusan dengan program-program tersebut, mereka tidak ada hubungannya dengan UTF-16 itu sendiri.

Namun, saya berpikir bahwa masalah perangkat lunak lama dengan hanya dukungan BMP agak berlebihan. Karakter di luar BMP hanya ditemui dalam kasus dan wilayah yang sangat spesifik. Menurut FAQ resmi Unicode , "bahkan dalam teks Asia Timur, kejadian pasangan pengganti harus rata-rata kurang dari 1% dari semua penyimpanan teks rata-rata". Tentu saja, karakter di luar BMP tidak boleh diabaikan karena program tidak sesuai dengan Unicode, tetapi sebagian besar program tidak dimaksudkan untuk bekerja dengan teks yang mengandung karakter tersebut. Itu sebabnya jika mereka tidak mendukungnya, itu tidak menyenangkan, tetapi bukan bencana.

Sekarang mari kita pertimbangkan alternatifnya. Jika UTF-16 tidak ada, maka kami tidak akan memiliki pengkodean yang cocok untuk teks non-ASCII, dan semua perangkat lunak yang dibuat untuk UCS-2 harus sepenuhnya dirancang ulang untuk tetap sesuai dengan Unicode. Yang terakhir kemungkinan besar hanya akan memperlambat adopsi Unicode. Kami juga tidak akan dapat mempertahankan kompabilitas dengan teks dalam UCS-2 seperti UTF-8 dalam kaitannya dengan ASCII.

Sekarang, dengan mengesampingkan semua masalah warisan, apa argumen yang menentang pengkodean itu sendiri? Saya benar-benar ragu bahwa pengembang saat ini tidak tahu bahwa UTF-16 panjang variabel, ditulis di mana-mana yang dimulai dengan Wikipedia. UTF-16 jauh lebih sulit diurai daripada UTF-8, jika seseorang menunjukkan kompleksitas sebagai masalah yang mungkin terjadi. Juga salah untuk berpikir bahwa mudah untuk mengacaukan dengan menentukan panjang string hanya di UTF-16. Jika Anda menggunakan UTF-8 atau UTF-32, Anda masih harus menyadari bahwa satu titik kode Unicode tidak selalu berarti satu karakter. Selain itu, saya tidak berpikir ada sesuatu yang substansial terhadap penyandian.

Karena itu saya tidak berpikir bahwa pengkodean itu sendiri harus dianggap berbahaya. UTF-16 adalah kompromi antara kesederhanaan dan kekompakan, dan tidak ada salahnya menggunakan apa yang diperlukan di mana itu diperlukan . Dalam beberapa kasus Anda harus tetap kompatibel dengan ASCII dan Anda perlu UTF-8, dalam beberapa kasus Anda ingin bekerja dengan bekerja dengan ideograf Han dan menghemat ruang menggunakan UTF-16, dalam beberapa kasus Anda perlu representasi universal karakter menggunakan tanda tetap pengkodean panjang. Gunakan apa yang lebih tepat, lakukan saja dengan benar.

Bertahun-tahun Windows internasionalisasi bekerja terutama dalam bahasa-bahasa Asia Timur mungkin telah merusak saya, tetapi saya condong ke UTF-16 untuk representasi string internal-ke-program, dan UTF-8 untuk penyimpanan jaringan atau file dokumen seperti plaintext. UTF-16 biasanya dapat diproses lebih cepat di Windows, jadi itulah manfaat utama menggunakan UTF-16 di Windows.

Membuat lompatan ke UTF-16 secara dramatis meningkatkan kecukupan produk rata-rata yang menangani teks internasional. Hanya ada beberapa kasus sempit ketika pasangan pengganti perlu dipertimbangkan (penghapusan, penyisipan, dan pemecahan garis, pada dasarnya) dan sebagian besar kasing rata-rata adalah pass-through langsung. Dan tidak seperti pengkodean sebelumnya seperti varian JIS, UTF-16 membatasi pasangan pengganti untuk rentang yang sangat sempit, sehingga pemeriksaannya sangat cepat dan bekerja maju dan mundur.

Memang, ini kira-kira sama cepatnya dengan UTF-8 yang dikodekan dengan benar. Tetapi ada juga banyak aplikasi UTF-8 yang rusak yang secara salah mengkodekan pasangan pengganti sebagai dua urutan UTF-8. Jadi UTF-8 tidak menjamin keselamatan juga.

IE menangani pasangan pengganti dengan cukup baik sejak 2000 atau lebih, meskipun biasanya mengubah mereka dari halaman UTF-8 ke representasi UTF-16 internal; Saya cukup yakin Firefox telah melakukannya dengan benar juga, jadi saya tidak begitu peduli apa yang dilakukan Opera.

UTF-32 (alias UCS4) tidak ada gunanya untuk sebagian besar aplikasi karena ini sangat menuntut ruang, jadi ini cukup nonstarter.

UTF-8 jelas merupakan cara yang harus ditempuh, mungkin disertai dengan UTF-32 untuk penggunaan internal dalam algoritma yang memerlukan akses acak berkinerja tinggi (tetapi mengabaikan kombinasi karakter).

Baik UTF-16 dan UTF-32 (serta varian LE / BE mereka) mengalami masalah endianess, sehingga mereka tidak boleh digunakan secara eksternal.

UTF-16? pasti berbahaya. Hanya sebutir garam saya di sini, tetapi ada tiga penyandian teks yang dapat diterima dalam sebuah program:

• ASCII: ketika berhadapan dengan hal-hal tingkat rendah (misalnya: mikrokontroler) yang tidak mampu membeli yang lebih baik
• UTF8: penyimpanan dalam media dengan lebar tetap seperti file

• integer codepoints ("CP"?): array bilangan bulat terbesar yang nyaman untuk bahasa dan platform pemrograman Anda (meluruh ke ASCII dalam batas resorpsi rendah). Seharusnya int32 pada komputer lama dan int64 pada apa pun dengan pengalamatan 64-bit.

• Jelas antarmuka ke kode lama menggunakan pengkodean apa yang diperlukan untuk membuat kode lama berfungsi dengan benar.

Unicode mendefinisikan poin kode hingga 0x10FFFF (1.114.112 kode), semua aplikasi yang berjalan di lingkungan multibahasa berurusan dengan string / nama file, dll. Harus menanganinya dengan benar.

Utf-16 : hanya mencakup 1.112.064 kode. Meskipun yang ada di akhir Unicode berasal dari pesawat 15-16 (Area Penggunaan Pribadi). Itu tidak dapat tumbuh lebih jauh di masa depan kecuali melanggar konsep Utf-16 .

Utf-8 : mencakup secara teoritis 2.216.757.376 kode. Rentang kode Unicode saat ini dapat diwakili oleh urutan maksimal 4 byte. Itu tidak menderita dengan masalah urutan byte , itu "kompatibel" dengan ascii.

Utf-32 : mencakup secara teoritis 2 ^ 32 = 4.294.967.296 kode. Saat ini tidak panjang variabel dikodekan dan mungkin tidak akan di masa depan.

Fakta-fakta itu jelas. Saya tidak mengerti menganjurkan penggunaan umum Utf-16 . Ini adalah variabel panjang yang disandikan (tidak dapat diakses oleh indeks), ia memiliki masalah untuk mencakup seluruh rentang Unicode bahkan saat ini, pesanan byte harus ditangani, dll. Saya tidak melihat keuntungan apa pun kecuali bahwa itu digunakan secara asli di Windows dan beberapa tempat lain. Meskipun saat menulis kode multi-platform, mungkin lebih baik menggunakan Utf-8 secara asli dan melakukan konversi hanya pada titik akhir dengan cara yang bergantung pada platform (seperti yang sudah disarankan). Ketika akses langsung dengan indeks diperlukan dan memori tidak menjadi masalah, Utf-32 harus digunakan.

Masalah utama adalah bahwa banyak programmer yang berurusan dengan Windows Unicode = Utf-16 bahkan tidak tahu atau mengabaikan fakta bahwa itu adalah panjang variabel yang dikodekan.

Cara biasanya di platform * nix cukup bagus, c string (char *) diartikan sebagai Utf-8 dikodekan, string c lebar (wchar_t *) diartikan sebagai Utf-32 .

Tambahkan ini ke daftar:

Skenario yang disajikan adalah sederhana (bahkan lebih sederhana karena saya akan menyajikannya di sini daripada pada awalnya!): 1.A WinForms TextBox duduk di Formulir, kosong. Ini memiliki MaxLength yang diatur ke 20 .

2.Pengguna mengetik ke dalam TextBox, atau mungkin menempelkan teks ke dalamnya.

3.Tidak peduli apa yang Anda ketik atau tempel ke dalam TextBox, Anda terbatas pada 20, meskipun akan berbunyi bip secara simpatik pada teks di luar 20 (YMMV di sini; Saya mengubah skema suara saya untuk memberi saya efek itu!).

4. Paket teks kecil kemudian dikirim ke tempat lain, untuk memulai petualangan yang mengasyikkan.

Sekarang ini adalah skenario yang mudah, dan siapa pun dapat menulis ini, di waktu luang mereka. Saya hanya menulis sendiri dalam beberapa bahasa pemrograman menggunakan WinForms, karena saya bosan dan belum pernah mencobanya sebelumnya. Dan dengan teks dalam berbagai bahasa aktual karena saya terhubung dengan kabel dan memiliki lebih banyak tata letak keyboard daripada siapa pun di seluruh alam semesta yang panik.

Aku bahkan menamai formulir Magic Carpet Ride , untuk membantu memperbaiki kebosanan.

Ini tidak berhasil, untuk apa nilainya.

Jadi sebagai gantinya, saya memasukkan 20 karakter berikut ke dalam formulir Magic Carpet Ride saya :

0123401234012340123 𠀀

Uh oh.

Karakter terakhir itu adalah U + 20000, ideograf Extension B pertama dari Unicode (alias U + d840 U + dc00, kepada teman-teman dekatnya yang tidak malu disingkap, seolah-olah, di depan) ....

Dan sekarang kami memiliki permainan bola.

Karena ketika TextBox.MaxLength berbicara tentang

Mendapat atau menetapkan jumlah karakter maksimum yang dapat dimasukkan secara manual ke dalam kotak teks.

apa itu sebenarnya berarti

Mendapat atau menetapkan jumlah maksimum unit kode UTF-16 LE yang dapat dimasukkan secara manual ke dalam kotak teks dan akan tanpa ampun memotong omong kosong yang hidup dari string apa pun yang mencoba memainkan permainan imut dengan gagasan karakter linguistik bahwa hanya seseorang yang terobsesi dengan Kaplan itu akan merasa ofensif (Ya ampun dia perlu keluar lebih banyak!).

Saya akan mencoba dan melihat tentang mendapatkan dokumen yang diperbarui ....
Pembaca reguler yang mengingat seri UCS-2 sampai UTF-16 saya akan mencatat ketidakbahagiaan saya dengan gagasan sederhana tentang TextBox.MaxLength dan bagaimana penanganannya minimal dalam kasus ini. di mana perilaku kejamnya menciptakan urutan ilegal, salah satu yang melemparkan bagian lain dari .Net Framework a

• System.Text.EncoderFallbackException: Tidak dapat menerjemahkan karakter Unicode \ uD850 pada indeks 0 ke halaman kode yang ditentukan. *

pengecualian jika Anda melewatkan string ini di tempat lain di .Net Framework (seperti yang dilakukan rekan saya Dan Thompson).

Sekarang oke, mungkin seri UCS-2 ke UTF-16 penuh berada di luar jangkauan banyak orang.
Tapi bukankah masuk akal untuk mengharapkan TextBox.Text tidak akan menghasilkan System.Stringyang tidak akan menyebabkan potongan lain dari .Net Framework untuk dibuang? Maksud saya, ini tidak seperti ada peluang dalam bentuk beberapa peristiwa pada kontrol yang memberi tahu Anda tentang pemotongan yang akan datang di mana Anda dapat dengan mudah menambahkan validasi yang lebih cerdas - validasi bahwa kontrol itu sendiri tidak keberatan dilakukan. Saya akan mengatakan bahwa kontrol punk ini melanggar kontrak keselamatan yang bahkan dapat menyebabkan masalah keamanan jika Anda dapat membuat pengecualian yang tidak terduga untuk menghentikan aplikasi sebagai semacam penolakan kasar terhadap layanan. Mengapa proses atau metode atau algoritma atau teknik WinForms apa pun menghasilkan hasil yang tidak valid?

Sumber: Michael S. Kaplan Blog MSDN

Saya tidak perlu mengatakan bahwa UTF-16 berbahaya. Itu tidak elegan, tetapi melayani tujuan kompatibilitas mundur dengan UCS-2, seperti halnya GB18030 dengan GB2312, dan UTF-8 tidak dengan ASCII.

Tetapi membuat perubahan mendasar pada struktur Unicode di tengah aliran, setelah Microsoft dan Sun membangun API besar sekitar karakter 16-bit, berbahaya. Kegagalan untuk menyebarkan kesadaran akan perubahan itu lebih berbahaya.

UTF-16 adalah kompromi terbaik antara penanganan dan ruang dan itulah mengapa sebagian besar platform utama (Win32, Java, .NET) menggunakannya untuk representasi internal string.

Saya tidak pernah mengerti maksud UTF-16. Jika Anda menginginkan representasi paling hemat ruang, gunakan UTF-8. Jika Anda ingin dapat memperlakukan teks sebagai panjang tetap, gunakan UTF-32. Jika Anda tidak menginginkan keduanya, gunakan UTF-16. Lebih buruk lagi, karena semua karakter umum (bidang multibahasa dasar) dalam UTF-16 muat dalam satu titik kode, bug yang menganggap bahwa UTF-16 adalah fixed-length akan sulit ditemukan, sedangkan jika Anda mencoba melakukan ini dengan UTF-8, kode Anda akan gagal dengan cepat dan keras segera setelah Anda mencoba menginternasionalkan.

_{Karena saya belum bisa berkomentar, saya memposting ini sebagai jawaban, karena sepertinya saya tidak bisa menghubungi penulis dari utf8everywhere.org. Sayang sekali saya tidak secara otomatis mendapatkan hak istimewa komentar, karena saya memiliki cukup reputasi di stackexchanges lainnya.}

Ini dimaksudkan sebagai komentar pada Pendapat: Ya, UTF-16 harus dianggap sebagai jawaban yang berbahaya .

Satu koreksi kecil:

Untuk mencegah satu dari secara tidak sengaja melewatkan UTF-8 char*ke versi ANSI-string fungsi Windows-API, orang harus mendefinisikan UNICODE, bukan _UNICODE. _UNICODEfungsi peta seperti _tcslenuntuk wcslen, tidak MessageBoxuntuk MessageBoxW. Alih-alih, UNICODEdefinisi tersebut mengatur yang terakhir. Sebagai bukti, ini dari WinUser.hheader MS Visual Studio 2005 :

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

Paling tidak, kesalahan ini harus diperbaiki utf8everywhere.org.

Sebuah sugesti:

Mungkin panduan ini harus berisi contoh penggunaan eksplisit dari versi Lebar-string dari struktur data, untuk membuatnya lebih mudah ketinggalan / lupakan. Menggunakan versi Lebar-string dari struktur data di atas menggunakan versi Lebar-fungsi fungsi membuatnya lebih kecil kemungkinannya bahwa seseorang secara tidak sengaja memanggil versi ANSI-string dari fungsi semacam itu.

Contoh dari contoh:

WIN32_FIND_DATAW data; // Note the W at the end.
HANDLE hSearch = FindFirstFileW(widen("*.txt").c_str(), &data);
if (hSearch != INVALID_HANDLE_VALUE)
{
    FindClose(hSearch);
    MessageBoxW(nullptr, data.cFileName, nullptr, MB_OK);
}

Seseorang mengatakan UCS4 dan UTF-32 sama. Tidak, tapi saya tahu apa yang Anda maksud. Salah satunya adalah pengkodean yang lain. Saya berharap mereka berpikir untuk menentukan endianness dari yang pertama sehingga kita tidak akan memiliki pertempuran endianess yang diperjuangkan di sini juga. Tidak bisakah mereka melihat kedatangan itu? Setidaknya UTF-8 adalah sama di mana-mana (kecuali seseorang mengikuti spesifikasi asli dengan 6-byte).

Jika Anda menggunakan UTF-16 Anda harus memasukkan penanganan untuk karakter multibyte. Anda tidak dapat pergi ke karakter Nth dengan mengindeks 2N ke dalam array byte. Anda harus berjalan, atau memiliki indeks karakter. Kalau tidak, Anda sudah menulis bug.

Draf spesifikasi C ++ saat ini mengatakan bahwa UTF-32 dan UTF-16 dapat memiliki varian little-endian, big-endian, dan tidak spesifik. Benarkah? Jika Unicode telah menetapkan bahwa setiap orang harus melakukan little-endian dari awal maka semuanya akan lebih sederhana. (Saya akan baik-baik saja dengan big-endian juga.) Sebaliknya, beberapa orang menerapkannya satu cara, beberapa yang lain, dan sekarang kita terjebak dengan kekonyolan untuk apa-apa. Terkadang memalukan menjadi insinyur perangkat lunak.

Saya tidak berpikir itu berbahaya jika pengembang cukup hati-hati.
Dan mereka harus menerima pertukaran ini jika mereka tahu juga.

Sebagai pengembang perangkat lunak Jepang, saya menemukan UCS-2 cukup besar dan membatasi ruang tampaknya menyederhanakan logika dan mengurangi memori runtime, jadi menggunakan utf-16 di bawah batasan UCS-2 cukup baik.

Ada filesystem atau aplikasi lain yang menganggap codepoint dan byte proporsional, sehingga nomor codepoint mentah dapat dijamin sesuai dengan beberapa penyimpanan ukuran tetap.

Salah satu contoh adalah NTFS dan VFAT menentukan UCS-2 sebagai pengkodean penyimpanan nama file mereka.

Jika contoh tersebut benar-benar ingin diperluas untuk mendukung UCS-4, saya bisa setuju menggunakan utf-8 untuk semuanya, tetapi panjang tetap memiliki poin yang baik seperti:

1. dapat menjamin ukuran berdasarkan panjang (ukuran data dan panjang codepoint sebanding)
2. dapat menggunakan nomor penyandian untuk pencarian hash
3. data yang tidak dikompresi berukuran cukup (dibandingkan dengan utf-32 / UCS-4)

Di masa depan ketika memori / kekuatan pemrosesan murah bahkan di perangkat embed, kami dapat menerima perangkat menjadi agak lambat untuk kesalahan cache tambahan atau kesalahan halaman dan penggunaan memori tambahan, tetapi ini tidak akan terjadi dalam waktu dekat saya kira ...

"Haruskah salah satu pengkodean paling populer, UTF-16, dianggap berbahaya?"

Sangat mungkin, tetapi alternatifnya tidak harus dipandang sebagai jauh lebih baik.

Masalah mendasar adalah bahwa ada banyak konsep berbeda tentang: mesin terbang, karakter, codepoint dan urutan byte. Pemetaan antara masing-masing adalah non-sepele, bahkan dengan bantuan perpustakaan normalisasi. (Sebagai contoh, beberapa karakter dalam bahasa Eropa yang ditulis dengan skrip berbasis Latin tidak ditulis dengan satu titik kode Unicode. Dan itu adalah akhir dari kerumitan yang lebih sederhana!) Apa artinya ini adalah untuk mendapatkan semuanya dengan benar sangat menakjubkan sulit; bug aneh diharapkan (dan bukannya hanya mengeluh tentang mereka di sini, beri tahu pengelola perangkat lunak yang bersangkutan).

Satu-satunya cara di mana UTF-16 dapat dianggap berbahaya sebagai kebalikan dari, katakanlah, UTF-8 adalah bahwa ia memiliki cara berbeda untuk menyandikan titik kode di luar BMP (sebagai pasangan pengganti). Jika kode ingin mengakses atau beralih berdasarkan titik kode, itu berarti perlu menyadari perbedaannya. OTOH, itu berarti bahwa tubuh substansial dari kode yang ada yang mengasumsikan "karakter" selalu dapat masuk ke dalam kuantitas dua byte - asumsi yang cukup umum, jika salah, - setidaknya dapat terus bekerja tanpa membangun kembali semuanya. Dengan kata lain, setidaknya Anda bisa melihat karakter yang tidak ditangani dengan benar!

Saya akan memutar pertanyaan Anda dan mengatakan bahwa seluruh shebang sialan Unicode harus dianggap berbahaya dan semua orang harus menggunakan pengkodean 8-bit, kecuali saya telah melihat (selama 20 tahun terakhir) di mana itu mengarah: mengerikan kebingungan atas berbagai pengkodean ISO 8859, ditambah seluruh rangkaian yang digunakan untuk Cyrillic, dan paket EBCDIC, dan ... yah, Unicode untuk semua kesalahannya mengalahkan itu. Kalau saja itu bukan kompromi jahat antara kesalahpahaman berbagai negara.