Haruskah penyandian karakter selain UTF-8 (dan mungkin UTF-16 / UTF-32) dihentikan?


31

Kencing hewan peliharaan saya sedang melihat begitu banyak proyek perangkat lunak yang memiliki banyak kode untuk dukungan set karakter. Jangan salah paham, saya semua mendukung kompatibilitas, dan saya senang editor teks membiarkan Anda membuka dan menyimpan file dalam beberapa set karakter. Yang mengganggu saya adalah bagaimana proliferasi pengkodean karakter non-universal diberi label "dukungan Unicode yang tepat" daripada "masalah".

Sebagai contoh, izinkan saya memilih PostgreSQL dan dukungan rangkaian karakternya . Penawaran PostgreSQL dengan dua jenis pengkodean:

  • Pengkodean klien: Digunakan dalam komunikasi antara klien dan server.
  • Pengkodean server: Digunakan untuk menyimpan teks secara internal dalam database.

Saya bisa mengerti mengapa mendukung banyak pengkodean klien adalah hal yang baik. Ini memungkinkan klien yang tidak beroperasi di UTF-8 untuk berkomunikasi dengan PostgreSQL tanpa perlu melakukan konversi. Apa yang tidak saya dapatkan adalah: mengapa PostgreSQL mendukung beberapa penyandian server ? File basis data (hampir selalu) tidak kompatibel dari satu versi PostgreSQL ke versi berikutnya, jadi kompatibilitas lintas versi bukan masalah di sini.

UTF-8 adalah satu-satunya set karakter standar yang kompatibel dengan ASCII yang dapat menyandikan semua codepoint Unicode (jika saya salah, beri tahu saya). Saya berada di perkemahan bahwa UTF-8 adalah set karakter terbaik , tetapi saya bersedia untuk memasang set karakter universal lainnya seperti UTF-16 dan UTF-32.

Saya percaya semua set karakter non-universal harus ditinggalkan. Apakah ada alasan kuat yang tidak seharusnya mereka lakukan?


4
@ Mario: Definisi asli UTF-8 diizinkan hingga 6 byte. Itu kemudian secara artifisial dibatasi hanya untuk menutupi karakter yang dapat didukung UTF-16.
dan04

6
Setidaknya PostgreSQL dengan sengaja menangani beberapa pengkodean karakter. Menyebalkan harus berurusan dengan campuran acak UTF-8 dan windows-1252 karena seseorang tidak peduli.
dan04

5
@ dan04: Bekerja dengan teks-teks Rusia dulunya menyebalkan, karena mereka menggunakan banyak penyandian yang sangat berbeda dan biasanya hanya meretas hal-hal untuk bekerja dengan menggunakan font yang berbeda (yang sering berbohong tentang penyandian yang digunakan dalam metadata mereka). Semua dalam semua, kekacauan yang mengerikan. Saya menduga mereka telah membersihkan - mungkin dengan pindah ke UTF-8 - karena jumlah permintaan dukungan dari arah itu telah turun begitu saja.
Donal Fellows

3
Kisaran Unicode teoretis adalah dari 0 hingga 0x10ffff. Tidak ada lagi. Itulah yang dikatakan standar Unicode. UTF-8 menangani semua Unicode dan selalu akan. Itu tidak mencakup jangkauan hipotetis dari suatu pengkodean yang bukan Unicode, tetapi mencakup semua Unicode.
gnasher729

Jawaban:


16

Karena Anda menyebutkan PostgreSQL, saya dapat mengatakan dengan beberapa otoritas bahwa alasan pembunuh utama mengapa pengkodean sisi-server non-UTF8 didukung dengan detail sedemikian rupa adalah bahwa Jepang membutuhkannya. Rupanya, konversi bolak-balik yang identik antara Unicode dan berbagai pengkodean "warisan" Jepang tidak selalu memungkinkan, dan dalam beberapa kasus tabel konversi bahkan berbeda di antara vendor. Benar-benar membingungkan, tetapi ternyata memang begitu. (Dukungan rangkaian karakter yang luas juga merupakan salah satu alasan mengapa PostgreSQL sangat populer di Jepang.)

Karena kita berbicara tentang sistem basis data, salah satu pekerjaan utama adalah untuk dapat menyimpan dan mengambil data dengan andal, seperti yang didefinisikan oleh pengguna, sehingga konversi kumpulan karakter yang hilang terkadang tidak dapat terbang. Jika Anda berurusan dengan peramban web, katakanlah, di mana yang paling penting adalah apakah hasilnya terlihat OK, maka Anda mungkin bisa lolos dengan mendukung penyandian yang lebih sedikit, tetapi dalam sistem basis data Anda memiliki persyaratan tambahan.

Beberapa alasan lain yang disebutkan dalam jawaban lain juga berlaku sebagai argumen pendukung. Tetapi selama Jepang memveto itu, dukungan pengaturan karakter tidak dapat dikurangi.


Jadi, karena penyandian ini, konversi teks ke UTF-8 dan kembali bersifat umum? Bahkan jika konversi kembali dilakukan segera (bukan 6 bulan dari sekarang)?
Joey Adams

Joey Adams: Rupanya begitu.
Peter Eisentraut

3
Google untuk "unifikasi Han" untuk mengetahui alasannya
Petr Viktorin

7

Dua alasan yang jelas: tergantung pada data yang Anda simpan, mengonversi ke format lain bisa memakan waktu dan ruang ekstra. Jika Anda menyimpan 400 megabyte informasi, menggandakan persyaratan penyimpanan bukanlah masalah besar - tetapi jika Anda menyimpan 400 terabyte itu mulai berarti lebih banyak. Mengonversi 400 terabyte data dari (katakanlah) Shift-JIS ke UTF-x bisa memakan sedikit waktu juga.

Ini menjadi sangat sulit jika Anda memiliki (misalnya) jaminan uptime yang mengatakan bahwa basis data akan tersedia untuk semua tetapi, katakanlah, 10 menit dari tahun tertentu, dan Anda memiliki basis data yang diperbarui beberapa ratus kali per detik. Pikiran Anda, masih mungkin untuk mengelola konversi besar dalam situasi seperti itu, tetapi itu bukan sesuatu yang harus dilakukan dengan ringan. Dalam beberapa kasus, mungkin perlu waktu bertahun - tahun perencanaan untuk bersiap-siap untuk konversi semacam itu.

Jika Anda mulai dengan basis data yang (misalnya) hanya mendukung ASCII, mungkin ada alasan bagus untuk berdebat apakah masuk akal untuk menambahkan dukungan untuk semua penyandian tersebut - tetapi jika Anda sudah mendukungnya, ada sedikit keuntungan dari menjatuhkan mendukung mereka.

Perhatikan, khususnya, bahwa Anda mungkin tidak akan mendapatkan apa-apa dengan cara menyederhanakan kode, atau semacamnya. Mereka masih membutuhkan semua rutinitas konversi untuk menangani konversi antara klien dan server. Dengan demikian, menjatuhkan dukungan berarti menjatuhkan satu panggilan fungsi (kecil) di jalur "tulis ke disk" dan "baca dari disk", tetapi sedikit (jika ada yang lain). Jika Anda mendukung bahkan dua penyandian pada disk, Anda bahkan tidak akan memperolehnya - Anda masih memiliki panggilan fungsi di sana, jadi semua yang Anda benar-benar akan lakukan akan membatasi rentang penyandian yang didukung oleh fungsi itu.

Setidaknya jika saya sedang merancang ini, saya mungkin akan menulis inti dari database untuk bekerja di UCS-4, dan kemudian memiliki rutinitas konversi antara inti dan disk, dan antara inti dan pengguna. Saya akan menggunakan set rutin yang sama dalam kedua kasus, jadi rute paling sederhana adalah dengan memungkinkan penyimpanan disk untuk menggunakan set pengkodean yang sama persis seperti yang diizinkan oleh klien.


1
Shift-JIS adalah non-sinkronisasi, yang membuat pencarian rumit. Anda akan mendapatkan penyederhanaan yang signifikan dengan tidak mendukungnya.
dan04

@ dan04: jika Anda sudah memiliki rutinitas pencarian / pengindeksan terbukti-waktu untuk Shift-JIS, beralih ke UTF-8 atau bahkan UCS2 mungkin akan meningkatkan kinerja secara tidak signifikan. Untuk database baru Anda dapat memilih pengkodean yang lebih baik, lebih nyaman dan teratur, seperti UCS2 atau UTF-16.
9000

@ dan04: jika Anda bisa lolos dengan tidak mendukung sama sekali, Anda akan mendapatkan sedikit. Selama Anda mendukungnya datang dari / pergi ke klien, Anda akan terjebak dengan sebagian besar keburukannya ...
Jerry Coffin

5

Ada beberapa masalah dengan hanya menyimpan UTF-8 di server:

  1. Berapa batas VARCHAR(20)kolom? Apakah itu 20 byte, atau 20 "karakter" (dan di Unicode, apa itu "karakter" ketika Anda menggabungkan karakter, pengikat dan sebagainya?). Lebih buruk lagi, bagaimana dengan di CHAR(20)mana ia sebenarnya harus mencadangkan seluruh ruang yang mungkin: Saya percaya pada MySQL, cadangan 4 kali jumlah byte untuk kolom yang dikodekan UTF-8 (jadi 80 byte CHAR(20)) hanya untuk menangani kasus terburuk.
  2. Anda harus melakukan konversi penyandian konstan antara penyandian server dan penyandian klien Anda. Anda bisa berargumen bahwa Anda ingin berhenti mendukung beberapa pengkodean klien juga, tetapi kecuali Anda melakukannya, maka semua string perlu dikonversi sepanjang waktu. Jika Anda dapat mencocokkan pengodean server dan pengodean klien, maka konversi tidak diperlukan.
  3. Seperti orang lain tunjukkan, UTF-8 cukup efisien untuk menyimpan teks bahasa Inggris, tetapi sangat tidak efisien untuk bahasa lain - khususnya bahasa Asia Timur. Anda bisa mengizinkan penggunaan UTF-16 atau UTF-8 sesuai, kurasa. Atau kompres teks, tetapi itu membuat pengindeksan dan pencarian menjadi tidak efisien.

Setelah mengatakan semua itu, saya setuju dengan Anda: penyandian sebelumnya sebagian besar tidak ada gunanya dan Unicode umumnya penyandian terbaik untuk digunakan untuk semua aplikasi baru. Jika saya menulis server database dari awal hari ini, saya hanya akan mendukung Unicode dan tidak mendukung encoding legacy sama sekali.

Perbedaannya adalah bahwa PostgreSQL dan sebagian besar server database lain yang digunakan saat ini ada sebelum Unicode adalah opsi yang layak. Jadi mereka sudah memiliki dukungan untuk pengkodean warisan (mereka bukan warisan pada saat itu, tentu saja) dan tidak ada banyak gunanya merobek semua kode itu karena alasan ideologis.


10
"tetapi sangat tidak efisien untuk bahasa lain - bahasa Asia timur, khususnya" Bahkan dalam praktik? Pertimbangkan halaman Wikipedia bahasa Mandarin ini . Meskipun menampilkan banyak sekali karakter Cina, dalam sumber halaman, karakter ASCII membanjiri mereka hampir 7: 1.
Joey Adams

2
Jika N di kolom CHAR (N) Anda adalah bagian dari format pengidentifikasi yang terdefinisi dengan baik (misalnya, VIN didefinisikan tepat 17 karakter), maka mungkin tidak perlu menggabungkan karakter atau ligatur. Jika tidak, maka N hanyalah batas arbitrer, yang harus ditafsirkan dengan murah hati untuk menghindari pemotongan data.
dan04

5
@ Joey Adams: itu benar dari HTML dan XML di mana markup itu sendiri membuat sebagian besar teks (dan itulah mengapa saya pikir UTF-8 adalah pilihan yang baik untuk web), tetapi dalam database Anda tidak sering menyimpan HTML. Pada akhirnya, itu hanya faktor dua (atau kurang) perbedaan, yang sebenarnya tidak terlalu banyak.
Dean Harding

5
Butir poin # 2 dalam jawaban ini tidak relevan: itu berlaku apakah Unicode digunakan atau tidak. Butir poin # 3 benar-benar melebih-lebihkan inefisiensi dan cakupannya. Pada saat yang sama, jawaban ini sangat mengecilkan masalah yang disebabkan oleh penyandian sebelumnya. Mudah untuk mengasumsikan bahwa masalahnya bukan masalah besar jika semua yang Anda gunakan dalam hidup Anda adalah bahasa Inggris.
Timwi

2
@Dean: Saya tidak tahu itu tidak diizinkan untuk mengomentari jawaban tanpa memposting salah satu dari saya sendiri.
Timwi

3

Pengkodean non-universal (dan khususnya byte tunggal) memang memiliki tempatnya: Pada sistem yang:

  • Tidak memiliki cukup memori untuk menyimpan Database Karakter Unicode.
  • Memiliki font byte tunggal yang dikodekan dalam ROM.
  • Tidak memiliki akses Internet untuk menyediakan sumber file yang disandikan berbeda.

Itu berlaku hari ini untuk beberapa jenis perangkat tertanam. Tetapi di desktop, dan di ruang server, pengkodean non-Unicode sudah lama usang sekarang.


3
Saya dulu punya komputer di rumah seperti itu. Saya menyingkirkan sebagian besar dari mereka di awal 80-an.
David Thornley

2

UTF-8 adalah yang terbaik untuk Anda penutur bahasa Inggris egosentris 1 . Jika Anda orang Jepang, sekitar 99% karakter Anda akan mengambil 3-4 byte, bukan dua di UTF-16.

Dialek non-latin benar-benar menderita UTF-8 pada tingkat ukuran. Jangan lupa bahwa dalam beberapa tahun, sebagian besar klien Anda mungkin orang Cina, dan tulisan China memiliki jutaan karakter. Anda tidak dapat mempertahankannya secara efisien dengan UTF-8.

Kalau tidak, saya benci kalau saya punya dokumen teks yang tidak ada di UTF- sesuatu . Saya akan sering pergi keluar dari jalan saya jika saya perlu memiliki penyandian yang tepat. Dalam buku saya, penyandian non-Unicode sudah mati.

1. Jangan mengambil bagian egosentris secara pribadi. Saya ingin membuat ilustrasi yang penuh warna dan saya tidak sungguh-sungguh.


3
@ Matthew - 4x jelas 4 kali lebih besar dari x (untuk x positif). Saya tidak melihat bagaimana notasi asimptotik relevan di sini. Saya belum pernah melihat hard disk diiklankan dengan tingkat pertumbuhan asimptotik. Biasanya, ukurannya tetap sama sepanjang umur drive.
Steve314

3
Jutaan karakter tidak akan muat di Unicode. Menurut artikel Wikipedia, saat ini ada sekitar enam puluh ribu karakter Han. Karena Unicode bukan hanya bahasa Cina, itu berarti bahwa sejumlah besar karakter Cina akan mengambil empat byte dalam UTF-16, yang selama UTF-8 dapatkan saat ini. Akan menarik untuk melihat statistik panjang teks bahasa Mandarin di UTF-8 dan UTF-16.
David Thornley

6
@ David:> 99% dari semua tulisan Jepang dan Cina menggunakan karakter yang hanya membutuhkan 2 byte di UTF-16 dan 3 di UTF-8. Karakter yang membutuhkan lebih banyak sangat jarang dan / atau historis.
Timwi

8
Perlu diingat bahwa bahasa Jepang dan Cina umumnya menggunakan lebih sedikit karakter per kata. Saya bekerja dengan aplikasi yang memiliki file bahasa besar dalam bahasa Inggris, Jepang dan Cina, semua dikodekan dalam utf-8. File berbahasa Mandarin sebenarnya adalah yang terkecil, sedangkan file berbahasa Jepang sekitar 15% lebih besar dari aslinya.
Gort the Robot

3
Omong kosong. Apa pun yang membutuhkan dua byte di UTF-16 tidak lebih dari 3 byte di UTF-8. Apa pun yang empat byte di UTF-8 adalah 4 byte di UTF-16. Tidak ada "jutaan" karakter Cina, dan jelas mereka tidak akan masuk ke dalam 16 bit.
gnasher729

1

Unicode pada dasarnya rusak, dan tidak mungkin diperbaiki. Itu perlu digantikan oleh sesuatu yang lebih baik, sesuatu yang benar-benar universal. Jika ada sesuatu yang perlu ditinggalkan, itu Unicode.

Contoh masalah dengan Unicide:

  • UTF8 adalah hack yang wajar, tetapi sebagian besar perangkat lunak berbasis UTF16 rusak. Sebagian besar aplikasi Windows yang mendukung Unicode menggunakan UTF16, termasuk OS itu sendiri. Masalah yang paling umum adalah tidak mendukung lebih dari bidang dasar, yaitu karakter multi-kata.

  • Unifikasi Han adalah bencana yang tak terselesaikan. Tidak mungkin untuk mencampur teks Jepang / Cina / Korea dalam satu dokumen tanpa metadata tambahan, dan sulit untuk mendeteksi font mana yang harus digunakan.

  • Karakter kombinasi adalah bencana lain. Skema pengodean yang lebih masuk akal memetakan satu karakter ke satu kode, yang membuat string pemrosesan relatif waras. Unicode tidak. Unicode bahkan tidak konsisten - sebagian besar karakter Han adalah kombinasi, tetapi tidak dikodekan seperti itu, sedangkan karakter kombinasional Eropa.

  • Beberapa nama orang tidak dapat ditulis dengan benar dalam Unicode, atau sangat rentan untuk dirender secara tidak benar karena masalah yang disebutkan di atas. Ini dapat memiliki konsekuensi yang parah, misalnya ketika mencoba naik pesawat dengan paspor yang tidak cocok dengan apa yang (tidak benar) dicetak pada tiket.

Karena masalah ini dan banyak lagi, banyak perangkat lunak non-Inggris tidak dapat menggunakan Unicode dan bergantung pada pengkodean karakter lokal. Ini sangat umum dengan perangkat lunak Jepang dan Cina.

Idealnya, Unicode harus ditinggalkan. Pengodean karakter TRON adalah pengganti Unicode yang cukup bagus, dan sebagian besar kompatibel untuk perangkat lunak yang ada yang tidak akan diperbarui.


Klaim Anda bahwa tidak mungkin untuk mencampur varian karakter yang berbeda (Jepang / Korea / Cina) tampaknya sudah ketinggalan zaman sejak 15 tahun, standar Unicode 3.2 pada tahun 2002. Unicode mendukung penyeleksi Variasi, codepoint yang setelah codepoint han secara eksplisit menentukan bentuk mana yang harus ditampilkan. Juga karakter kombinatorial ditentukan baik sebagai "menggabungkan tanda diakritik" dengan karakter dasar (a °) dan mesin terbang khusus (å), proses konversi mereka sebaliknya juga adalah "normalisasi". Jadi, tidak, Unicode tidak rusak secara fundamental.
Thorsten S.

Anda mengilustrasikan banyak kekurangan. Beberapa bahasa menggunakan karakter kombinasi, beberapa tidak, dan Unicode tidak dapat memutuskan mana yang lebih disukai. Seperti yang saya tunjukkan, sebagian besar perangkat lunak yang mengklaim mendukung Unicode toh tidak memahami masalah-masalah itu dan akan menampilkannya salah bahkan dengan pemilihnya. Pemrogram seharusnya tidak diharapkan menjadi ahli bahasa, yang merupakan kelemahan mendasar lainnya di Unicode.
pengguna

0

Mungkin untuk menulis, tetapi tidak untuk membaca.

Ada banyak konten yang ada yang menggunakan pengkodean itu, dan beberapa pengkodean seperti base64 tidak pergi ke mana pun karena beberapa protokol teks mengamanatkannya sebagai cara untuk menanamkan data biner.

Masalah sebenarnya adalah deteksi otomatis penyandian yang mengarah ke lubang keamanan. Saya tidak keberatan melihat beberapa penyandian yang tidak jelas seperti UTF-7 hilang begitu saja.

Deteksi otomatis juga cenderung berurusan dengan buruk dengan konten yang dihasilkan oleh string byte yang digabungkan secara naif.


7
Base64 bukan pengkodean karakter.
dan04

0

Saya setuju bahwa pengkodean karakter default untuk database dan aplikasi baru harus semacam varian UTF. Saya pribadi akan memilih UTF-16 karena tampaknya merupakan tradeoff yang wajar pada ruang dan kompleksitas (lebih dari UTF-8). Yang mengatakan, beberapa pengkodean karakter masih masuk akal dalam kasus-kasus tertentu.

  • Jika Anda menyimpan / mentransfer teks base64, Anda hanya perlu ASCII dan Anda bahkan bisa lolos dengan protokol 7-bit yang dikodekan seperti email. Overhead tambahan UTF-8 tidak perlu.
  • Beberapa file dan data yang ada dibangun di atas pengkodean karakter yang lebih lama ini, karena dapat membacanya adalah penting.

Perhatikan bahwa ada 4 algoritma normalisasi UTF standar. Jika Anda khawatir tentang karakter multi-codepoint, Anda dapat menggunakan salah satu dari dua algoritma normalisasi yang menciutkannya menjadi karakter single-codepoint yang setara. Perbedaan antara mereka ada hubungannya dengan kesetaraan logis vs kesetaraan fisik karakter.


1
Bisakah para downvoter mengatakan mengapa mereka downvot?
Berin Loritsch

3
Saya tidak melakukan downvote, tetapi inti base64 adalah mentransfer data biner ke saluran teks. Jika Anda dapat memilih pengkodean apa yang akan digunakan pada saluran itu, Anda tidak akan menggunakan pengkodean teks sama sekali. Bahkan jika saluran Anda benar-benar ASCII biasa, basis 64 hanya menggunakan 6 dari 7 bit - sudah ada overhead yang signifikan.
Steve314

Saya harap seseorang tidak hanya membaca poin-poinnya. Itu adalah pengecualian untuk menggunakan UTF. Dan Anda salah tentang basis 64 hanya menggunakan 6 dari 8 byte. Set pertama "karakter" ASCII adalah karakter kontrol yang tidak dapat dicetak, yang memaksa beberapa karakter di base64 untuk menggunakan 7 dari 8 byte. Itu sengaja menghindari bit tinggi karena semua karakter tidak dijamin ada di setiap halaman kode, sedangkan karakter dari 0-127 adalah.
Berin Loritsch

2
@Berin - (1) tidak, tetapi hal-hal "Saya setuju" tidak banyak tanpa poin-poin, dan (2) base 64 memiliki 64 "digit". 64 digit bernilai 6 bit, karena 2 ^ 6 == 64. Bagaimana Anda menyatakan bahwa dalam ruang kode 7 bit (atau 8 bit, atau bahkan 8 byte jika Anda harus) terpisah dari berapa banyak data yang benar-benar ada. Menghindari karakter non-cetak dll adalah alasan untuk overhead - itu tidak berarti overhead tidak ada Pilih saluran yang dirancang untuk data biner dan overhead itu tidak ada.
Steve314

3
Ingatlah bahwa base64 diciptakan untuk menangani pengiriman data biner melalui saluran hanya teks. Ini diketahui tidak efisien (ekspansi 3: 4), tetapi berurusan dengan keterbatasan teknis dalam opsi transportasi tertentu. Legacy akan berupa email dan forum UseNet, tetapi aplikasi yang lebih modern akan menyematkan data biner dalam XML. Terkadang saluran yang tepat tidak ada , dan Anda harus bekerja melalui batasan yang ada.
Berin Loritsch
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.