Platform apa yang memiliki sesuatu selain karakter 8-bit?

138

Sesekali, seseorang di SO menunjukkan bahwa char(alias 'byte') belum tentu 8 bit .

Tampaknya 8-bit charhampir universal. Saya akan berpikir bahwa untuk platform arus utama, perlu memiliki 8-bit charuntuk memastikan kelangsungan hidupnya di pasar.

Baik sekarang dan secara historis, platform apa yang menggunakan charyang bukan 8 bit, dan mengapa mereka berbeda dari 8 bit "normal"?

Saat menulis kode, dan memikirkan tentang dukungan lintas platform (misalnya untuk pustaka penggunaan umum), pertimbangan macam apa yang layak diberikan untuk platform dengan non-8-bit char?

Di masa lalu saya telah menemukan beberapa Perangkat Analog DSP yang char16 bit. DSP adalah sedikit arsitektur khusus yang saya kira. (Kemudian lagi, pada saat assembler dengan kode tangan dengan mudah mengalahkan apa yang dapat dilakukan oleh kompiler C yang tersedia, jadi saya tidak benar-benar mendapatkan banyak pengalaman dengan C pada platform itu.)

c++  c  cross-platform 
— Craig McQueen
sumber
9
Seri CDC Cyber ​​memiliki pengkodean 6/12 bit. Karakter paling populer adalah 6 bit. Karakter yang tersisa menggunakan 12 bit.
— Thomas Matthews
2
PDP-11 berhasil melakukannya. Gagasan bahwa karakter dapat dikodekan dalam karakter benar-benar usang.
— Hans Passant
7
"PDP-11 berhasil" - Maksud Anda karena C pertama kali diimplementasikan untuk PDP-11 dengan 8 bit byte? Tetapi C selanjutnya diimplementasikan untuk mesin Honeywell dengan 9 bit byte. Lihat K&R versi 1. Juga, pertanyaan yang diajukan tentang char (yaitu byte) bukan tentang karakter (satu atau lebih byte yang menyandikan sesuatu yang tidak ditanyakan).
— Pemrogram Windows
6
DEC-10 dan DEC-20 memiliki kata 36-bit. Lima karakter ASCII 7-bit per kata cukup umum. Juga enam karakter 6-bit digunakan.
— David R Tribble
3
@CraigMcQueen: Jika saya ingat dengan benar, CodeVision untuk mikrokontroler Atmel memungkinkan seseorang memilih ukuran char
— vsz

Jawaban:

81

charjuga 16 bit di Texas Instruments C54x DSP, yang muncul misalnya di OMAP2. Ada DSP lain di luar sana dengan 16 dan 32 bit char. Saya rasa saya pernah mendengar tentang DSP 24-bit, tetapi saya tidak ingat apa, jadi mungkin saya membayangkannya.

Pertimbangan lain adalah mandat POSIX CHAR_BIT == 8. Jadi jika Anda menggunakan POSIX, Anda dapat mengasumsikannya. Jika kemudian seseorang perlu mem-port kode Anda ke implementasi POSIX yang hampir selesai, yang kebetulan memiliki fungsi yang Anda gunakan tetapi ukurannya berbeda char, itu adalah nasib buruk mereka.

Namun secara umum, menurut saya, mengatasi masalah ini hampir selalu lebih mudah daripada memikirkannya. Ketik saja CHAR_BIT. Jika Anda menginginkan tipe 8 bit yang tepat, gunakan int8_t. Kode Anda akan gagal untuk dikompilasi pada implementasi yang tidak menyediakannya, alih-alih diam-diam menggunakan ukuran yang tidak Anda harapkan. Paling tidak, jika saya menemukan kasus di mana saya memiliki alasan kuat untuk mengasumsikannya, maka saya akan menegaskannya.

— Steve Jessop
sumber
2
TI C62xx dan C64xx DSP juga memiliki karakter 16-bit. (uint8_t tidak ditentukan pada platform itu.)
— myron-semack
7
Banyak DSP untuk pemrosesan audio adalah mesin 24-bit; yang BelaSigna DSP dari Pada Semi (setelah mereka membeli AMI Semi); yang DSP56K / Symphony Audio DSP dari Freescale (setelah mereka dipisahkan dari Motorola).
— David Cary
2
@msemack C64xx memiliki perangkat keras untuk 8/16/32/40, dan karakter 8bit
— pengguna3528438
4
Daripada assert()(jika itu yang Anda maksud), saya akan menggunakan #if CHAR_BIT != 8... #error "I require CHAR_BIT == 8"...#endif
— Keith Thompson
1
@Keompson_Adakah alasan untuk tidak menggunakan static_assert()?
— Qix - MONICA DISALAHKAN
37

Saat menulis kode, dan memikirkan tentang dukungan lintas platform (misalnya untuk pustaka penggunaan umum), pertimbangan macam apa yang layak diberikan kepada platform dengan karakter non-8-bit?

Ini tidak terlalu berarti bahwa "layak memberikan pertimbangan" pada sesuatu karena itu dimainkan sesuai aturan. Dalam C ++, misalnya, standar mengatakan semua byte akan memiliki "setidaknya" 8 bit. Jika kode Anda mengasumsikan bahwa byte memiliki tepat 8 bit, Anda melanggar standar.

Ini mungkin tampak konyol sekarang - " tentu saja semua byte memiliki 8 bit!", Saya mendengar Anda berkata. Tetapi banyak orang yang sangat pintar mengandalkan asumsi yang bukan jaminan, dan kemudian semuanya rusak. Sejarah penuh dengan contoh-contoh seperti itu.

Misalnya, sebagian besar pengembang awal 90-an berasumsi bahwa penundaan waktu CPU tanpa operasi tertentu yang mengambil sejumlah siklus tetap akan memakan waktu jam yang tetap, karena sebagian besar CPU konsumen kira-kira memiliki daya yang setara. Sayangnya, komputer menjadi lebih cepat dengan sangat cepat. Hal ini melahirkan munculnya kotak-kotak dengan tombol "Turbo" - yang tujuannya, ironisnya, adalah untuk memperlambat komputer sehingga game yang menggunakan teknik penundaan waktu dapat dimainkan dengan kecepatan yang wajar.

Seorang pemberi komentar bertanya di bagian mana dalam standar dikatakan bahwa char harus memiliki setidaknya 8 bit. Ini di bagian 5.2.4.2.1 . Bagian ini mendefinisikan CHAR_BIT, jumlah bit dalam entitas beralamat terkecil, dan memiliki nilai default 8. Ia juga mengatakan:

Nilai yang ditetapkan implementasinya harus sama atau lebih besar besarnya (nilai absolut) dengan yang ditunjukkan, dengan tanda yang sama.

Jadi angka apa pun yang sama dengan 8 atau lebih tinggi cocok untuk diganti dengan implementasi ke CHAR_BIT.

— John Feminella
sumber
6
Saya belum pernah melihat tombol Turbo dalam setidaknya 20 tahun - apakah menurut Anda itu sesuai dengan pertanyaan?
— Mark Ransom
29
@ Mark Ransom: Itulah intinya. Pengembang sering kali mengandalkan asumsi yang tampaknya benar saat ini, tetapi jauh lebih goyah daripada yang semula terlihat. (Tidak dapat menghitung berapa kali saya telah membuat bahwa kesalahan!) Turbo tombol harus menjadi pengingat yang menyakitkan untuk tidak membuat asumsi yang tidak perlu, dan tentu saja tidak membuat asumsi yang tidak dijamin oleh standar bahasa seolah-olah mereka fakta yang tidak bisa diubah.
— John Feminella
1
Bisakah Anda menunjukkan tempat di C ++ Standard yang mengatakan bahwa bye memiliki setidaknya 8 bit? Itu adalah kepercayaan umum namun saya pribadi gagal menemukannya dalam Standar. Satu-satunya hal yang saya temukan di Standar adalah karakter mana yang harus dapat diwakili oleh charada lebih dari 64 dari mereka tetapi kurang dari 128 sehingga 7 bit akan cukup.
— Adam Badura
6
Bagian 18.2.2 menggunakan standar C untuk itu. Dalam standar C itu bagian 7.10 dan kemudian bagian 5.4.2.4.1. Halaman 22 dalam standar C.
— Pemrogram Windows
2
Jadi jawaban dan komentar lain menyebutkan mesin dengan 5 bit, 6 bit dan 7 bit byte. Apakah itu berarti Anda tidak dapat menjalankan program C pada mesin yang sesuai dengan standar?
— Jerry Jeremiah
34

Mesin dengan arsitektur 36-bit memiliki byte 9-bit. Menurut Wikipedia, mesin dengan arsitektur 36-bit meliputi:

  • Perusahaan Peralatan Digital PDP-6/10
  • IBM 701/704/709/7090/7094
  • UNIVAC 1103 / 1103A / 1105/1100/2200,
— R Samuel Klatchko
sumber
7
Juga mesin Honeywell, seperti mungkin mesin kedua tempat C diterapkan. Lihat K&R versi 1.
— Pemrogram Windows
5
Sebenarnya, Dec-10 juga memiliki karakter 6-bit - Anda dapat mengemas 6 di antaranya menjadi kata 36-bit (mantan programmer Des-10 berbicara)
2
DEC-20 menggunakan lima karakter ASCII 7-bit per 36-bit kata pada TOPS-20 O / S.
— David R Tribble
3
Lelucon itu sebenarnya diimplementasikan untuk mendukung Unicode pada arsitektur ini.
— Joshua
9
Saya membayangkan bahwa alasan oktal pernah benar-benar digunakan adalah karena 3 digit oktal dengan rapi mewakili byte 9-bit, seperti biasanya kita menggunakan heksadesimal hari ini karena dua digit heksadesimal dengan rapi mewakili byte 8-bit.
— bames53
18

Beberapa yang saya sadari:

  • DEC PDP-10: variabel, tetapi paling sering karakter 7-bit dikemas 5 per kata 36-bit, atau karakter 9 bit, 4 per kata
  • Mainframe Data Kontrol (CDC-6400, 6500, 6600, 7600, Cyber ​​170, Cyber ​​176 dll.) Karakter 6-bit, dikemas 10 per kata 60-bit.
  • Mainframe Unisys: 9 bit / byte
  • Windows CE: sama sekali tidak mendukung jenis `char` - membutuhkan wchar_t 16-bit sebagai gantinya
— Jerry Coffin
sumber
2
@ephemient: Saya cukup yakin ada setidaknya satu kompiler C (pra-standar) untuk PDP-10 / DecSystem 10 / DecSystem 20. Saya akan sangat terkejut dengan kompiler C untuk mainframe CDC (mereka digunakan terutama untuk pekerjaan numerik, jadi kompiler Fortran adalah yang terpenting di sana). Saya cukup yakin yang lain memiliki kompiler C.
— Jerry Coffin
3
Apakah compiler Windows CE benar-benar tidak mendukung chartipe ini sama sekali? Saya tahu bahwa pustaka sistem hanya mendukung versi lebar dari fungsi yang mengambil string, dan bahwa setidaknya beberapa versi WinCE menghapus fungsi string ANSI seperti strlen, untuk menghentikan Anda melakukan penanganan string char. Tetapi apakah itu benar-benar tidak memiliki tipe karakter sama sekali? Apa itu sizeof(TCHAR)? Jenis apa yang dikembalikan malloc? Bagaimana bytetipe Java diimplementasikan?
— Steve Jessop
10
Windows CE mendukung char, yang merupakan byte. Lihat komentar Craig McQueen atas jawaban Richard Pennington. Byte dibutuhkan sama banyaknya di Windows CE seperti di mana pun, tidak peduli ukurannya di mana pun.
— Pemrogram Windows
2
Ada (were?) Setidaknya ada dua implementasi C untuk PDP-10: KCC dan port gcc ( pdp10.nocrew.org/gcc ).
— Pemrogram
3
Standar C tidak mengizinkan karakter 7-bit yang dikemas 5 per kata 36-bit (seperti yang Anda sebutkan untuk PDP-10), juga tidak mengizinkan karakter 6-bit, seperti yang Anda sebutkan untuk mainframe Data Kontrol. Lihat parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.6
— Ken Bloom
15

Tidak ada yang namanya kode yang sepenuhnya portabel. :-)

Ya, mungkin ada berbagai ukuran byte / karakter. Ya, mungkin ada implementasi C / C ++ untuk platform dengan nilai CHAR_BITdan UCHAR_MAX. Ya, terkadang dimungkinkan untuk menulis kode yang tidak bergantung pada ukuran karakter.

Namun, hampir semua kode nyata tidak berdiri sendiri. Misalnya, Anda mungkin menulis kode yang mengirim pesan biner ke jaringan (protokol tidak penting). Anda dapat menentukan struktur yang berisi bidang yang diperlukan. Daripada Anda harus membuat serial itu. Hanya menyalin biner struktur ke buffer keluaran tidak portabel: umumnya Anda tidak tahu urutan byte untuk platform, atau penyelarasan anggota struktur, jadi struktur hanya menyimpan data, tetapi tidak menjelaskan cara data harus berseri .

Baik. Anda dapat melakukan transformasi urutan byte dan memindahkan anggota struktur (misalnya uint32_tatau serupa) menggunakan memcpyke buffer. Kenapa memcpy? Karena ada banyak platform yang tidak memungkinkan untuk menulis 32-bit (16-bit, 64-bit - tidak ada perbedaan) ketika alamat target tidak disejajarkan dengan benar.

Jadi, Anda telah melakukan banyak hal untuk mencapai portabilitas.

Dan sekarang pertanyaan terakhir. Kami memiliki penyangga. Data darinya dikirim ke jaringan TCP / IP. Jaringan tersebut mengasumsikan byte 8-bit. Pertanyaannya adalah: dari jenis apa buffer itu seharusnya? Jika karakter Anda 9-bit? Jika 16-bit? 24? Mungkin setiap karakter sesuai dengan satu byte 8-bit yang dikirim ke jaringan, dan hanya 8 bit yang digunakan? Atau mungkin beberapa byte jaringan dikemas menjadi karakter 24/16/9-bit? Itu pertanyaan, dan sulit dipercaya bahwa ada satu jawaban yang cocok untuk semua kasus. Banyak hal bergantung pada implementasi soket untuk platform target.

Jadi, apa yang saya bicarakan. Biasanya kode dapat dengan mudah dibuat portabel sampai batas tertentu . Sangat penting untuk melakukannya jika Anda berharap menggunakan kode pada platform yang berbeda. Namun, meningkatkan portabilitas di luar ukuran itu adalah hal yang membutuhkan banyak usaha dan sering kali memberi sedikit , karena kode sebenarnya hampir selalu bergantung pada kode lain (implementasi soket dalam contoh di atas). Saya yakin bahwa sekitar 90% dari kemampuan kode untuk bekerja pada platform dengan byte selain 8-bit hampir tidak berguna, karena menggunakan lingkungan yang terikat pada 8-bit. Cukup periksa ukuran byte dan lakukan pernyataan waktu kompilasi. Anda hampir pasti harus banyak menulis ulang untuk platform yang sangat tidak biasa.

Tetapi jika kode Anda sangat "mandiri" - mengapa tidak? Anda dapat menuliskannya dengan cara yang memungkinkan ukuran byte yang berbeda.

— Ellioh
sumber
4
Jika seseorang menyimpan satu oktet per unsigned charnilai, seharusnya tidak ada masalah portabilitas kecuali kode menggunakan trik aliasing daripada shift untuk mengonversi urutan oktet ke / dari jenis bilangan bulat yang lebih besar. Secara pribadi, saya pikir standar C harus mendefinisikan intrinsik untuk mengemas / membongkar bilangan bulat dari urutan jenis yang lebih pendek (paling biasanya char) menyimpan jumlah bit yang dijamin tersedia per item (8 per unsigned char, 16 per unsigned short, atau 32 per unsigned long).
— supercat
5

Bahasa pemrograman C dan C ++, misalnya, mendefinisikan byte sebagai "unit data yang dapat dialamatkan cukup besar untuk menampung setiap anggota dari kumpulan karakter dasar lingkungan eksekusi" (klausul 3.6 dari standar C). Karena tipe data integral char C harus berisi setidaknya 8 bit (klausul 5.2.4.2.1), satu byte dalam C setidaknya mampu menampung 256 nilai yang berbeda. Berbagai implementasi C dan C ++ mendefinisikan byte sebagai 8, 9, 16, 32, atau 36 bit

Dikutip dari http://en.wikipedia.org/wiki/Byte#History

Tidak yakin tentang bahasa lain.

http://en.wikipedia.org/wiki/IBM_7030_Stretch#Data_Formats

Mendefinisikan byte pada mesin itu menjadi panjang variabel

— petantik
sumber
1
"Namun, tidak yakin tentang bahasa lain" - secara historis, sebagian besar bahasa mengizinkan arsitektur mesin untuk menentukan ukuran byte-nya sendiri. Sebenarnya secara historis begitu pula C, sampai standar menetapkan batas bawah pada 8.
— Pemrogram Windows
4

Keluarga DEC PDP-8 memiliki kata 12 bit meskipun Anda biasanya menggunakan ASCII 8 bit untuk keluaran (kebanyakan pada Teletype). Namun, ada juga kode karakter 6-BIT yang memungkinkan Anda untuk menyandikan 2 karakter dalam satu kata 12-bit.

— PrgTrdr
sumber
3

Pertama, karakter Unicode lebih panjang dari 8-bit. Seperti yang disebutkan sebelumnya, spesifikasi C mendefinisikan tipe data dengan ukuran minimumnya. Gunakan sizeofdan nilai di limits.hjika Anda ingin menginterogasi tipe data Anda dan menemukan dengan tepat ukurannya untuk konfigurasi dan arsitektur Anda.

Untuk alasan ini, saya mencoba untuk tetap menggunakan tipe data seperti uint16_tketika saya membutuhkan tipe data dengan panjang bit tertentu.

Edit: Maaf, saya awalnya salah membaca pertanyaan Anda.

Spesifikasi C mengatakan bahwa charobjek "cukup besar untuk menyimpan setiap anggota set karakter eksekusi". limits.hmencantumkan ukuran minimum 8 bit, tetapi definisi membiarkan ukuran maksimal charterbuka.

Jadi, a charsetidaknya sepanjang karakter terbesar dari set eksekusi arsitektur Anda (biasanya dibulatkan ke batas 8-bit terdekat). Jika arsitektur Anda memiliki opcode yang lebih panjang, charukuran Anda mungkin lebih panjang.

Secara historis, opcode platform x86 adalah satu byte, jadi charawalnya nilai 8-bit. Platform x86 saat ini mendukung opcode yang lebih panjang dari satu byte, tetapi charpanjangnya tetap 8 bit karena itulah yang dikondisikan oleh programmer (dan volume besar kode x86 yang ada).

Saat memikirkan tentang dukungan multi-platform, manfaatkan jenis yang ditentukan dalam stdint.h. Jika Anda menggunakan (misalnya) uint16_t, maka Anda dapat yakin bahwa nilai ini adalah nilai 16-bit unsigned pada arsitektur apapun, apakah itu nilai 16-bit berkorespondensi dengan char, short, int, atau sesuatu yang lain. Sebagian besar kerja keras telah dilakukan oleh orang-orang yang menulis compiler / library standar Anda.

Jika Anda perlu mengetahui ukuran pasti a charkarena Anda melakukan manipulasi perangkat keras tingkat rendah yang memerlukannya, saya biasanya menggunakan tipe data yang cukup besar untuk menampung chardi semua platform yang didukung (biasanya 16 bit sudah cukup) dan menjalankan nilai melalui convert_to_machine_charrutinitas ketika saya membutuhkan representasi mesin yang tepat. Dengan begitu, kode khusus platform terbatas pada fungsi antarmuka dan sebagian besar waktu saya dapat menggunakan normal uint16_t.

— bta
sumber
2
Pertanyaannya tidak menanyakan tentang karakter (apakah Unicode atau tidak). Ia bertanya tentang char, yang merupakan byte.
— Pemrogram Windows
1
Juga, set karakter eksekusi tidak ada hubungannya dengan opcode, itu adalah set karakter yang digunakan saat eksekusi, pikirkan cross-compiler.
— ninjalj
"Secara historis, opcode platform x86 adalah satu byte": sungguh manis. Secara historis , C dikembangkan pada PDP-11 (1972), jauh sebelum x86 ditemukan (1978).
— Martin Bonner mendukung Monica
3

Pertimbangan seperti apa yang layak diberikan pada platform dengan karakter non-8-bit?

angka ajaib terjadi misalnya saat menggeser;

sebagian besar dapat ditangani dengan mudah dengan menggunakan CHAR_BIT dan misalnya UCHAR_MAX, bukan 8 dan 255 (atau serupa).

semoga penerapan Anda mendefinisikannya :)

itu adalah masalah "umum" .....

masalah tidak langsung lainnya mengatakan Anda memiliki:

struct xyz {
   uchar baz;
   uchar blah;
   uchar buzz; 
}

ini mungkin "hanya" mengambil (kasus terbaik) 24 bit pada satu platform, tetapi mungkin mengambil misalnya 72 bit di tempat lain .....

jika setiap uchar memiliki "bit flags" dan setiap uchar hanya memiliki 2 bit "signifikan" atau flag yang saat ini Anda gunakan, dan Anda hanya mengaturnya menjadi 3 uchar untuk "kejelasan", maka itu mungkin relatif "lebih boros" misalnya pada platform dengan uchars 24-bit .....

tidak ada yang tidak bisa diselesaikan oleh bitfield, tetapi mereka memiliki hal-hal lain yang harus diperhatikan ....

dalam kasus ini, hanya satu enum yang mungkin menjadi cara untuk mendapatkan bilangan bulat berukuran "terkecil" yang sebenarnya Anda butuhkan ....

mungkin bukan contoh nyata, tetapi hal-hal seperti ini "menggigit" saya saat porting / bermain dengan beberapa kode .....

hanya fakta bahwa jika sebuah uchar adalah tiga kali lebih besar dari yang diharapkan "biasanya", 100 struktur seperti itu dapat menghabiskan banyak memori pada beberapa platform ..... di mana "biasanya" itu bukan masalah besar .... .

jadi hal-hal masih bisa "rusak" atau dalam hal ini "membuang banyak memori dengan sangat cepat" karena asumsi bahwa uchar "tidak terlalu boros" di satu platform, relatif terhadap RAM yang tersedia, daripada di platform lain ... ..

masalahnya mungkin lebih menonjol misalnya untuk int juga, atau jenis lain, misalnya Anda memiliki beberapa struktur yang membutuhkan 15 bit, jadi Anda menempelkannya di int, tetapi di beberapa platform lain int adalah 48 bit atau apa pun .... .

"biasanya" Anda dapat membaginya menjadi 2 uchar, tetapi misalnya dengan uchar 24-bit Anda hanya perlu satu .....

jadi enum mungkin menjadi solusi "umum" yang lebih baik ....

tergantung pada bagaimana Anda mengakses bit itu :)

jadi, mungkin ada "kekurangan desain" yang ada di belakang kepala mereka .... meskipun kodenya mungkin masih berfungsi / berjalan dengan baik terlepas dari ukuran uchar atau uint ...

ada hal-hal seperti ini yang harus diperhatikan, meskipun tidak ada "angka ajaib" di kode Anda ...

semoga ini masuk akal :)

— dd ee
sumber
1
...apa? Menurut Anda, mengapa enumcenderung lebih kecil daripada jenis asli lainnya? Apakah Anda sadar ini default ke penyimpanan yang sama seperti int? "Anda memiliki beberapa struktur yang membutuhkan 15 bit, jadi Anda memasukkannya ke dalam int, tetapi di beberapa platform lain int adalah 48 bit atau apa pun ....." - jadi #include <cstdint>dan jadikan itu int16_tkesempatan terbaik untuk meminimalkan penggunaan bit . Saya benar-benar tidak yakin apa yang Anda pikir Anda katakan di antara semua elips itu.
— underscore_d
1

int dulu 16 bit (pdp11, dll.). Pergi ke arsitektur 32 bit itu sulit. Orang-orang menjadi lebih baik: Hampir tidak ada yang menganggap sebuah pointer akan muat lagi (Anda tidak benar?). Atau offset file, atau cap waktu, atau ...

Karakter 8 bit sudah agak dari anakronisme. Kita sudah membutuhkan 32 bit untuk menampung semua set karakter dunia.

— Richard Pennington
sumber
2
Benar. Namanya charagak aneh sekarang di zaman Unicode. Saya lebih peduli tentang unit 8-bit (oktet) saat berurusan dengan data biner, misalnya penyimpanan file, komunikasi jaringan. uint8_tlebih bermanfaat.
— Craig McQueen
3
Unicode sebenarnya tidak pernah membutuhkan 32 bit penuh. Mereka awalnya direncanakan untuk 31 (lihat karya UTF-8 asli), tetapi sekarang mereka hanya konten dengan 21 bit . Mereka mungkin menyadari bahwa mereka tidak akan dapat mencetak buku itu lagi jika mereka benar-benar membutuhkan semua 31 bit: P
— me22
2
@ me22, Unicode awalnya direncanakan untuk 16 bit. "Karakter unicode secara konsisten memiliki lebar 16 bit, apa pun bahasanya ..." Unicode 1.0.0. unicode.org/versions/Unicode1.0.0/ch01.pdf .
— Shannon Severance
1
ISO 10646 awalnya 31 bit, dan Unicode digabungkan dengan ISO 10646, jadi mungkin ceroboh untuk mengatakan bahwa Unicode adalah 31 bit, tetapi itu tidak benar-benar tidak benar. Perhatikan bahwa mereka tidak benar-benar mencetak tabel kode lengkap lagi.
— prosfilaes
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.