Hari ini kita akan berbicara tentang dari mana kode jelek itu berasal di situs web dan program, pengkodean teks apa yang ada dan mana yang harus digunakan. Mari kita lihat lebih dekat sejarah perkembangannya, dimulai dengan ASCII dasar, serta versi lanjutannya CP866, KOI8-R, Windows 1251 dan diakhiri dengan konsorsium Unicode modern yang mengkode UTF 16 dan 8. Daftar isi:
Bagi sebagian orang, informasi ini mungkin tampak tidak perlu, tetapi tahukah Anda berapa banyak pertanyaan yang saya terima khususnya mengenai krakozyabr perayapan (kumpulan karakter yang tidak dapat dibaca). Sekarang saya memiliki kesempatan untuk merujuk semua orang ke teks artikel ini dan menemukan kesalahan saya sendiri. Nah, siap-siap menyerap informasinya dan coba ikuti alur ceritanya.
ASCII - pengkodean teks dasar untuk alfabet Latin
Perkembangan pengkodean teks terjadi bersamaan dengan terbentuknya industri TI, dan selama ini berhasil mengalami banyak perubahan. Secara historis, semuanya dimulai dengan EBCDIC, yang pengucapannya agak disonan dalam bahasa Rusia, yang memungkinkan untuk mengkodekan huruf-huruf alfabet Latin, angka Arab, dan tanda baca dengan karakter kontrol. Namun tetap saja, titik awal untuk pengembangan pengkodean teks modern harus dianggap sebagai ASCII (American Standard Code for Information Interchange, yang dalam bahasa Rusia biasanya diucapkan sebagai "ask"). Ini menjelaskan 128 karakter pertama yang paling umum digunakan oleh pengguna berbahasa Inggris - huruf Latin, angka Arab, dan tanda baca. 128 karakter yang dijelaskan dalam ASCII ini juga menyertakan beberapa karakter layanan seperti tanda kurung, tanda pagar, tanda bintang, dll. Faktanya, Anda dapat melihatnya sendiri: 128 karakter dari versi asli ASCII inilah yang menjadi standar, dan dalam pengkodean lainnya Anda pasti akan menemukannya dan karakter tersebut akan muncul dalam urutan ini. Tetapi faktanya adalah dengan bantuan satu byte informasi Anda tidak dapat menyandikan 128, tetapi sebanyak 256 nilai yang berbeda (dua pangkat delapan sama dengan 256), oleh karena itu, setelah versi dasar Asuka, keseluruhan serangkaian pengkodean ASCII yang diperluas muncul , yang memungkinkan, selain 128 karakter dasar, juga dapat dikodekan menggunakan karakter pengkodean nasional (misalnya, Rusia). Di sini, mungkin ada baiknya menjelaskan lebih banyak tentang sistem bilangan yang digunakan dalam deskripsi. Pertama, seperti yang anda ketahui bersama, komputer hanya bekerja dengan bilangan-bilangan dalam sistem biner, yaitu dengan nol dan satu (“Aljabar Boolean”, kalau ada yang mengambilnya di institut atau sekolah). Satu byte terdiri dari delapan bit, yang masing-masing mewakili dua pangkat dua, dimulai dari nol, dan hingga dua hingga ketujuh: Tidak sulit untuk memahami bahwa semua kemungkinan kombinasi nol dan satu dalam konstruksi seperti itu dapat hanya menjadi 256. Mengubah bilangan dari sistem biner ke desimal cukup sederhana. Anda hanya perlu menjumlahkan semua pangkat dua dengan pangkat di atasnya. Dalam contoh kita, hasilnya adalah 1 (2 pangkat nol) ditambah 8 (dua pangkat 3), ditambah 32 (dua pangkat lima), ditambah 64 (pangkat keenam), ditambah 128 (pangkat ketujuh). Jumlahnya adalah 233 dalam notasi desimal. Seperti yang Anda lihat, semuanya sangat sederhana. Namun jika Anda melihat lebih dekat pada tabel dengan karakter ASCII, Anda akan melihat bahwa karakter tersebut direpresentasikan dalam pengkodean heksadesimal. Misalnya, "tanda bintang" sama dengan angka heksadesimal 2A di Aski. Anda mungkin tahu bahwa dalam sistem bilangan heksadesimal, selain angka arab, juga digunakan huruf latin dari A (berarti sepuluh) sampai F (berarti lima belas). Nah, untuk mengubah bilangan biner menjadi heksadesimalgunakan metode sederhana berikut. Setiap byte informasi dibagi menjadi dua bagian yang terdiri dari empat bit. Itu. Dalam setiap setengah byte, hanya enam belas nilai (dua pangkat empat) yang dapat dikodekan dalam biner, yang dapat dengan mudah direpresentasikan sebagai bilangan heksadesimal. Selain itu, di bagian kiri byte, derajat perlu dihitung lagi mulai dari nol, dan tidak seperti yang ditunjukkan pada tangkapan layar. Hasilnya, kami mendapatkan nomor E9 yang dikodekan di tangkapan layar. Saya harap alur pemikiran saya dan solusi atas teka-teki ini jelas bagi Anda. Nah, sekarang mari kita lanjutkan berbicara tentang pengkodean teks.
Versi lanjutan dari pengkodean Asuka - CP866 dan KOI8-R dengan pseudografik
Jadi, kami mulai berbicara tentang ASCII, yang seolah-olah merupakan titik awal pengembangan semua pengkodean modern (Windows 1251, Unicode, UTF 8). Awalnya, hanya berisi 128 karakter alfabet Latin, angka Arab, dan lainnya, tetapi dalam versi yang diperluas, menjadi mungkin untuk menggunakan semua 256 nilai yang dapat dikodekan dalam satu byte informasi. Itu. Menjadi mungkin untuk menambahkan simbol huruf bahasa Anda ke Aski. Di sini kita perlu menyimpang sekali lagi untuk menjelaskan mengapa pengkodean teks diperlukan dan mengapa itu sangat penting. Karakter di layar komputer Anda dibentuk berdasarkan dua hal - kumpulan bentuk vektor (representasi) dari berbagai karakter (ada dalam file dengan font yang diinstal di komputer Anda) dan kode yang memungkinkan Anda mengeluarkan karakter tersebut dengan tepat. dari kumpulan bentuk vektor (file font) simbol yang perlu disisipkan di tempat yang tepat. Jelas bahwa font itu sendiri bertanggung jawab atas bentuk vektor, tetapi sistem operasi dan program yang digunakan di dalamnya bertanggung jawab atas pengkodeannya. Itu. teks apa pun di komputer Anda akan berupa sekumpulan byte, yang masing-masing mengkodekan satu karakter dari teks ini. Program yang menampilkan teks ini di layar (editor teks, browser, dll.), saat mengurai kode, membaca pengkodean karakter berikutnya dan mencari bentuk vektor yang sesuai dalam file font yang diperlukan, yang terhubung untuk menampilkan ini dokumen teks. Semuanya sederhana dan dangkal. Artinya, untuk mengkodekan karakter apa pun yang kita perlukan (misalnya, dari alfabet nasional), dua kondisi harus dipenuhi: bentuk vektor karakter ini harus dalam font yang digunakan, dan karakter ini dapat dikodekan dalam pengkodean ASCII yang diperluas dalam satu byte. Oleh karena itu, ada banyak sekali pilihan seperti itu. Hanya untuk pengkodean karakter bahasa Rusia, ada beberapa jenis Aska yang diperluas. Misalnya, CP866 awalnya muncul , yang memiliki kemampuan untuk menggunakan karakter dari alfabet Rusia, dan merupakan versi ASCII yang diperluas. Artinya, bagian atasnya sepenuhnya bertepatan dengan versi dasar Aska (128 karakter Latin, angka, dan omong kosong lainnya), yang disajikan pada tangkapan layar tepat di atas, tetapi bagian bawah tabel dengan pengkodean CP866 memiliki tampilan seperti yang ditunjukkan dalam tangkapan layar tepat di bawah dan diizinkan menyandikan 128 karakter lainnya (huruf Rusia dan segala jenis grafik semu): Soalnya, di kolom kanan angkanya dimulai dengan 8, karena angka dari 0 hingga 7 mengacu pada bagian dasar ASCII (lihat tangkapan layar pertama). Jadi, huruf Sirilik “M” di CP866 akan memiliki kode 9C (terletak di perpotongan garis yang sesuai dengan 9 dan kolom dengan angka C dalam sistem bilangan heksadesimal), yang dapat ditulis dalam satu byte informasi , dan jika ada font yang cocok dengan karakter Rusia, surat ini akan muncul di teks tanpa masalah. Dari mana asal jumlah tersebut?pseudografik di CP866 ? Intinya adalah bahwa pengkodean untuk teks Rusia ini dikembangkan pada tahun-tahun sulit ketika sistem operasi grafis tidak tersebar luas seperti sekarang. Dan di Dosa dan sistem operasi teks serupa, pseudografik memungkinkan setidaknya untuk mendiversifikasi desain teks, dan oleh karena itu CP866 dan semua rekan lainnya dari kategori versi Asuka yang diperluas berlimpah di dalamnya. CP866 didistribusikan oleh IBM, tetapi selain itu, sejumlah pengkodean dikembangkan untuk karakter bahasa Rusia, misalnya, KOI8-R dapat dikaitkan dengan tipe yang sama (ASCII yang diperluas) : Prinsip operasinya tetap sama seperti seperti yang dijelaskan pada CP866 sebelumnya - Setiap karakter teks dikodekan sebagai satu byte. Tangkapan layar menunjukkan paruh kedua tabel KOI8-R, karena babak pertama sepenuhnya konsisten dengan dasar Asuka, yang ditunjukkan pada tangkapan layar pertama artikel ini. Di antara fitur pengkodean KOI8-R, dapat dicatat bahwa huruf Sirilik dalam tabelnya tidak disusun menurut abjad, seperti yang dilakukan pada CP866. Jika Anda melihat tangkapan layar pertama (bagian dasar, yang disertakan dalam semua pengkodean yang diperluas), Anda akan melihat bahwa di KOI8-R huruf Rusia terletak di sel tabel yang sama dengan huruf alfabet Latin yang sesuai. dari bagian pertama tabel. Hal ini dilakukan untuk kenyamanan peralihan dari karakter Rusia ke Latin dengan membuang satu bit saja (dua pangkat tujuh atau 128).
Windows 1251 - versi modern ASCII dan mengapa retakan muncul
Perkembangan lebih lanjut dari pengkodean teks disebabkan oleh fakta bahwa sistem operasi grafis semakin populer dan kebutuhan untuk menggunakan pseudografik di dalamnya menghilang seiring waktu. Akibatnya, muncullah seluruh kelompok yang, pada dasarnya, masih merupakan versi Asuka yang diperluas (satu karakter teks dikodekan hanya dengan satu byte informasi), tetapi tanpa menggunakan simbol pseudografis. Mereka termasuk dalam apa yang disebut pengkodean ANSI, yang dikembangkan oleh American Standards Institute. Dalam bahasa umum, nama Cyrillic juga digunakan untuk versi dengan dukungan bahasa Rusia. Contohnya adalah Windows 1251 . Ini sangat berbeda dari CP866 dan KOI8-R yang digunakan sebelumnya karena tempat simbol pseudografik di dalamnya digantikan oleh simbol tipografi Rusia yang hilang (kecuali untuk tanda aksen), serta simbol yang digunakan dalam bahasa Slavia yang dekat dengan Rusia (Ukraina, Belarusia, dll.) : Karena banyaknya pengkodean bahasa Rusia, produsen font dan produsen perangkat lunak terus-menerus mengalami sakit kepala, dan Anda dan saya, para pembaca yang budiman, sering mendapat masalah dengan bug terkenal yang sama ketika ada kebingungan dengan versi yang digunakan dalam teks. Sangat sering mereka keluar ketika mengirim dan menerima pesan melalui email, yang memerlukan pembuatan tabel konversi yang sangat kompleks, yang, pada kenyataannya, tidak dapat menyelesaikan masalah ini secara mendasar, dan seringkali pengguna menggunakan transliterasi huruf Latin untuk korespondensi untuk hindari omong kosong yang terkenal saat menggunakan penyandian bahasa Rusia seperti CP866, KOI8-R, atau Windows 1251. Faktanya, retakan yang muncul alih-alih teks Rusia adalah akibat dari kesalahan penggunaan penyandian bahasa tertentu, yang tidak sesuai dengan yang ada di di mana pesan teks awalnya dikodekan. Katakanlah jika Anda mencoba menampilkan karakter yang dikodekan menggunakan CP866 menggunakan tabel kode Windows 1251, maka omong kosong yang sama (kumpulan karakter yang tidak berarti) akan keluar, sepenuhnya menggantikan teks pesan. Situasi serupa sangat sering muncul saat membuat dan menyiapkan situs web, forum, atau blog, ketika teks dengan karakter Rusia salah disimpan dalam pengkodean yang salah yang digunakan di situs secara default, atau di editor teks yang salah, yang menambahkan lelucon yang tidak terlihat. ke kode dengan mata telanjang. Pada akhirnya, banyak orang bosan dengan situasi ini dengan banyak pengkodean dan omong kosong yang terus-menerus, dan prasyarat muncul untuk penciptaan variasi universal baru yang akan menggantikan semua yang sudah ada dan menyelesaikan masalah dengan munculnya teks yang tidak dapat dibaca. . Selain itu, ada masalah bahasa seperti Cina, dimana karakter bahasanya jauh lebih banyak dari 256.
Unicode - pengkodean universal UTF 8, 16 dan 32
Ribuan karakter kelompok bahasa Asia Tenggara ini tidak mungkin dijelaskan dalam satu byte informasi yang dialokasikan untuk pengkodean karakter dalam versi ASCII yang diperluas. Hasilnya, sebuah konsorsium bernama Unicode (Unicode Consortium) dibentuk dengan kerja sama dari banyak pemimpin industri TI (mereka yang memproduksi perangkat lunak, yang menyandikan perangkat keras, yang membuat font) yang tertarik dengan munculnya pengkodean teks universal. Variasi pertama yang dirilis di bawah naungan Unicode Consortium adalah UTF 32 . Angka pada nama pengkodean berarti jumlah bit yang digunakan untuk mengkodekan satu karakter. 32 bit sama dengan 4 byte informasi yang diperlukan untuk menyandikan satu karakter dalam pengkodean UTF universal yang baru. Akibatnya, file yang sama dengan teks yang dikodekan dalam versi ASCII yang diperluas dan UTF-32, dalam kasus terakhir, akan memiliki ukuran (berat) empat kali lebih besar. Ini buruk, tetapi sekarang kita memiliki kesempatan untuk menyandikan menggunakan UTF sejumlah karakter yang sama dengan dua pangkat tiga puluh detik ( miliaran karakter yang akan mencakup nilai apa pun yang benar-benar diperlukan dengan margin yang sangat besar). Tetapi banyak negara dengan bahasa kelompok Eropa tidak perlu menggunakan karakter dalam jumlah besar dalam pengkodean sama sekali, namun, ketika menggunakan UTF-32, mereka tanpa alasan menerima peningkatan empat kali lipat dalam bobot dokumen teks, dan sebagai hasilnya, peningkatan volume lalu lintas Internet dan volume data yang disimpan. Jumlahnya banyak, dan tidak ada seorang pun yang mampu membeli sampah sebanyak itu. Sebagai hasil dari pengembangan Unicode, muncul UTF-16 , yang ternyata sangat sukses sehingga diadopsi secara default sebagai ruang dasar untuk semua karakter yang kami gunakan. Ia menggunakan dua byte untuk mengkodekan satu karakter. Mari kita lihat bagaimana tampilannya. Di sistem operasi Windows, Anda dapat mengikuti jalur "Mulai" - "Program" - "Aksesori" - "Alat Sistem" - "Tabel Karakter". Hasilnya, sebuah tabel akan terbuka dengan bentuk vektor dari semua font yang diinstal pada sistem Anda. Jika Anda memilih kumpulan karakter Unicode di "Opsi lanjutan", Anda akan dapat melihat untuk setiap font secara terpisah seluruh rentang karakter yang disertakan di dalamnya. Omong-omong, dengan mengklik salah satunya, Anda dapat melihat kode dua byte dalam format UTF-16 , yang terdiri dari empat digit heksadesimal: Berapa banyak karakter yang dapat dikodekan dalam UTF-16 menggunakan 16 bit? 65.536 (dua pangkat enam belas), dan ini adalah angka yang diadopsi sebagai spasi dasar di Unicode. Selain itu, ada cara untuk mengkodekan sekitar dua juta karakter dengan menggunakannya, tetapi cara tersebut dibatasi pada ruang yang diperluas sebanyak satu juta karakter teks. Tetapi bahkan versi pengkodean Unicode yang sukses ini tidak memberikan banyak kepuasan bagi mereka yang menulis, katakanlah, program hanya dalam bahasa Inggris, karena setelah transisi dari versi ASCII yang diperluas ke UTF-16, bobot dokumen menjadi dua kali lipat (satu byte per karakter di Aski dan dua byte untuk karakter yang sama di YUTF-16). Justru untuk memuaskan semua orang dan semua yang ada di konsorsium Unicode maka diputuskan untuk membuat pengkodean panjang variabel . Itu disebut UTF-8. Meskipun namanya delapan, sebenarnya ia memiliki panjang yang bervariasi, yaitu. Setiap karakter teks dapat dikodekan ke dalam urutan yang panjangnya satu hingga enam byte. Dalam praktiknya, UTF-8 hanya menggunakan rentang satu hingga empat byte, karena lebih dari empat byte kode, secara teoritis tidak mungkin lagi membayangkan apa pun. Semua karakter Latin di dalamnya dikodekan menjadi satu byte, seperti di ASCII lama. Yang perlu diperhatikan adalah jika hanya mengkodekan alfabet Latin, bahkan program yang tidak memahami Unicode akan tetap membaca apa yang dikodekan dalam YTF-8. Artinya, bagian dasar Asuka ditransfer begitu saja ke gagasan konsorsium Unicode ini. Karakter Sirilik dalam UTF-8 dikodekan dalam dua byte, dan, misalnya, karakter Georgia dikodekan dalam tiga byte. Konsorsium Unicode, setelah membuat UTF 16 dan 8, memecahkan masalah utama - sekarang kami memiliki satu ruang kode di font kami . Dan kini pabrikannya hanya bisa mengisinya dengan karakter teks berbentuk vektor berdasarkan kekuatan dan kemampuannya. Pada “Tabel Karakter” di atas Anda dapat melihat bahwa font yang berbeda mendukung jumlah karakter yang berbeda. Beberapa font yang kaya Unicode bisa jadi cukup berat. Tapi sekarang mereka berbeda bukan karena mereka dibuat untuk pengkodean yang berbeda, tetapi karena pembuat font telah mengisi atau tidak sepenuhnya mengisi ruang kode tunggal dengan bentuk vektor tertentu.
Kata-kata gila alih-alih huruf Rusia - cara memperbaikinya
Sekarang mari kita lihat bagaimana krakozyabr muncul alih-alih teks atau, dengan kata lain, bagaimana pengkodean yang benar untuk teks Rusia dipilih. Sebenarnya, ini diatur dalam program tempat Anda membuat atau mengedit teks ini, atau kode menggunakan fragmen teks. Untuk mengedit dan membuat file teks, saya pribadi menggunakan editor Html dan PHP Notepad++ yang sangat bagus menurut saya . Namun, ia dapat menyorot sintaksis ratusan bahasa pemrograman dan markup lainnya, dan juga memiliki kemampuan untuk diperluas menggunakan plugin. Baca ulasan rinci tentang program luar biasa ini di tautan yang disediakan. Di menu atas Notepad++ terdapat item “Encodings”, di mana Anda akan memiliki kesempatan untuk mengkonversi opsi yang ada ke opsi yang digunakan di situs Anda secara default: Dalam kasus situs di Joomla 1.5 dan lebih tinggi, sebagai serta dalam kasus blog di WordPress, sebaiknya hindari tampilan Krakozyabrov pilih opsi UTF 8 tanpa BOM . Apa awalan BOM? Faktanya adalah ketika mereka mengembangkan pengkodean YUTF-16, untuk beberapa alasan mereka memutuskan untuk melampirkan sesuatu seperti kemampuan untuk menulis kode karakter baik dalam urutan langsung (misalnya, 0A15) dan terbalik (150A) . Dan agar program memahami urutan membaca kode, BOM (Byte Order Mark atau, dengan kata lain, tanda tangan) ditemukan, yang dinyatakan dengan menambahkan tiga byte tambahan ke awal dokumen. Dalam pengkodean UTF-8, tidak ada BOM yang disediakan di konsorsium Unicode, dan oleh karena itu menambahkan tanda tangan (tiga byte tambahan yang terkenal di awal dokumen) hanya mencegah beberapa program membaca kode. Oleh karena itu, saat menyimpan file dalam UTF, kita harus selalu memilih opsi tanpa BOM (tanpa tanda tangan). Dengan demikian, Anda akan melindungi diri Anda terlebih dahulu dari penjelajahan krakozyabrs . Yang patut diperhatikan adalah bahwa beberapa program di Windows tidak dapat melakukan ini (mereka tidak dapat menyimpan teks dalam UTF-8 tanpa BOM), misalnya, Windows Notepad yang terkenal kejam. Ini menyimpan dokumen dalam UTF-8, tetapi masih menambahkan tanda tangan (tiga byte tambahan) di awal. Selain itu, byte ini akan selalu sama - baca kode secara berurutan. Tapi di server, karena hal kecil ini, masalah bisa muncul - penjahat akan keluar. Oleh karena itu, jangan gunakan notepad Windows biasa dalam keadaan apa pun.untuk mengedit dokumen di situs Anda jika Anda tidak ingin ada retakan yang muncul. Saya menganggap editor Notepad++ yang telah disebutkan sebagai pilihan terbaik dan termudah, yang praktis tidak memiliki kekurangan dan hanya terdiri dari kelebihan. Di Notepad++, saat Anda memilih pengkodean, Anda akan memiliki opsi untuk mengonversi teks menjadi pengkodean UCS-2, yang sifatnya sangat mirip dengan standar Unicode. Juga di Notepad dimungkinkan untuk menyandikan teks dalam ANSI, mis. sehubungan dengan bahasa Rusia, ini adalah Windows 1251, yang telah kami jelaskan di atas, Dari mana informasi ini berasal? Itu terdaftar di registri sistem operasi Windows Anda - pengkodean mana yang harus dipilih dalam kasus ANSI, yang mana untuk dipilih dalam kasus OEM (untuk bahasa Rusia akan menjadi CP866). Jika Anda menyetel bahasa default lain di komputer Anda, maka pengkodean ini akan diganti dengan bahasa serupa dari kategori ANSI atau OEM untuk bahasa yang sama. Setelah Anda menyimpan dokumen di Notepad++ dalam pengkodean yang Anda perlukan atau membuka dokumen dari situs untuk diedit, Anda akan dapat melihat namanya di sudut kanan bawah editor: Untuk menghindari kebingungan , selain langkah-langkah yang dijelaskan di atas , akan berguna untuk menulis kode sumber di headernya di semua halaman situs informasi tentang pengkodean ini, sehingga tidak ada kebingungan di server atau host lokal. Secara umum, semua bahasa markup hypertext kecuali Html menggunakan deklarasi xml khusus, yang menentukan pengkodean teks.
<?xml version="1.0" encoding="windows-1251"?>
Sebelum mengurai kode, browser mengetahui versi mana yang digunakan dan bagaimana tepatnya versi tersebut perlu menafsirkan kode karakter bahasa tersebut. Namun yang perlu diperhatikan adalah jika Anda menyimpan dokumen dalam Unicode default, deklarasi xml ini dapat dihilangkan (pengkodean akan dianggap UTF-8 jika tidak ada BOM atau UTF-16 jika ada BOM). Dalam kasus dokumen HTML, elemen Meta digunakan untuk menunjukkan pengkodean , yang ditempatkan di antara tag Head pembuka dan penutup:
<head>...<meta charset="utf-8">...</head>
Entri ini sangat berbeda dari standar di Html 4.01, namun sepenuhnya sesuai dengan standar Html 5, dan akan dipahami dengan benar oleh browser mana pun yang saat ini digunakan. Secara teori, elemen Meta yang menunjukkan pengkodean dokumen Html akan lebih baik ditempatkan setinggi mungkin di header dokumen , sehingga pada saat teks bertemu dengan karakter pertama yang bukan dari ANSI dasar (yang selalu dibaca dengan benar dan masuk variasi apa pun), browser seharusnya sudah memiliki informasi tentang cara menafsirkan kode karakter ini. Tautan ke sumber asli: pengkodean teks ASCII (Windows 1251, CP866, KOI8-R) dan Unicode (UTF 8, 16, 32) - cara memperbaiki masalah dengan cracker
128 karakter dari versi asli ASCII inilah yang menjadi standar, dan dalam pengkodean lainnya Anda pasti akan menemukannya dan karakter tersebut akan muncul dalam urutan ini. Tetapi faktanya adalah dengan bantuan satu byte informasi Anda tidak dapat menyandikan 128, tetapi sebanyak 256 nilai yang berbeda (dua pangkat delapan sama dengan 256), oleh karena itu, setelah versi dasar Asuka, keseluruhan serangkaian pengkodean ASCII yang diperluas muncul , yang memungkinkan, selain 128 karakter dasar, juga dapat dikodekan menggunakan karakter pengkodean nasional (misalnya, Rusia). Di sini, mungkin ada baiknya menjelaskan lebih banyak tentang sistem bilangan yang digunakan dalam deskripsi. Pertama, seperti yang anda ketahui bersama, komputer hanya bekerja dengan bilangan-bilangan dalam sistem biner, yaitu dengan nol dan satu (“Aljabar Boolean”, kalau ada yang mengambilnya di institut atau sekolah). Satu byte terdiri dari delapan bit, yang masing-masing mewakili dua pangkat dua, dimulai dari nol, dan hingga dua hingga ketujuh: 
Tidak sulit untuk memahami bahwa semua kemungkinan kombinasi nol dan satu dalam konstruksi seperti itu dapat hanya menjadi 256. Mengubah bilangan dari sistem biner ke desimal cukup sederhana. Anda hanya perlu menjumlahkan semua pangkat dua dengan pangkat di atasnya. Dalam contoh kita, hasilnya adalah 1 (2 pangkat nol) ditambah 8 (dua pangkat 3), ditambah 32 (dua pangkat lima), ditambah 64 (pangkat keenam), ditambah 128 (pangkat ketujuh). Jumlahnya adalah 233 dalam notasi desimal. Seperti yang Anda lihat, semuanya sangat sederhana. Namun jika Anda melihat lebih dekat pada tabel dengan karakter ASCII, Anda akan melihat bahwa karakter tersebut direpresentasikan dalam pengkodean heksadesimal. Misalnya, "tanda bintang" sama dengan angka heksadesimal 2A di Aski. Anda mungkin tahu bahwa dalam sistem bilangan heksadesimal, selain angka arab, juga digunakan huruf latin dari A (berarti sepuluh) sampai F (berarti lima belas). Nah, untuk mengubah bilangan biner menjadi heksadesimalgunakan metode sederhana berikut. Setiap byte informasi dibagi menjadi dua bagian yang terdiri dari empat bit. Itu. Dalam setiap setengah byte, hanya enam belas nilai (dua pangkat empat) yang dapat dikodekan dalam biner, yang dapat dengan mudah direpresentasikan sebagai bilangan heksadesimal. Selain itu, di bagian kiri byte, derajat perlu dihitung lagi mulai dari nol, dan tidak seperti yang ditunjukkan pada tangkapan layar. Hasilnya, kami mendapatkan nomor E9 yang dikodekan di tangkapan layar. Saya harap alur pemikiran saya dan solusi atas teka-teki ini jelas bagi Anda. Nah, sekarang mari kita lanjutkan berbicara tentang pengkodean teks.
Soalnya, di kolom kanan angkanya dimulai dengan 8, karena angka dari 0 hingga 7 mengacu pada bagian dasar ASCII (lihat tangkapan layar pertama). Jadi, huruf Sirilik “M” di CP866 akan memiliki kode 9C (terletak di perpotongan garis yang sesuai dengan 9 dan kolom dengan angka C dalam sistem bilangan heksadesimal), yang dapat ditulis dalam satu byte informasi , dan jika ada font yang cocok dengan karakter Rusia, surat ini akan muncul di teks tanpa masalah. Dari mana asal jumlah tersebut?pseudografik di CP866 ? Intinya adalah bahwa pengkodean untuk teks Rusia ini dikembangkan pada tahun-tahun sulit ketika sistem operasi grafis tidak tersebar luas seperti sekarang. Dan di Dosa dan sistem operasi teks serupa, pseudografik memungkinkan setidaknya untuk mendiversifikasi desain teks, dan oleh karena itu CP866 dan semua rekan lainnya dari kategori versi Asuka yang diperluas berlimpah di dalamnya. CP866 didistribusikan oleh IBM, tetapi selain itu, sejumlah pengkodean dikembangkan untuk karakter bahasa Rusia, misalnya, KOI8-R dapat dikaitkan dengan tipe yang sama (ASCII yang diperluas) : 
Prinsip operasinya tetap sama seperti seperti yang dijelaskan pada CP866 sebelumnya - Setiap karakter teks dikodekan sebagai satu byte. Tangkapan layar menunjukkan paruh kedua tabel KOI8-R, karena babak pertama sepenuhnya konsisten dengan dasar Asuka, yang ditunjukkan pada tangkapan layar pertama artikel ini. Di antara fitur pengkodean KOI8-R, dapat dicatat bahwa huruf Sirilik dalam tabelnya tidak disusun menurut abjad, seperti yang dilakukan pada CP866. Jika Anda melihat tangkapan layar pertama (bagian dasar, yang disertakan dalam semua pengkodean yang diperluas), Anda akan melihat bahwa di KOI8-R huruf Rusia terletak di sel tabel yang sama dengan huruf alfabet Latin yang sesuai. dari bagian pertama tabel. Hal ini dilakukan untuk kenyamanan peralihan dari karakter Rusia ke Latin dengan membuang satu bit saja (dua pangkat tujuh atau 128).
Karena banyaknya pengkodean bahasa Rusia, produsen font dan produsen perangkat lunak terus-menerus mengalami sakit kepala, dan Anda dan saya, para pembaca yang budiman, sering mendapat masalah dengan bug terkenal yang sama ketika ada kebingungan dengan versi yang digunakan dalam teks. Sangat sering mereka keluar ketika mengirim dan menerima pesan melalui email, yang memerlukan pembuatan tabel konversi yang sangat kompleks, yang, pada kenyataannya, tidak dapat menyelesaikan masalah ini secara mendasar, dan seringkali pengguna menggunakan transliterasi huruf Latin untuk korespondensi untuk hindari omong kosong yang terkenal saat menggunakan penyandian bahasa Rusia seperti CP866, KOI8-R, atau Windows 1251. Faktanya, retakan yang muncul alih-alih teks Rusia adalah akibat dari kesalahan penggunaan penyandian bahasa tertentu, yang tidak sesuai dengan yang ada di di mana pesan teks awalnya dikodekan. Katakanlah jika Anda mencoba menampilkan karakter yang dikodekan menggunakan CP866 menggunakan tabel kode Windows 1251, maka omong kosong yang sama (kumpulan karakter yang tidak berarti) akan keluar, sepenuhnya menggantikan teks pesan. 
Situasi serupa sangat sering muncul saat membuat dan menyiapkan situs web, forum, atau blog, ketika teks dengan karakter Rusia salah disimpan dalam pengkodean yang salah yang digunakan di situs secara default, atau di editor teks yang salah, yang menambahkan lelucon yang tidak terlihat. ke kode dengan mata telanjang. Pada akhirnya, banyak orang bosan dengan situasi ini dengan banyak pengkodean dan omong kosong yang terus-menerus, dan prasyarat muncul untuk penciptaan variasi universal baru yang akan menggantikan semua yang sudah ada dan menyelesaikan masalah dengan munculnya teks yang tidak dapat dibaca. . Selain itu, ada masalah bahasa seperti Cina, dimana karakter bahasanya jauh lebih banyak dari 256.
Berapa banyak karakter yang dapat dikodekan dalam UTF-16 menggunakan 16 bit? 65.536 (dua pangkat enam belas), dan ini adalah angka yang diadopsi sebagai spasi dasar di Unicode. Selain itu, ada cara untuk mengkodekan sekitar dua juta karakter dengan menggunakannya, tetapi cara tersebut dibatasi pada ruang yang diperluas sebanyak satu juta karakter teks. Tetapi bahkan versi pengkodean Unicode yang sukses ini tidak memberikan banyak kepuasan bagi mereka yang menulis, katakanlah, program hanya dalam bahasa Inggris, karena setelah transisi dari versi ASCII yang diperluas ke UTF-16, bobot dokumen menjadi dua kali lipat (satu byte per karakter di Aski dan dua byte untuk karakter yang sama di YUTF-16). Justru untuk memuaskan semua orang dan semua yang ada di konsorsium Unicode maka diputuskan untuk membuat pengkodean panjang variabel . Itu disebut UTF-8. Meskipun namanya delapan, sebenarnya ia memiliki panjang yang bervariasi, yaitu. Setiap karakter teks dapat dikodekan ke dalam urutan yang panjangnya satu hingga enam byte. Dalam praktiknya, UTF-8 hanya menggunakan rentang satu hingga empat byte, karena lebih dari empat byte kode, secara teoritis tidak mungkin lagi membayangkan apa pun. Semua karakter Latin di dalamnya dikodekan menjadi satu byte, seperti di ASCII lama. Yang perlu diperhatikan adalah jika hanya mengkodekan alfabet Latin, bahkan program yang tidak memahami Unicode akan tetap membaca apa yang dikodekan dalam YTF-8. Artinya, bagian dasar Asuka ditransfer begitu saja ke gagasan konsorsium Unicode ini. Karakter Sirilik dalam UTF-8 dikodekan dalam dua byte, dan, misalnya, karakter Georgia dikodekan dalam tiga byte. Konsorsium Unicode, setelah membuat UTF 16 dan 8, memecahkan masalah utama - sekarang kami memiliki satu ruang kode di font kami . Dan kini pabrikannya hanya bisa mengisinya dengan karakter teks berbentuk vektor berdasarkan kekuatan dan kemampuannya. Pada “Tabel Karakter” di atas Anda dapat melihat bahwa font yang berbeda mendukung jumlah karakter yang berbeda. Beberapa font yang kaya Unicode bisa jadi cukup berat. Tapi sekarang mereka berbeda bukan karena mereka dibuat untuk pengkodean yang berbeda, tetapi karena pembuat font telah mengisi atau tidak sepenuhnya mengisi ruang kode tunggal dengan bentuk vektor tertentu.
Dalam kasus situs di Joomla 1.5 dan lebih tinggi, sebagai serta dalam kasus blog di WordPress, sebaiknya hindari tampilan Krakozyabrov pilih opsi UTF 8 tanpa BOM . Apa awalan BOM? Faktanya adalah ketika mereka mengembangkan pengkodean YUTF-16, untuk beberapa alasan mereka memutuskan untuk melampirkan sesuatu seperti kemampuan untuk menulis kode karakter baik dalam urutan langsung (misalnya, 0A15) dan terbalik (150A) . Dan agar program memahami urutan membaca kode, BOM (Byte Order Mark atau, dengan kata lain, tanda tangan) ditemukan, yang dinyatakan dengan menambahkan tiga byte tambahan ke awal dokumen. Dalam pengkodean UTF-8, tidak ada BOM yang disediakan di konsorsium Unicode, dan oleh karena itu menambahkan tanda tangan (tiga byte tambahan yang terkenal di awal dokumen) hanya mencegah beberapa program membaca kode. Oleh karena itu, saat menyimpan file dalam UTF, kita harus selalu memilih opsi tanpa BOM (tanpa tanda tangan). Dengan demikian, Anda akan melindungi diri Anda terlebih dahulu dari penjelajahan krakozyabrs . Yang patut diperhatikan adalah bahwa beberapa program di Windows tidak dapat melakukan ini (mereka tidak dapat menyimpan teks dalam UTF-8 tanpa BOM), misalnya, Windows Notepad yang terkenal kejam. Ini menyimpan dokumen dalam UTF-8, tetapi masih menambahkan tanda tangan (tiga byte tambahan) di awal. Selain itu, byte ini akan selalu sama - baca kode secara berurutan. Tapi di server, karena hal kecil ini, masalah bisa muncul - penjahat akan keluar. Oleh karena itu, jangan gunakan notepad Windows biasa dalam keadaan apa pun.untuk mengedit dokumen di situs Anda jika Anda tidak ingin ada retakan yang muncul. Saya menganggap editor Notepad++ yang telah disebutkan sebagai pilihan terbaik dan termudah, yang praktis tidak memiliki kekurangan dan hanya terdiri dari kelebihan. Di Notepad++, saat Anda memilih pengkodean, Anda akan memiliki opsi untuk mengonversi teks menjadi pengkodean UCS-2, yang sifatnya sangat mirip dengan standar Unicode. Juga di Notepad dimungkinkan untuk menyandikan teks dalam ANSI, mis. sehubungan dengan bahasa Rusia, ini adalah Windows 1251, yang telah kami jelaskan di atas, Dari mana informasi ini berasal? Itu terdaftar di registri sistem operasi Windows Anda - pengkodean mana yang harus dipilih dalam kasus ANSI, yang mana untuk dipilih dalam kasus OEM (untuk bahasa Rusia akan menjadi CP866). Jika Anda menyetel bahasa default lain di komputer Anda, maka pengkodean ini akan diganti dengan bahasa serupa dari kategori ANSI atau OEM untuk bahasa yang sama. Setelah Anda menyimpan dokumen di Notepad++ dalam pengkodean yang Anda perlukan atau membuka dokumen dari situs untuk diedit, Anda akan dapat melihat namanya di sudut kanan bawah editor: 
Untuk menghindari kebingungan , selain langkah-langkah yang dijelaskan di atas , akan berguna untuk menulis kode sumber di headernya di semua halaman situs informasi tentang pengkodean ini, sehingga tidak ada kebingungan di server atau host lokal. Secara umum, semua bahasa markup hypertext kecuali Html menggunakan deklarasi xml khusus, yang menentukan pengkodean teks.
GO TO FULL VERSION