Clever Geek Handbook

Bagaimana pengkodean UTF-8 ditemukan: kutipan dari korespondensi pencipta



Semua orang tahu pengkodean UTF-8, yang telah lama mendominasi ruang Internet , dan telah digunakan selama bertahun-tahun. Tampaknya semuanya diketahui tentang dia, dan tidak ada yang menarik untuk diceritakan tentang topik ini. Jika Anda membaca sumber-sumber populer seperti Wikipedia, maka sebenarnya tidak ada yang aneh di sana, kecuali bahwa versi bahasa Inggris secara singkat menyebutkan sebuah cerita aneh tentang bagaimana hal itu "digambar di atas serbet di restoran." 



Faktanya, penemuan pengkodean ini tidak bisa begitu dangkal, jika hanya karena Ken Thompson, orang yang legendaris, memiliki andil dalam pembuatannya. Dia bekerja dengan Dennis Ritchie, salah satu pencipta UNIX, berkontribusi pada pengembangan C (menemukan pendahulunya - B), dan kemudian, saat bekerja di Google, ikut serta dalam pembuatan bahasa Go. 



Sebelum Anda - terjemahan beberapa huruf di mana pengembang mengingat sejarah pembuatan pengkodean. 



Karakter:



ken (at) entrisphere.com - Ken Thompson





Ken Thompson (kiri) dengan Dennis Ritchie



"Rob 'Commander' Pike" - Robert Pike , seorang programmer Kanada yang bekerja pada UTF-8 dengan Ken Thompson







mkuhn (at) acm.org - Markus Kuhn , ilmuwan komputer Jerman







henry (at) spsystems.net - Henry Spurser , penulis salah satu implementasi RegExp







Russ Cox < rsc@plan9.bell-labs.com > - Russ Cox , karyawan Bell Labs yang mengerjakan Plan 9







Greger sistem Leijonhufvud < greger@friherr.com> - Salah satu anggota staf X / Open







Plan 9 - Sistem operasi, yang pertama kali menggunakan pengkodean UTF-8 untuk menyediakan multibahasa.







UTF-8 - Pengkodean karakter Unicode









Korespondensi 2003





Di bawah ini adalah korespondensi antara pencipta pengkodean, Robert dan Ken, yang dimulai oleh Robert Pike, mengeluh bahwa kontribusi mereka terhadap pembuatan UTF-8 tidak dapat dilupakan. Robert meminta salah satu kenalan lamanya untuk mengobrak-abrik arsip server surat dan menemukan bukti partisipasi mereka. (perkiraan per.) 



Subject: UTF-8 history
From: "Rob 'Commander' Pike" <r (at) google.com>
Date: Wed, 30 Apr 2003 22:32:32 -0700 (Thu 06:32 BST)
To: mkuhn (at) acm.org, henry (at) spsystems.net
Cc: ken (at) entrisphere.com




Melihat percakapan tentang asal-usul UTF-8, saya melihat cerita yang sama terus berulang. 



Versi yang salah: 



  1. UTF-8 dikembangkan oleh IBM.
  2. Ini diimplementasikan di Plan 9 (sistem operasi yang dikembangkan oleh Bell Laboratories)


Itu tidak benar. Saya melihat langsung bagaimana UTF-8 ditemukan di atas serbet pada suatu malam di bulan September 1992 di restoran New Jersey. 



Itu terjadi dengan cara ini. Kami menggunakan ISO 10646 UTF asli untuk mendukung karakter 16-bit di Plan 9, yang kami benci, dan siap untuk mengirimkan Plan 9 ketika beberapa orang menelepon saya pada suatu malam, saya pikir mereka dari IBM. Saya ingat bertemu mereka di pertemuan komite X / Open di Austin. Mereka ingin Ken dan saya melihat proyek FSS / UTF mereka. 
(, ..) . Bell Labs , Plan 9 — , , , . , .



Unicode , , , , , .



(. .)
Kami memahami mengapa mereka ingin mengubah desain dan memutuskan bahwa ini adalah kesempatan yang baik untuk menggunakan pengalaman kami untuk mengembangkan standar baru dan mengajak orang-orang di X / Open untuk mempromosikannya. Kami harus memberi tahu mereka tentang hal itu, dan mereka setuju dengan syarat bahwa kami segera menanganinya. 



Kemudian kami pergi untuk makan, dan selama makan malam, Ken memilah-milah paket ketukan, dan ketika kami kembali, mereka memanggil orang-orang dari X / Open dan menjelaskan ide kami kepada mereka. Kami mengirim sketsa kami melalui surat, dan mereka menjawab bahwa itu lebih baik daripada sketsa mereka (tetapi saya ingat persis bahwa mereka tidak menunjukkan kepada kami versinya), dan bertanya kapan kami dapat menerapkannya.
Salah satu opsi untuk membatasi karakter adalah garis miring, tetapi ini dapat membingungkan sistem file, ini dapat menafsirkannya sebagai urutan pelolosan.



(perkiraan per.)
Menurut saya hal itu terjadi pada Rabu malam. Kami berjanji bahwa kami akan meluncurkan sistem pada hari Senin, ketika saya pikir mereka memiliki beberapa pertemuan penting yang dijadwalkan. Malam itu, Ken menulis kode encoder / decoder, dan saya mulai berurusan dengan C dan pustaka grafis. Keesokan harinya kode sudah siap dan kami mulai mengonversi file teks sistem. Pada hari Jumat, Plan 9 sudah aktif dan berjalan pada apa yang disebut UTF-8. 



Dan kemudian ceritanya ditulis ulang sedikit.



Mengapa kami tidak menggunakan FSS / UTF mereka saja? 



Sejauh yang saya ingat, dalam panggilan telepon pertama saya bernyanyi untuk Desiderata persyaratan saya untuk pengkodean, dan FSS / UTF tidak memiliki setidaknya satu hal - kemampuan untuk menyinkronkan aliran byte yang diambil dari tengah aliran menggunakan sesedikit mungkin karakter sebanyak mungkin untuk sinkronisasi (lihat di atas, tentang mendefinisikan batas karakter.



menyanyikannya Desiderat
.



, 1971 , : «Desiderata» , , : «». , « » « ». ( .)





Karena tidak ada solusi di mana pun, kami bebas melakukannya sesuka kami.

Saya pikir "cerita ini ditemukan oleh IBM dan diterapkan di Plan 9" berasal dari dokumentasi RFC 2279. Kami sangat senang ketika UTF-8 berakar sehingga kami tidak menceritakannya kepada siapa pun. 



Tak satu pun dari kami yang bekerja di Bell Labs lagi, tapi saya yakin ada arsip email yang dapat menguatkan cerita kami, dan saya dapat meminta seseorang untuk menggali lebih dalam.



Jadi, semua penghargaan diberikan kepada orang-orang di X / Open dan IBM yang membuatnya mungkin dan mendorong pengkodean, tetapi Ken mengembangkannya, dan saya membantunya dengan itu, tidak peduli apa yang dikatakan buku sejarah. 



-Rampok 



Date: Sat, 07 Jun 2003 18:44:05 -0700
From: "Rob `Commander' Pike" <r@google.com>
To: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>
cc: henry@spsystems.net, ken@entrisphere.com,
Greger Leijonhufvud <greger@friherr.com>
Subject: Re: UTF-8 history




Saya meminta Russ Cox untuk menggali arsip. Saya melampirkan pesannya. Saya pikir Anda akan setuju bahwa ini menegaskan cerita yang saya posting sebelumnya. Email yang kami kirim ke X / Open (saya pikir Ken mengedit dan mengedarkan dokumen ini) menyertakan "desideratum number 6" baru tentang deteksi batas karakter. 



Kami tidak akan tahu lagi apa dampak solusi asli dari X / Open terhadap kami. Meski berbeda, namun mereka memiliki karakteristik yang sama. Saya tidak ingat melihatnya secara detail, itu sudah terlalu lama (di surat terakhir dia mengatakan bahwa X / Open tidak menunjukkan implementasinya kepada mereka. Approx. Lane) . Tapi saya ingat betul bagaimana Ken menulis sketsa di atas serbet dan kemudian berharap kami menyimpannya. 



-Rampok 



From: Russ Cox <rsc@plan9.bell-labs.com>
To: r@google.com
Subject: utf digging
Date-Sent: Saturday, June 07, 2003 7:46 PM -0400


File boot pengguna /sys/src/libc/port/rune.c



diubah oleh divisi-heavy pada 4 September 1992. Versi di dump memiliki waktu 19:51:55. Keesokan harinya sebuah komentar ditambahkan ke dalamnya, tetapi selain itu, komentar tidak berubah hingga 14 November 1996, ketika runelen



dipercepat dengan secara eksplisit memeriksa nilai rune



alih-alih menggunakan nilai yang dikembalikan runetochar



. Perubahan terakhir pada 26 Mei 2001 saat ditambahkan runenlen



. (Rune adalah struktur yang berisi nilai Unicode. Runelen dan runetochar adalah fungsi yang bekerja dengan tipe data ini. Approx. Trans.)



Ada beberapa huruf dari kotak surat Anda yang dihasilkan dengan grapping garis utf. 



Yang pertama adalah tentang file utf.c



yang merupakan salinan wctomb



dan mbtowc



(fungsi konversi karakter. Approx. Per.) Yang menangani pengodean UTF-8 6-byte penuh, 32-bit runes.



Dengan logika kontrol aliran, tampilannya cukup jelek. Saya kira kode ini berasal dari email pertama itu. 



Dalam /usr/ken/utf/xutf



saya menemukan salinan apa yang tampaknya menjadi sumber bahwa metode encoding non-self-sinkronisasi, dengan UTF-8 skema ditambahkan ke akhir email (dimulai dengan "Kami mendefinisikan 7 jenis byte



"). 



Versi surat di bawah ini, tertanggal 2 September 11:44:10, adalah yang pertama. Setelah beberapa kali pengeditan, pada pagi hari tanggal 8 September, versi kedua keluar. Log server email menunjukkan bagaimana versi kedua surat itu dikirim dan, setelah beberapa saat, kembali ke Ken: 



helix: Sep  8 03:22:13: ken: upas/sendmail: remote inet!xopen.co.uk!xojig
>From ken Tue Sep  8 03:22:07 EDT 1992 (xojig@xopen.co.uk) 6833
helix: Sep  8 03:22:13: ken: upas/sendmail: delivered rob From ken Tue Sep 8 03:22:07 EDT 1992 6833
helix: Sep  8 03:22:16: ken: upas/sendmail: remote pyxis!andrew From ken Tue Sep  8 03:22:07 EDT 1992 (andrew) 6833
helix: Sep  8 03:22:19: ken: upas/sendmail: remote coma!dmr From ken Tue Sep  8 03:22:07 EDT 1992 (dmr) 6833
helix: Sep  8 03:25:52: ken: upas/sendmail: delivered rob From ken Tue Sep 8 03:24:58 EDT 1992 141
helix: Sep  8 03:36:13: ken: upas/sendmail: delivered ken From ken Tue Sep 8 03:36:12 EDT 1992 6833


Semoga berhasil.



File dari arsip surat



Berikutnya adalah file dengan korespondensi dari dump server email, yang dilampirkan oleh Russ Cox, sebagai tanggapan atas permintaan Robert untuk menyelidiki sejarah. Ini adalah "versi pertama". (perkiraan) 



>From ken Fri Sep  4 03:37:39 EDT 1992


Berikut saran kami untuk memodifikasi FSS-UTF. Ini tentang hal yang sama seperti yang sebelumnya. Saya minta maaf kepada penulis. 



Kode telah diuji sampai batas tertentu dan harus dalam kondisi yang cukup baik. Kami mendesain ulang kode Plan 9 untuk menggunakan pengkodean ini, dan kami akan merilis distribusi dan memilih pengguna universitas untuk pengujian awal. 



Format Transformasi Kumpulan Karakter Universal Aman Sistem File (FSS-UTF)



Dengan ISO / IEC 10646 (Unicode) yang ditetapkan sebagai standar internasional dan harapan adopsi yang luas dari Set Karakter Berkode Universal (UCS) ini, sistem operasi yang secara historis berdasarkan ASCII perlu mengembangkan cara untuk mewakili dan menangani sejumlah besar karakter yang dapat menyandikan dengan standar baru. UCS memiliki beberapa masalah yang perlu dipecahkan dalam sistem operasi yang didirikan secara historis dan lingkungan untuk pemrograman di C. 



(Teks di bawah ini menyebutkan "sistem operasi historis" beberapa kali. Rupanya dalam konteks "secara historis bekerja dengan pengkodean ASCII." menghilangkan julukan ini, atau menggantinya dengan jalur yang "ada", dll.)



Masalah terbesar adalah skema pengkodean yang digunakan di UCS. Yakni, integrasi standar UCS dengan bahasa pemrograman, sistem operasi, dan utilitas yang ada. Masalah dalam bahasa pemrograman dan sistem operasi sedang ditangani di seluruh industri, namun kami masih dihadapkan pada penanganan UCS oleh sistem operasi dan utilitas. 



Di antara masalah yang terkait dengan penanganan UCS dalam sistem operasi, yang utama adalah penyajian data di dalam sistem file. Konsep dasarnya adalah untuk mendukung sistem operasi yang telah ada di mana investasi telah dilakukan dan pada saat yang sama memanfaatkan sejumlah besar karakter yang disediakan oleh UCS. 



UCS memungkinkan untuk menyandikan teks multibahasa menggunakan satu set karakter. Tapi UCS dan UTF tidak melindungi byte nol (akhir baris dalam beberapa bahasa. Approx. Per.) Dan / atau garis miring di ASCII /, yang membuat pengkodean tidak kompatibel dengan Unix. Proposal berikut menyediakan format transformasi UCS yang kompatibel dengan Unix, sehingga sistem Unix dapat mendukung teks multibahasa dalam satu encoding.



Format konversi pengkodean ini dimaksudkan untuk pengkodean file sebagai langkah perantara menuju dukungan UCS penuh. Namun, karena hampir semua implementasi Unis menghadapi masalah dukungan UCS yang sama, proposal ini dimaksudkan untuk menyediakan kompatibilitas encoding umum pada tahap ini.



Maksud / Tujuan



Berdasarkan asumsi, kami mendapatkan bahwa jika hampir semua masalah pemrosesan dan penyimpanan UCS di sistem file OS diketahui, maka kami perlu menggunakan format konversi UCS yang akan berfungsi tanpa melanggar struktur sistem operasi. Tujuannya agar proses konversi format dapat digunakan untuk menyandikan file.



Kriteria format konversi



Berikut ini adalah pedoman yang harus diikuti saat menentukan format konversi UCS:



  1. Kompatibilitas dengan sistem file yang ada.

    Dilarang menggunakan byte nol dan karakter garis miring sebagai bagian dari nama file. 
  2. .

    ASCII. UCS, ASCII, ASCII.
  3. UCS .
  4. .
  5. , , .
  6. , (. ..).


FSS-UTF



Format transformasi UCS yang diusulkan mengkodekan nilai UCS dalam suatu rentang [0,0x7fffffff]



menggunakan beberapa byte per karakter dan panjang 1, 2, 3, 4, 5, dan 6 byte. Dalam semua kasus pengkodean dengan lebih dari satu byte, byte utama menentukan jumlah byte yang digunakan, dengan bit paling signifikan yang ditetapkan di setiap byte. Setiap byte yang tidak dimulai dengan 10XXXXXX adalah awal dari urutan karakter UCS.



Cara mudah untuk mengingat formatnya: jumlah yang tinggi di byte pertama berarti jumlah byte dalam karakter multibyte. 



Bits    Hex Min  Hex Max  Byte Sequence in Binary
1    7  00000000 0000007f 0vvvvvvv
2   11  00000080 000007FF 110vvvvv 10vvvvvv
3   16  00000800 0000FFFF 1110vvvv 10vvvvvv 10vvvvvv
4   21  00010000 001FFFFF 11110vvv 10vvvvvv 10vvvvvv 10vvvvvv
5   26  00200000 03FFFFFF 111110vv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
6   31  04000000 7FFFFFFF 1111110v 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv


Nilai karakter UCD yang dikodekan multibyte adalah rangkaian v-bit. Jika beberapa metode pengkodean dimungkinkan, misalnya UCS 0, maka yang terpendek dianggap dapat diterima.



Di bawah ini adalah contoh implementasi fungsi C standar wcstombs()



dan mbstowcs()



yang mendemonstrasikan algoritme untuk mengubah dari UCS ke format konversi dan mengubah dari format konversi ke UCS. Contoh implementasi mencakup pemeriksaan kesalahan, beberapa di antaranya mungkin tidak diperlukan untuk konsistensi: 



typedef

struct
{
    int   cmask;
    int   cval;
    int   shift;
    long  lmask;
    long  lval;
} Tab;

static
Tab       tab[] =
{
    0x80, 0x00,  0*6,   0x7F,         0,            /* 1 byte sequence */
    0xE0, 0xC0,  1*6,   0x7FF,        0x80,         /* 2 byte sequence */
    0xF0, 0xE0,  2*6,   0xFFFF,              0x800,        /* 3 byte sequence */
    0xF8, 0xF0,  3*6,   0x1FFFFF,     0x10000,      /* 4 byte sequence */
    0xFC, 0xF8,  4*6,   0x3FFFFFF,    0x200000,     /* 5 byte sequence */
    0xFE, 0xFC,  5*6,   0x7FFFFFFF,   0x4000000,    /* 6 byte sequence */
    0,                                              /* end of table */
};

int
mbtowc(wchar_t *p, char *s, size_t n)
{
    long l;
    int c0, c, nc;
    Tab *t;

    if(s == 0)
        return 0;

    nc = 0;
    if(n <= nc)
        return -1;
    c0 = *s & 0xff;
    l = c0;
    for(t=tab; t->cmask; t++) {
        nc++;
        if((c0 & t->cmask) == t->cval) {
            l &= t->lmask;
            if(l < t->lval)
                return -1;
            *p = l;
            return nc;
        }
        if(n <= nc)
            return -1;
        s++;
        c = (*s ^ 0x80) & 0xFF;
        if(c & 0xC0)
            return -1;
        l = (l<<6) | c;
    }
    return -1;
}

int
wctomb(char *s, wchar_t wc)
{
    long l;
    int c, nc;
    Tab *t;

    if(s == 0)
        return 0;

    l = wc;
    nc = 0;
    for(t=tab; t->cmask; t++) {
        nc++;
        if(l <= t->lmask) {
            c = t->shift;
            *s = t->cval | (l>>c);
            while(c > 0) {
                c -= 6;
                s++;
                *s = 0x80 | ((l>>c) & 0x3F);
            }
            return nc;
        }
    }
    return -1;
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    


>From ken Tue Sep  8 03:24:58 EDT 1992


Saya mengirimkannya melalui pos, tetapi surat itu masuk ke lubang hitam, jadi saya tidak menerima salinan saya. Alamat internet ini pasti sedang koma.



Versi kedua surat itu, dengan revisi



Kemudian salinan surat itu dilampirkan, yang dijelaskan di atas sebagai: "Setelah beberapa kali koreksi, pada pagi hari tanggal 8 September, versi kedua keluar." Bagian yang berulang disembunyikan di bawah spoiler. (perkiraan terjemahan) 



>From ken Tue Sep  8 03:42:43 EDT 1992


Saya akhirnya mendapatkan salinan saya. 



--- /usr/ken/utf/xutf from dump of Sep 2 1992 ---


Teks tersembunyi

File System Safe Universal Character Set Transformation Format (FSS-UTF)



ISO/IEC 10646 (Unicode) (UCS), , ASCII, , . UCS , C. 



, UCS. UCS , . , UCS . 



, UCS , . , , , , UCS. 



UCS . UCS UTF ( . . .) / ASCII /, Unix. UCS, Unix, , , Unix- .



, UCS. , Unis UCS, .



/



, UCS ,   UCS, . , .





  , , UCS:



  1. .

    . 
  2. .

    ASCII. UCS, ASCII, ASCII.
  3. UCS .
  4. .
  5. , , .
  6. , (. ..).


FSS-UTF



UCS UCS [0,0x7fffffff]



1, 2, 3, 4, 5, 6 . , . , 10XXXXXX, UCS.



: . 



Bits    Hex Min  Hex Max  Byte Sequence in Binary
1    7  00000000 0000007f 0vvvvvvv
2   11  00000080 000007FF 110vvvvv 10vvvvvv
3   16  00000800 0000FFFF 1110vvvv 10vvvvvv 10vvvvvv
4   21  00010000 001FFFFF 11110vvv 10vvvvvv 10vvvvvv 10vvvvvv
5   26  00200000 03FFFFFF 111110vv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
6   31  04000000 7FFFFFFF 1111110v 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv


UCD — v-. , UCS 0, .



C wcstombs()



mbstowcs()



, UCS UCS. , : 



typedef

struct
{
    int   cmask;
    int   cval;
    int   shift;
    long  lmask;
    long  lval;
} Tab;

static
Tab       tab[] =
{
    0x80, 0x00,  0*6,   0x7F,         0,            /* 1 byte sequence */
    0xE0, 0xC0,  1*6,   0x7FF,        0x80,         /* 2 byte sequence */
    0xF0, 0xE0,  2*6,   0xFFFF,              0x800,        /* 3 byte sequence */
    0xF8, 0xF0,  3*6,   0x1FFFFF,     0x10000,      /* 4 byte sequence */
    0xFC, 0xF8,  4*6,   0x3FFFFFF,    0x200000,     /* 5 byte sequence */
    0xFE, 0xFC,  5*6,   0x7FFFFFFF,   0x4000000,    /* 6 byte sequence */
    0,                                              /* end of table */
};

int
mbtowc(wchar_t *p, char *s, size_t n)
{
    long l;
    int c0, c, nc;
    Tab *t;

    if(s == 0)
        return 0;

    nc = 0;
    if(n <= nc)
        return -1;
    c0 = *s & 0xff;
    l = c0;
    for(t=tab; t->cmask; t++) {
        nc++;
        if((c0 & t->cmask) == t->cval) {
            l &= t->lmask;
            if(l < t->lval)
                return -1;
            *p = l;
            return nc;
        }
        if(n <= nc)
            return -1;
        s++;
        c = (*s ^ 0x80) & 0xFF;
        if(c & 0xC0)
            return -1;
        l = (l<<6) | c;
    }
    return -1;
}

int
wctomb(char *s, wchar_t wc)
{
    long l;
    int c, nc;
    Tab *t;

    if(s == 0)
        return 0;

    l = wc;
    nc = 0;
    for(t=tab; t->cmask; t++) {
        nc++;
        if(l <= t->lmask) {
            c = t->shift;
            *s = t->cval | (l>>c);
            while(c > 0) {
                c -= 6;
                s++;
                *s = 0x80 | ((l>>c) & 0x3F);
            }
            return nc;
        }
    }
    return -1;
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    


int mbtowc(wchar_t *p, const char *s, size_t n)
{
       unsigned char *uc;      /* so that all bytes are nonnegative */

       if ((uc = (unsigned char *)s) == 0)
           return 0;               /* no shift states */
       if (n == 0)
           return -1;
       if ((*p = uc[0]) < 0x80)
           return uc[0] != '\0';   /* return 0 for '\0', else 1 */
       if (uc[0] < 0xc0)
       {
           if (n < 2)
               return -1;
           if (uc[1] < 0x80)
               goto bad;
           *p &= 0x3f;
           *p <<= 7;
           *p |= uc[1] & 0x7f;
           *p += OFF1;
           return 2;
       }
       if (uc[0] < 0xe0)
       {
           if (n < 3)
               return -1;
           if (uc[1] < 0x80 || uc[2] < 0x80)
               goto bad;
           *p &= 0x1f;
           *p <<= 14;
           *p |= (uc[1] & 0x7f) << 7;
           *p |= uc[2] & 0x7f;
           *p += OFF2;
           return 3;
       }
       if (uc[0] < 0xf0)
       {
           if (n < 4)
               return -1;
           if (uc[1] < 0x80 || uc[2] < 0x80 || uc[3] < 0x80)
               goto bad;
           *p &= 0x0f;
           *p <<= 21;
           *p |= (uc[1] & 0x7f) << 14;
           *p |= (uc[2] & 0x7f) << 7;
           *p |= uc[3] & 0x7f;
           *p += OFF3;
           return 4;
       }
       if (uc[0] < 0xf8)
       {
           if (n < 5)
               return -1;
           if (uc[1] < 0x80 || uc[2] < 0x80 || uc[3] < 0x80 || uc[4] < 0x80)
               goto bad;
           *p &= 0x07;
           *p <<= 28;
           *p |= (uc[1] & 0x7f) << 21;
           *p |= (uc[2] & 0x7f) << 14;
           *p |= (uc[3] & 0x7f) << 7;
           *p |= uc[4] & 0x7f;
           if (((*p += OFF4) & ~(wchar_t)0x7fffffff) == 0)
               return 5;
       }
bad:;
       errno = EILSEQ;
       return -1;
}


Kami mendefinisikan 7 jenis byte: 



T0 0xxxxxxx      7 free bits
Tx 10xxxxxx      6 free bits
T1 110xxxxx      5 free bits
T2 1110xxxx      4 free bits
T3 11110xxx      3 free bits
T4 111110xx      2 free bits
T5 111111xx      2 free bits


Pengkodeannya terlihat seperti ini: 



>From hex Thru hex      Sequence             Bits
00000000  0000007f      T0                   7
00000080  000007FF      T1 Tx                11
00000800  0000FFFF      T2 Tx Tx             16
00010000  001FFFFF      T3 Tx Tx Tx          21
00200000  03FFFFFF      T4 Tx Tx Tx Tx       26
04000000  FFFFFFFF      T5 Tx Tx Tx Tx Tx    32


Beberapa catatan:



  1. Dua byte dapat menyandikan kekuatan 2 ^ 11 karakter, tetapi hanya 2 ^ 11-2 ^ 7 yang akan digunakan. Kode dalam kisaran 0-7F akan dianggap tidak valid. Saya pikir ini lebih baik daripada menambahkan sekumpulan konstanta "ajaib" tanpa manfaat nyata. Pernyataan ini berlaku untuk semua urutan yang lebih panjang.
  2. Urutan 4, 5, dan 6 byte ada hanya untuk alasan politik. Saya lebih suka menghapusnya.
  3. Urutan 6 byte mencakup 32 bit, proposal FSS-UTF hanya mencakup 31.
  4. Semua urutan disinkronkan ke byte mana pun yang tidak Tx.





***



Korespondensi singkat ini menempatkan segalanya pada tempatnya. Meskipun "serbet legendaris" itu tidak bertahan, ada cukup banyak ekstrak dari arsip server email agar komunitas dapat mengenali manfaatnya. Wikipedia menambahkan nama Ken dan Robert dan fakta menarik tentang serbet di restoran, dan di Internet cerita ini diedarkan dan didiskusikan "sebagaimana adanya", dalam bentuk teks sederhana yang berisi beberapa huruf dan sebagian dari dump dari server email. 



Sistem operasi Plan 9 telah lama dilupakan, tidak ada yang ingat untuk apa itu ditulis dan mengapa itu "nomor sembilan", dan UTF-8, hampir tiga puluh tahun kemudian, masih relevan dan tidak akan pensiun.



Tampaknya ini hanya penyandian, tetapi bahkan cerita yang sederhana pun dapat menghibur jika Anda mendalami sedikit. Pada awal perkembangan teknologi, tidak mungkin untuk memprediksi apa yang akan terjadi dalam sejarah, dan apa yang akan dilupakan.



Sumber arsip





More articles:


All Articles