Hari ini kita akan bercakap tentang dari mana krakozyabrs berasal di tapak web dan dalam program, apakah pengekodan teks yang wujud dan yang mana harus digunakan. Mari kita lihat lebih dekat sejarah pembangunan mereka, bermula dengan ASCII asas, serta versi lanjutannya CP866, KOI8-R, Windows 1251 dan berakhir dengan pengekodan konsortium Unicode moden UTF 16 dan 8. Jadual kandungan:
Bagi sesetengah orang, maklumat ini mungkin kelihatan tidak perlu, tetapi adakah anda tahu berapa banyak soalan yang saya terima secara khusus mengenai krakozyabrs yang merangkak (set aksara yang tidak boleh dibaca). Sekarang saya akan mempunyai peluang untuk merujuk semua orang kepada teks artikel ini dan mencari kesilapan saya sendiri. Baiklah, bersedia untuk menyerap maklumat dan cuba mengikuti aliran cerita.
ASCII - pengekodan teks asas untuk abjad Latin
Perkembangan pengekodan teks berlaku serentak dengan pembentukan industri IT, dan pada masa ini mereka berjaya mengalami banyak perubahan. Dari segi sejarah, semuanya bermula dengan EBCDIC, yang agak sumbang dalam sebutan Rusia, yang memungkinkan untuk mengekod huruf abjad Latin, angka Arab dan tanda baca dengan aksara kawalan. Tetapi masih, titik permulaan untuk pembangunan pengekodan teks moden harus dianggap sebagai ASCII yang terkenal (Kod Standard Amerika untuk Pertukaran Maklumat, yang dalam bahasa Rusia biasanya disebut sebagai "tanya"). Ia menerangkan 128 aksara pertama yang paling biasa digunakan oleh pengguna berbahasa Inggeris - huruf Latin, angka Arab dan tanda baca. 128 aksara yang diterangkan dalam ASCII ini juga termasuk beberapa aksara perkhidmatan seperti kurungan, tanda cincang, asterisk, dsb. Malah, anda boleh melihatnya sendiri: 128 aksara daripada versi asal ASCII inilah yang menjadi standard, dan dalam mana-mana pengekodan lain anda pasti akan menemuinya dan ia akan muncul dalam susunan ini. Tetapi hakikatnya ialah dengan bantuan satu bait maklumat anda boleh mengekod bukan 128, tetapi sebanyak 256 nilai yang berbeza (dua kepada kuasa lapan sama dengan 256), oleh itu, selepas versi asas Asuka, keseluruhan siri pengekodan ASCII lanjutan muncul , di mana ia mungkin, sebagai tambahan kepada 128 aksara asas juga boleh dikodkan menggunakan aksara pengekodan kebangsaan (contohnya, Rusia). Di sini, ia mungkin berbaloi untuk menyatakan lebih banyak tentang sistem nombor yang digunakan dalam penerangan. Pertama, seperti yang anda semua tahu, komputer hanya berfungsi dengan nombor dalam sistem binari, iaitu dengan sifar dan satu (“algebra Boolean”, jika sesiapa mengambilnya di institut atau sekolah). Satu bait terdiri daripada lapan bit, setiap satunya mewakili dua hingga kuasa dua, bermula dari sifar, dan sehingga dua hingga ketujuh: Tidak sukar untuk memahami bahawa semua kemungkinan gabungan sifar dan satu dalam pembinaan sedemikian boleh hanya 256. Menukar nombor daripada sistem binari kepada perpuluhan adalah agak mudah. Anda hanya perlu menambah semua kuasa dua dengan kuasa di atasnya. Dalam contoh kami, ini ternyata menjadi 1 (2 kepada kuasa sifar) ditambah 8 (dua kepada kuasa 3), ditambah 32 (dua kepada kuasa kelima), ditambah 64 (kepada kuasa keenam), ditambah 128 (kepada kuasa ketujuh). Jumlahnya ialah 233 dalam tatatanda perpuluhan. Seperti yang anda lihat, semuanya sangat mudah. Tetapi jika anda melihat dengan teliti jadual dengan aksara ASCII, anda akan melihat bahawa ia diwakili dalam pengekodan heksadesimal. Sebagai contoh, "asterisk" sepadan dengan nombor perenambelasan 2A dalam Aski. Anda mungkin tahu bahawa dalam sistem nombor perenambelasan, sebagai tambahan kepada angka Arab, huruf Latin dari A (bermakna sepuluh) hingga F (bermakna lima belas) juga digunakan. Nah, untuk menukar nombor binari kepada perenambelasanmenggunakan kaedah mudah berikut. Setiap bait maklumat dibahagikan kepada dua bahagian empat bit. Itu. Dalam setiap separuh bait, hanya enam belas nilai (dua hingga kuasa keempat) boleh dikodkan dalam binari, yang boleh dengan mudah diwakili sebagai nombor perenambelasan. Selain itu, di separuh kiri bait, darjah perlu dikira semula bermula dari sifar, dan bukan seperti yang ditunjukkan dalam tangkapan skrin. Akibatnya, kami mendapat bahawa nombor E9 dikodkan dalam tangkapan skrin. Saya berharap perjalanan pemikiran saya dan penyelesaian teka-teki ini jelas kepada anda. Nah, sekarang mari kita teruskan, sebenarnya, bercakap tentang pengekodan teks.
Versi lanjutan Asuka - pengekodan CP866 dan KOI8-R dengan pseudografik
Jadi, kami mula bercakap tentang ASCII, yang, seolah-olah, titik permulaan untuk pembangunan semua pengekodan moden (Windows 1251, Unicode, UTF 8). Pada mulanya, ia mengandungi hanya 128 aksara abjad Latin, angka Arab dan sesuatu yang lain, tetapi dalam versi lanjutan ia menjadi mungkin untuk menggunakan semua 256 nilai yang boleh dikodkan dalam satu bait maklumat. Itu. Anda boleh menambah simbol huruf dalam bahasa anda pada Aski. Di sini kita perlu menyimpang sekali lagi untuk menjelaskan mengapa pengekodan teks diperlukan sama sekali dan mengapa ia sangat penting. Aksara pada skrin komputer anda dibentuk berdasarkan dua perkara - set bentuk vektor (perwakilan) pelbagai aksara (ia ada dalam fail dengan fon yang dipasang pada komputer anda) dan kod yang membolehkan anda mengeluarkan dengan tepat satu aksara itu. daripada set bentuk vektor (fail fon) ini, simbol yang perlu dimasukkan di tempat yang betul. Adalah jelas bahawa fon itu sendiri bertanggungjawab untuk bentuk vektor, tetapi sistem pengendalian dan program yang digunakan di dalamnya bertanggungjawab untuk pengekodan. Itu. sebarang teks pada komputer anda akan menjadi satu set bait, setiap satunya mengekod satu aksara tunggal teks ini. Program yang memaparkan teks ini pada skrin (editor teks, penyemak imbas, dll.), apabila menghuraikan kod, membaca pengekodan aksara seterusnya dan mencari bentuk vektor yang sepadan dalam fail fon yang diperlukan, yang disambungkan untuk memaparkan ini dokumen teks. Semuanya mudah dan cetek. Ini bermakna bahawa untuk mengekod mana-mana aksara yang kita perlukan (contohnya, daripada abjad kebangsaan), dua syarat mesti dipenuhi: bentuk vektor aksara ini mestilah dalam fon yang digunakan dan aksara ini boleh dikodkan dalam pengekodan ASCII lanjutan dalam satu bait. Oleh itu, terdapat sejumlah besar pilihan sedemikian. Hanya untuk pengekodan aksara bahasa Rusia, terdapat beberapa jenis Aska lanjutan. Sebagai contoh, CP866 pada asalnya muncul , yang mempunyai keupayaan untuk menggunakan aksara daripada abjad Rusia, dan ia adalah versi lanjutan ASCII. Iaitu, bahagian atasnya sepenuhnya bertepatan dengan versi asas Aska (128 aksara Latin, nombor dan omong kosong lain), yang ditunjukkan dalam tangkapan skrin tepat di atas, tetapi bahagian bawah jadual dengan pengekodan CP866 mempunyai rupa yang ditunjukkan dalam tangkapan skrin betul-betul di bawah dan dibenarkan mengekod lagi 128 aksara (huruf Rusia dan semua jenis pseudo-grafik): Anda lihat, di lajur kanan nombor bermula dengan 8, kerana nombor dari 0 hingga 7 merujuk kepada bahagian asas ASCII (lihat tangkapan skrin pertama). Oleh itu, huruf Cyrillic "M" dalam CP866 akan mempunyai kod 9C (ia terletak di persimpangan baris yang sepadan dengan 9 dan lajur dengan nombor C dalam sistem nombor perenambelasan), yang boleh ditulis dalam satu bait maklumat , dan jika terdapat fon yang sesuai dengan aksara Rusia surat ini akan muncul dalam teks tanpa sebarang masalah. Dari mana datangnya jumlah ini?pseudografik dalam CP866 ? Intinya ialah pengekodan untuk teks Rusia ini telah dibangunkan kembali pada tahun-tahun kelam apabila sistem pengendalian grafik tidak meluas seperti sekarang. Dan dalam Dosa dan sistem pengendalian teks yang serupa, pseudografi membolehkan sekurang-kurangnya entah bagaimana mempelbagaikan reka bentuk teks, dan oleh itu CP866 dan semua rakannya yang lain daripada kategori versi lanjutan Asuka banyak terdapat di dalamnya. CP866 diedarkan oleh IBM, tetapi sebagai tambahan kepada ini, beberapa pengekodan telah dibangunkan untuk aksara bahasa Rusia, sebagai contoh, KOI8-R boleh dikaitkan dengan jenis yang sama (ASCII lanjutan) : Prinsip operasinya tetap sama seperti daripada CP866 yang diterangkan lebih awal - Setiap aksara teks dikodkan sebagai satu bait tunggal. Tangkapan skrin menunjukkan separuh kedua jadual KOI8-R, kerana separuh masa pertama benar-benar konsisten dengan Asuka asas, yang ditunjukkan dalam tangkapan skrin pertama dalam artikel ini. Antara ciri pengekodan KOI8-R, boleh diperhatikan bahawa huruf Cyrillic dalam jadualnya tidak dalam susunan abjad, seperti yang dilakukan dalam CP866. Jika anda melihat tangkapan skrin pertama (bahagian asas, yang disertakan dalam semua pengekodan lanjutan), anda akan melihat bahawa dalam KOI8-R huruf Rusia terletak di sel yang sama dalam jadual dengan huruf yang sepadan dalam abjad Latin dari bahagian pertama jadual. Ini dilakukan untuk kemudahan menukar daripada aksara Rusia ke Latin dengan membuang hanya satu bit (dua kepada kuasa ketujuh atau 128).
Windows 1251 - versi moden ASCII dan sebab retakan itu keluar
Perkembangan selanjutnya pengekodan teks adalah disebabkan oleh fakta bahawa sistem pengendalian grafik semakin popular dan keperluan untuk menggunakan pseudografik di dalamnya hilang dari semasa ke semasa. Akibatnya, seluruh kumpulan timbul bahawa, pada dasarnya, masih merupakan versi lanjutan Asuka (satu aksara teks dikodkan dengan hanya satu bait maklumat), tetapi tanpa menggunakan simbol pseudografik. Ia tergolong dalam pengekodan ANSI yang dipanggil, yang dibangunkan oleh American Standards Institute. Dalam bahasa biasa, nama Cyrillic juga digunakan untuk versi dengan sokongan bahasa Rusia. Contohnya ialah Windows 1251 . Ia berbeza dengan baik daripada CP866 dan KOI8-R yang digunakan sebelum ini kerana tempat simbol pseudografik di dalamnya diambil oleh simbol tipografi Rusia yang hilang (kecuali tanda aksen), serta simbol yang digunakan dalam bahasa Slavik berhampiran dengan Rusia (Ukraine, Belarusia, dll.). ): Disebabkan oleh banyaknya pengekodan bahasa Rusia, pengeluar fon dan pengeluar perisian sentiasa mengalami sakit kepala, dan anda dan saya, pembaca yang dikasihi, sering menghadapi masalah dengan pepijat terkenal yang sama. apabila terdapat kekeliruan dengan versi yang digunakan dalam teks. Selalunya mereka keluar apabila menghantar dan menerima mesej melalui e-mel, yang memerlukan penciptaan jadual penukaran yang sangat kompleks, yang, sebenarnya, tidak dapat menyelesaikan masalah ini secara asas, dan sering pengguna menggunakan transliterasi huruf Latin untuk surat-menyurat untuk elakkan omong kosong yang terkenal apabila menggunakan pengekodan Rusia seperti CP866, KOI8-R atau Windows 1251. Malah, retakan yang muncul dan bukannya teks Rusia adalah akibat daripada penggunaan pengekodan bahasa yang tidak betul, yang tidak sepadan dengan yang terdapat dalam yang mesej teks asalnya dikodkan. Katakan bahawa jika anda cuba memaparkan aksara yang dikodkan menggunakan CP866 menggunakan jadual kod Windows 1251, maka omong kosong yang sama ini (set aksara yang tidak bermakna) akan keluar, menggantikan teks mesej sepenuhnya. Situasi yang sama selalunya timbul apabila membuat dan menyediakan tapak web, forum atau blog, apabila teks dengan aksara Rusia tersilap disimpan dalam pengekodan yang salah yang digunakan di tapak secara lalai, atau dalam penyunting teks yang salah, yang menambah gag yang tidak kelihatan. kepada kod dengan mata kasar. Pada akhirnya, ramai orang bosan dengan keadaan ini dengan banyak pengekodan dan sentiasa menjalar keluar omong kosong, dan prasyarat muncul untuk penciptaan variasi universal baharu yang akan menggantikan semua yang sedia ada dan menyelesaikan masalah dengan kemunculan teks yang tidak boleh dibaca . Di samping itu, terdapat masalah bahasa seperti bahasa Cina, di mana terdapat lebih banyak aksara bahasa daripada 256.
Unicode - pengekodan universal UTF 8, 16 dan 32
Beribu-ribu aksara kumpulan bahasa Asia Tenggara ini tidak mungkin dapat diterangkan dalam satu bait maklumat yang diperuntukkan untuk pengekodan aksara dalam versi lanjutan ASCII. Hasilnya, sebuah konsortium yang dipanggil Unicode (Unicode Consortium) telah diwujudkan dengan kerjasama ramai pemimpin industri IT (mereka yang menghasilkan perisian, yang mengekod perkakasan, yang mencipta fon) yang berminat dengan kemunculan pengekodan teks universal. Variasi pertama yang dikeluarkan di bawah naungan Unicode Consortium ialah UTF 32 . Nombor dalam nama pengekodan bermaksud bilangan bit yang digunakan untuk mengekod satu aksara. 32 bit sama dengan 4 bait maklumat yang diperlukan untuk mengekod satu aksara tunggal dalam pengekodan UTF universal baharu. Akibatnya, fail yang sama dengan teks yang dikodkan dalam versi lanjutan ASCII dan dalam UTF-32, dalam kes kedua, akan mempunyai saiz (berat) empat kali lebih besar. Ini buruk, tetapi kini kami berpeluang untuk mengekod menggunakan UTF sejumlah aksara bersamaan dengan dua hingga kuasa tiga puluh saat ( berbilion aksara yang akan meliputi sebarang nilai yang benar-benar diperlukan dengan margin yang sangat besar). Tetapi banyak negara dengan bahasa kumpulan Eropah tidak perlu menggunakan sejumlah besar aksara dalam pengekodan sama sekali, bagaimanapun, apabila menggunakan UTF-32, mereka tanpa sebab menerima peningkatan empat kali ganda dalam berat dokumen teks, dan akibatnya, peningkatan dalam jumlah trafik Internet dan volum data yang disimpan. Ini adalah banyak, dan tiada siapa yang mampu membayar pembaziran sedemikian. Hasil daripada pembangunan Unicode, UTF-16 muncul , yang ternyata sangat berjaya sehingga ia telah diterima pakai secara lalai sebagai ruang asas untuk semua aksara yang kami gunakan. Ia menggunakan dua bait untuk mengekod satu aksara. Mari kita lihat bagaimana perkara ini kelihatan. Dalam sistem pengendalian Windows, anda boleh mengikuti laluan "Mula" - "Program" - "Aksesori" - "Alat Sistem" - "Jadual Aksara". Akibatnya, jadual akan dibuka dengan bentuk vektor semua fon yang dipasang pada sistem anda. Jika anda memilih set aksara Unicode dalam "Pilihan lanjutan", anda akan dapat melihat untuk setiap fon secara berasingan keseluruhan julat aksara yang disertakan di dalamnya. Ngomong-ngomong, dengan mengklik mana-mana daripadanya, anda boleh melihat kod dua baitnya dalam format UTF-16 , yang terdiri daripada empat digit heksadesimal: Berapakah bilangan aksara yang boleh dikodkan dalam UTF-16 menggunakan 16 bit? 65,536 (dua kepada kuasa enam belas), dan ini ialah nombor yang diterima pakai sebagai ruang asas dalam Unicode. Di samping itu, terdapat cara untuk mengekod kira-kira dua juta aksara menggunakannya, tetapi ia terhad kepada ruang yang diperluaskan dengan sejuta aksara teks. Tetapi walaupun versi pengekodan Unicode yang berjaya ini tidak memberikan banyak kepuasan kepada mereka yang menulis, katakan, program hanya dalam bahasa Inggeris, kerana selepas peralihan daripada versi lanjutan ASCII ke UTF-16, berat dokumen meningkat dua kali ganda (satu bait setiap aksara dalam Aski dan dua bait untuk aksara yang sama dalam YUTF-16). Ia adalah tepat untuk memuaskan hati semua orang dan segala-galanya dalam konsortium Unicode bahawa ia telah memutuskan untuk menghasilkan pengekodan panjang berubah-ubah . Ia dipanggil UTF-8. Walaupun lapan dalam nama, ia sebenarnya mempunyai panjang berubah-ubah, i.e. Setiap aksara teks boleh dikodkan ke dalam urutan satu hingga enam bait panjangnya. Dalam praktiknya, UTF-8 hanya menggunakan julat dari satu hingga empat bait, kerana melebihi empat bait kod ia tidak lagi secara teori mungkin membayangkan apa-apa. Semua aksara Latin di dalamnya dikodkan menjadi satu bait, sama seperti dalam ASCII lama yang baik. Apa yang patut diberi perhatian ialah dalam kes pengekodan hanya abjad Latin, malah program yang tidak memahami Unicode masih akan membaca apa yang dikodkan dalam YTF-8. Iaitu, bahagian asas Asuka hanya dipindahkan kepada idea konsortium Unicode ini. Aksara Cyrillic dalam UTF-8 dikodkan dalam dua bait, dan, sebagai contoh, aksara Georgia dikodkan dalam tiga bait. Konsortium Unicode, selepas mencipta UTF 16 dan 8, menyelesaikan masalah utama - kini kami mempunyai ruang kod tunggal dalam fon kami . Dan kini pengeluar mereka hanya boleh mengisinya dengan bentuk vektor aksara teks berdasarkan kekuatan dan keupayaan mereka. Dalam "Jadual Aksara" di atas anda boleh melihat bahawa fon berbeza menyokong bilangan aksara yang berbeza. Sesetengah fon kaya Unicode boleh menjadi agak berat. Tetapi kini mereka berbeza bukan pada hakikat bahawa ia dicipta untuk pengekodan yang berbeza, tetapi pada hakikat bahawa pengeluar fon telah mengisi atau tidak sepenuhnya mengisi ruang kod tunggal dengan bentuk vektor tertentu.
Perkataan gila dan bukannya huruf Rusia - bagaimana untuk membetulkannya
Sekarang mari kita lihat bagaimana krakozyabrs muncul dan bukannya teks atau, dengan kata lain, cara pengekodan yang betul untuk teks Rusia dipilih. Sebenarnya, ia ditetapkan dalam program di mana anda mencipta atau mengedit teks ini, atau kod menggunakan serpihan teks. Untuk mengedit dan membuat fail teks, saya secara peribadi menggunakan yang sangat baik, pada pendapat saya, editor Html dan PHP Notepad++ . Walau bagaimanapun, ia boleh menyerlahkan sintaks beratus-ratus bahasa pengaturcaraan dan penanda lain, dan juga mempunyai keupayaan untuk dilanjutkan menggunakan pemalam. Baca ulasan terperinci program hebat ini di pautan yang disediakan. Dalam menu atas Notepad++ terdapat item "Pengekodan", di mana anda akan mempunyai peluang untuk menukar pilihan sedia ada kepada pilihan yang digunakan di tapak anda secara lalai: Dalam kes tapak di Joomla 1.5 dan lebih tinggi, seperti dan juga dalam kes blog di WordPress, anda harus mengelakkan penampilan Krakozyabrov memilih pilihan UTF 8 tanpa BOM . Apakah awalan BOM? Hakikatnya ialah apabila mereka membangunkan pengekodan YUTF-16, atas sebab tertentu mereka memutuskan untuk melampirkan padanya perkara seperti keupayaan untuk menulis kod aksara kedua-duanya dalam urutan langsung (contohnya, 0A15) dan sebaliknya (150A) . Dan untuk program memahami dalam urutan apa untuk membaca kod, BOM (Byte Order Mark atau, dengan kata lain, tandatangan) telah dicipta, yang dinyatakan dalam menambah tiga bait tambahan pada permulaan dokumen. Dalam pengekodan UTF-8, tiada BOM disediakan dalam konsortium Unicode, dan oleh itu menambah tandatangan (tiga bait tambahan yang terkenal pada permulaan dokumen) hanya menghalang beberapa program daripada membaca kod. Oleh itu, apabila menyimpan fail dalam UTF, kita mesti sentiasa memilih pilihan tanpa BOM (tanpa tandatangan). Oleh itu, anda akan melindungi diri anda terlebih dahulu daripada merangkak keluar dari krakozyabrs . Apa yang patut diberi perhatian ialah sesetengah program dalam Windows tidak boleh melakukan ini (mereka tidak boleh menyimpan teks dalam UTF-8 tanpa BOM), sebagai contoh, Windows Notepad yang sama terkenal. Ia menyimpan dokumen dalam UTF-8, tetapi masih menambah tandatangan (tiga bait tambahan) pada permulaannya. Selain itu, bait ini akan sentiasa sama - baca kod dalam urutan langsung. Tetapi pada pelayan, kerana perkara kecil ini, masalah boleh timbul - penyangak akan keluar. Oleh itu, jangan gunakan notepad Windows biasa dalam apa jua keadaan.untuk mengedit dokumen di tapak anda jika anda tidak mahu sebarang retakan muncul. Saya menganggap editor Notepad++ yang telah disebutkan sebagai pilihan terbaik dan paling mudah, yang hampir tidak mempunyai kelemahan dan hanya terdiri daripada kelebihan. Dalam Notepad++, apabila anda memilih pengekodan, anda akan mempunyai pilihan untuk menukar teks kepada pengekodan UCS-2, yang sangat hampir dengan standard Unicode. Juga dalam Notepad adalah mungkin untuk mengekod teks dalam ANSI, i.e. berhubung dengan bahasa Rusia, ini ialah Windows 1251, yang telah kami jelaskan di atas. Dari manakah maklumat ini datang? Ia didaftarkan dalam pendaftaran sistem pengendalian Windows anda - pengekodan yang perlu dipilih dalam kes ANSI, yang perlu dipilih dalam kes OEM (untuk bahasa Rusia ia akan menjadi CP866). Jika anda menetapkan bahasa lalai lain pada komputer anda, maka pengekodan ini akan digantikan dengan yang serupa daripada kategori ANSI atau OEM untuk bahasa yang sama itu. Selepas anda menyimpan dokumen dalam Notepad++ dalam pengekodan yang anda perlukan atau membuka dokumen daripada tapak untuk pengeditan, anda akan dapat melihat namanya di sudut kanan bawah editor: Untuk mengelakkan kekeliruan , sebagai tambahan kepada langkah yang diterangkan di atas , adalah berguna untuk menulis kod sumber dalam pengepalanya semua halaman maklumat tapak tentang pengekodan ini, supaya tiada kekeliruan pada pelayan atau hos tempatan. Secara umum, semua bahasa penanda hiperteks kecuali Html menggunakan pengisytiharan xml khas, yang menentukan pengekodan teks.
<?xml version="1.0" encoding="windows-1251"?>
Sebelum menghuraikan kod, penyemak imbas mengetahui versi mana yang sedang digunakan dan bagaimana sebenarnya ia perlu mentafsir kod aksara bahasa tersebut. Tetapi apa yang patut diberi perhatian ialah jika anda menyimpan dokumen dalam Unicode lalai, pengisytiharan xml ini boleh ditinggalkan (pengekodan akan dianggap UTF-8 jika tiada BOM atau UTF-16 jika terdapat BOM). Dalam kes dokumen HTML, elemen Meta digunakan untuk menunjukkan pengekodan , yang diletakkan di antara teg Ketua pembukaan dan penutup:
<head>...<meta charset="utf-8">...</head>
Entri ini agak berbeza daripada standard dalam Html 4.01, tetapi mematuhi sepenuhnya standard Html 5, dan ia akan difahami dengan betul oleh mana-mana penyemak imbas yang sedang digunakan. Secara teori, elemen Meta yang menunjukkan pengekodan dokumen Html akan diletakkan setinggi mungkin dalam pengepala dokumen , supaya pada masa teks menemui aksara pertama bukan dari ANSI asas (yang sentiasa dibaca dengan betul dan dalam sebarang variasi), penyemak imbas sepatutnya sudah mempunyai maklumat tentang cara mentafsir kod aksara ini. Pautan ke sumber asal: pengekodan teks ASCII (Windows 1251, CP866, KOI8-R) dan Unicode (UTF 8, 16, 32) - cara menyelesaikan masalah dengan keropok
128 aksara daripada versi asal ASCII inilah yang menjadi standard, dan dalam mana-mana pengekodan lain anda pasti akan menemuinya dan ia akan muncul dalam susunan ini. Tetapi hakikatnya ialah dengan bantuan satu bait maklumat anda boleh mengekod bukan 128, tetapi sebanyak 256 nilai yang berbeza (dua kepada kuasa lapan sama dengan 256), oleh itu, selepas versi asas Asuka, keseluruhan siri pengekodan ASCII lanjutan muncul , di mana ia mungkin, sebagai tambahan kepada 128 aksara asas juga boleh dikodkan menggunakan aksara pengekodan kebangsaan (contohnya, Rusia). Di sini, ia mungkin berbaloi untuk menyatakan lebih banyak tentang sistem nombor yang digunakan dalam penerangan. Pertama, seperti yang anda semua tahu, komputer hanya berfungsi dengan nombor dalam sistem binari, iaitu dengan sifar dan satu (“algebra Boolean”, jika sesiapa mengambilnya di institut atau sekolah). Satu bait terdiri daripada lapan bit, setiap satunya mewakili dua hingga kuasa dua, bermula dari sifar, dan sehingga dua hingga ketujuh: 
Tidak sukar untuk memahami bahawa semua kemungkinan gabungan sifar dan satu dalam pembinaan sedemikian boleh hanya 256. Menukar nombor daripada sistem binari kepada perpuluhan adalah agak mudah. Anda hanya perlu menambah semua kuasa dua dengan kuasa di atasnya. Dalam contoh kami, ini ternyata menjadi 1 (2 kepada kuasa sifar) ditambah 8 (dua kepada kuasa 3), ditambah 32 (dua kepada kuasa kelima), ditambah 64 (kepada kuasa keenam), ditambah 128 (kepada kuasa ketujuh). Jumlahnya ialah 233 dalam tatatanda perpuluhan. Seperti yang anda lihat, semuanya sangat mudah. Tetapi jika anda melihat dengan teliti jadual dengan aksara ASCII, anda akan melihat bahawa ia diwakili dalam pengekodan heksadesimal. Sebagai contoh, "asterisk" sepadan dengan nombor perenambelasan 2A dalam Aski. Anda mungkin tahu bahawa dalam sistem nombor perenambelasan, sebagai tambahan kepada angka Arab, huruf Latin dari A (bermakna sepuluh) hingga F (bermakna lima belas) juga digunakan. Nah, untuk menukar nombor binari kepada perenambelasanmenggunakan kaedah mudah berikut. Setiap bait maklumat dibahagikan kepada dua bahagian empat bit. Itu. Dalam setiap separuh bait, hanya enam belas nilai (dua hingga kuasa keempat) boleh dikodkan dalam binari, yang boleh dengan mudah diwakili sebagai nombor perenambelasan. Selain itu, di separuh kiri bait, darjah perlu dikira semula bermula dari sifar, dan bukan seperti yang ditunjukkan dalam tangkapan skrin. Akibatnya, kami mendapat bahawa nombor E9 dikodkan dalam tangkapan skrin. Saya berharap perjalanan pemikiran saya dan penyelesaian teka-teki ini jelas kepada anda. Nah, sekarang mari kita teruskan, sebenarnya, bercakap tentang pengekodan teks.
Anda lihat, di lajur kanan nombor bermula dengan 8, kerana nombor dari 0 hingga 7 merujuk kepada bahagian asas ASCII (lihat tangkapan skrin pertama). Oleh itu, huruf Cyrillic "M" dalam CP866 akan mempunyai kod 9C (ia terletak di persimpangan baris yang sepadan dengan 9 dan lajur dengan nombor C dalam sistem nombor perenambelasan), yang boleh ditulis dalam satu bait maklumat , dan jika terdapat fon yang sesuai dengan aksara Rusia surat ini akan muncul dalam teks tanpa sebarang masalah. Dari mana datangnya jumlah ini?pseudografik dalam CP866 ? Intinya ialah pengekodan untuk teks Rusia ini telah dibangunkan kembali pada tahun-tahun kelam apabila sistem pengendalian grafik tidak meluas seperti sekarang. Dan dalam Dosa dan sistem pengendalian teks yang serupa, pseudografi membolehkan sekurang-kurangnya entah bagaimana mempelbagaikan reka bentuk teks, dan oleh itu CP866 dan semua rakannya yang lain daripada kategori versi lanjutan Asuka banyak terdapat di dalamnya. CP866 diedarkan oleh IBM, tetapi sebagai tambahan kepada ini, beberapa pengekodan telah dibangunkan untuk aksara bahasa Rusia, sebagai contoh, KOI8-R boleh dikaitkan dengan jenis yang sama (ASCII lanjutan) : 
Prinsip operasinya tetap sama seperti daripada CP866 yang diterangkan lebih awal - Setiap aksara teks dikodkan sebagai satu bait tunggal. Tangkapan skrin menunjukkan separuh kedua jadual KOI8-R, kerana separuh masa pertama benar-benar konsisten dengan Asuka asas, yang ditunjukkan dalam tangkapan skrin pertama dalam artikel ini. Antara ciri pengekodan KOI8-R, boleh diperhatikan bahawa huruf Cyrillic dalam jadualnya tidak dalam susunan abjad, seperti yang dilakukan dalam CP866. Jika anda melihat tangkapan skrin pertama (bahagian asas, yang disertakan dalam semua pengekodan lanjutan), anda akan melihat bahawa dalam KOI8-R huruf Rusia terletak di sel yang sama dalam jadual dengan huruf yang sepadan dalam abjad Latin dari bahagian pertama jadual. Ini dilakukan untuk kemudahan menukar daripada aksara Rusia ke Latin dengan membuang hanya satu bit (dua kepada kuasa ketujuh atau 128).
Disebabkan oleh banyaknya pengekodan bahasa Rusia, pengeluar fon dan pengeluar perisian sentiasa mengalami sakit kepala, dan anda dan saya, pembaca yang dikasihi, sering menghadapi masalah dengan pepijat terkenal yang sama. apabila terdapat kekeliruan dengan versi yang digunakan dalam teks. Selalunya mereka keluar apabila menghantar dan menerima mesej melalui e-mel, yang memerlukan penciptaan jadual penukaran yang sangat kompleks, yang, sebenarnya, tidak dapat menyelesaikan masalah ini secara asas, dan sering pengguna menggunakan transliterasi huruf Latin untuk surat-menyurat untuk elakkan omong kosong yang terkenal apabila menggunakan pengekodan Rusia seperti CP866, KOI8-R atau Windows 1251. Malah, retakan yang muncul dan bukannya teks Rusia adalah akibat daripada penggunaan pengekodan bahasa yang tidak betul, yang tidak sepadan dengan yang terdapat dalam yang mesej teks asalnya dikodkan. Katakan bahawa jika anda cuba memaparkan aksara yang dikodkan menggunakan CP866 menggunakan jadual kod Windows 1251, maka omong kosong yang sama ini (set aksara yang tidak bermakna) akan keluar, menggantikan teks mesej sepenuhnya. 
Situasi yang sama selalunya timbul apabila membuat dan menyediakan tapak web, forum atau blog, apabila teks dengan aksara Rusia tersilap disimpan dalam pengekodan yang salah yang digunakan di tapak secara lalai, atau dalam penyunting teks yang salah, yang menambah gag yang tidak kelihatan. kepada kod dengan mata kasar. Pada akhirnya, ramai orang bosan dengan keadaan ini dengan banyak pengekodan dan sentiasa menjalar keluar omong kosong, dan prasyarat muncul untuk penciptaan variasi universal baharu yang akan menggantikan semua yang sedia ada dan menyelesaikan masalah dengan kemunculan teks yang tidak boleh dibaca . Di samping itu, terdapat masalah bahasa seperti bahasa Cina, di mana terdapat lebih banyak aksara bahasa daripada 256.
Berapakah bilangan aksara yang boleh dikodkan dalam UTF-16 menggunakan 16 bit? 65,536 (dua kepada kuasa enam belas), dan ini ialah nombor yang diterima pakai sebagai ruang asas dalam Unicode. Di samping itu, terdapat cara untuk mengekod kira-kira dua juta aksara menggunakannya, tetapi ia terhad kepada ruang yang diperluaskan dengan sejuta aksara teks. Tetapi walaupun versi pengekodan Unicode yang berjaya ini tidak memberikan banyak kepuasan kepada mereka yang menulis, katakan, program hanya dalam bahasa Inggeris, kerana selepas peralihan daripada versi lanjutan ASCII ke UTF-16, berat dokumen meningkat dua kali ganda (satu bait setiap aksara dalam Aski dan dua bait untuk aksara yang sama dalam YUTF-16). Ia adalah tepat untuk memuaskan hati semua orang dan segala-galanya dalam konsortium Unicode bahawa ia telah memutuskan untuk menghasilkan pengekodan panjang berubah-ubah . Ia dipanggil UTF-8. Walaupun lapan dalam nama, ia sebenarnya mempunyai panjang berubah-ubah, i.e. Setiap aksara teks boleh dikodkan ke dalam urutan satu hingga enam bait panjangnya. Dalam praktiknya, UTF-8 hanya menggunakan julat dari satu hingga empat bait, kerana melebihi empat bait kod ia tidak lagi secara teori mungkin membayangkan apa-apa. Semua aksara Latin di dalamnya dikodkan menjadi satu bait, sama seperti dalam ASCII lama yang baik. Apa yang patut diberi perhatian ialah dalam kes pengekodan hanya abjad Latin, malah program yang tidak memahami Unicode masih akan membaca apa yang dikodkan dalam YTF-8. Iaitu, bahagian asas Asuka hanya dipindahkan kepada idea konsortium Unicode ini. Aksara Cyrillic dalam UTF-8 dikodkan dalam dua bait, dan, sebagai contoh, aksara Georgia dikodkan dalam tiga bait. Konsortium Unicode, selepas mencipta UTF 16 dan 8, menyelesaikan masalah utama - kini kami mempunyai ruang kod tunggal dalam fon kami . Dan kini pengeluar mereka hanya boleh mengisinya dengan bentuk vektor aksara teks berdasarkan kekuatan dan keupayaan mereka. Dalam "Jadual Aksara" di atas anda boleh melihat bahawa fon berbeza menyokong bilangan aksara yang berbeza. Sesetengah fon kaya Unicode boleh menjadi agak berat. Tetapi kini mereka berbeza bukan pada hakikat bahawa ia dicipta untuk pengekodan yang berbeza, tetapi pada hakikat bahawa pengeluar fon telah mengisi atau tidak sepenuhnya mengisi ruang kod tunggal dengan bentuk vektor tertentu.
Dalam kes tapak di Joomla 1.5 dan lebih tinggi, seperti dan juga dalam kes blog di WordPress, anda harus mengelakkan penampilan Krakozyabrov memilih pilihan UTF 8 tanpa BOM . Apakah awalan BOM? Hakikatnya ialah apabila mereka membangunkan pengekodan YUTF-16, atas sebab tertentu mereka memutuskan untuk melampirkan padanya perkara seperti keupayaan untuk menulis kod aksara kedua-duanya dalam urutan langsung (contohnya, 0A15) dan sebaliknya (150A) . Dan untuk program memahami dalam urutan apa untuk membaca kod, BOM (Byte Order Mark atau, dengan kata lain, tandatangan) telah dicipta, yang dinyatakan dalam menambah tiga bait tambahan pada permulaan dokumen. Dalam pengekodan UTF-8, tiada BOM disediakan dalam konsortium Unicode, dan oleh itu menambah tandatangan (tiga bait tambahan yang terkenal pada permulaan dokumen) hanya menghalang beberapa program daripada membaca kod. Oleh itu, apabila menyimpan fail dalam UTF, kita mesti sentiasa memilih pilihan tanpa BOM (tanpa tandatangan). Oleh itu, anda akan melindungi diri anda terlebih dahulu daripada merangkak keluar dari krakozyabrs . Apa yang patut diberi perhatian ialah sesetengah program dalam Windows tidak boleh melakukan ini (mereka tidak boleh menyimpan teks dalam UTF-8 tanpa BOM), sebagai contoh, Windows Notepad yang sama terkenal. Ia menyimpan dokumen dalam UTF-8, tetapi masih menambah tandatangan (tiga bait tambahan) pada permulaannya. Selain itu, bait ini akan sentiasa sama - baca kod dalam urutan langsung. Tetapi pada pelayan, kerana perkara kecil ini, masalah boleh timbul - penyangak akan keluar. Oleh itu, jangan gunakan notepad Windows biasa dalam apa jua keadaan.untuk mengedit dokumen di tapak anda jika anda tidak mahu sebarang retakan muncul. Saya menganggap editor Notepad++ yang telah disebutkan sebagai pilihan terbaik dan paling mudah, yang hampir tidak mempunyai kelemahan dan hanya terdiri daripada kelebihan. Dalam Notepad++, apabila anda memilih pengekodan, anda akan mempunyai pilihan untuk menukar teks kepada pengekodan UCS-2, yang sangat hampir dengan standard Unicode. Juga dalam Notepad adalah mungkin untuk mengekod teks dalam ANSI, i.e. berhubung dengan bahasa Rusia, ini ialah Windows 1251, yang telah kami jelaskan di atas. Dari manakah maklumat ini datang? Ia didaftarkan dalam pendaftaran sistem pengendalian Windows anda - pengekodan yang perlu dipilih dalam kes ANSI, yang perlu dipilih dalam kes OEM (untuk bahasa Rusia ia akan menjadi CP866). Jika anda menetapkan bahasa lalai lain pada komputer anda, maka pengekodan ini akan digantikan dengan yang serupa daripada kategori ANSI atau OEM untuk bahasa yang sama itu. Selepas anda menyimpan dokumen dalam Notepad++ dalam pengekodan yang anda perlukan atau membuka dokumen daripada tapak untuk pengeditan, anda akan dapat melihat namanya di sudut kanan bawah editor: 
Untuk mengelakkan kekeliruan , sebagai tambahan kepada langkah yang diterangkan di atas , adalah berguna untuk menulis kod sumber dalam pengepalanya semua halaman maklumat tapak tentang pengekodan ini, supaya tiada kekeliruan pada pelayan atau hos tempatan. Secara umum, semua bahasa penanda hiperteks kecuali Html menggunakan pengisytiharan xml khas, yang menentukan pengekodan teks.
GO TO FULL VERSION