Ngayon ay pag-uusapan natin kung saan nanggaling ang mga krakozyabr sa isang website at sa mga programa, kung anong mga text encoding ang umiiral at kung alin ang dapat gamitin. Tingnan natin ang kasaysayan ng kanilang pag-unlad, simula sa pangunahing ASCII, pati na rin ang mga pinahabang bersyon nito na CP866, KOI8-R, Windows 1251 at nagtatapos sa modernong Unicode consortium encodings na UTF 16 at 8. Talaan ng mga nilalaman:
Para sa ilan, maaaring mukhang hindi kailangan ang impormasyong ito, ngunit malalaman mo ba kung gaano karaming mga tanong ang natatanggap ko partikular tungkol sa mga gumagapang na krakozyabrs (hindi nababasang hanay ng mga character). Ngayon ay magkakaroon ako ng pagkakataon na i-refer ang lahat sa teksto ng artikulong ito at hanapin ang sarili kong mga pagkakamali. Buweno, humanda sa pagsipsip ng impormasyon at subukang sundan ang daloy ng kuwento.
ASCII - pangunahing pag-encode ng teksto para sa alpabetong Latin
Ang pag-unlad ng mga pag-encode ng teksto ay naganap nang sabay-sabay sa pagbuo ng industriya ng IT, at sa panahong ito ay nakaranas sila ng maraming pagbabago. Sa kasaysayan, nagsimula ang lahat sa EBCDIC, na medyo dissonant sa pagbigkas ng Ruso, na naging posible na i-encode ang mga titik ng alpabetong Latin, mga numerong Arabe at mga bantas na may mga control character. Gayunpaman, ang panimulang punto para sa pagbuo ng mga modernong pag-encode ng teksto ay dapat isaalang-alang ang sikat na ASCII (American Standard Code for Information Interchange, na sa Russian ay karaniwang binibigkas bilang "magtanong"). Inilalarawan nito ang unang 128 character na pinakakaraniwang ginagamit ng mga user na nagsasalita ng Ingles - mga letrang Latin, Arabic numeral at mga bantas. Kasama rin sa 128 character na ito na inilalarawan sa ASCII ang ilang character ng serbisyo gaya ng mga bracket, hash mark, asterisk, atbp. Sa katunayan, makikita mo mismo ang mga ito: Ang 128 character na ito mula sa orihinal na bersyon ng ASCII ang naging pamantayan, at sa anumang iba pang pag-encode ay tiyak na mahahanap mo ang mga ito at lilitaw ang mga ito sa ganitong pagkakasunud-sunod. Ngunit ang katotohanan ay sa tulong ng isang byte ng impormasyon maaari kang mag-encode hindi 128, ngunit kasing dami ng 256 iba't ibang mga halaga (dalawa sa kapangyarihan ng walong katumbas ng 256), samakatuwid, pagkatapos ng pangunahing bersyon ng Asuka, isang buo lumitaw ang serye ng mga pinahabang pag-encode ng ASCII , kung saan posible, bilang karagdagan sa 128 pangunahing mga character ay maaari ding i-encode gamit ang mga pambansang encoding na character (halimbawa, Russian). Dito, marahil ay nagkakahalaga ng pagsasabi ng kaunti pa tungkol sa mga sistema ng numero na ginagamit sa paglalarawan. Una, tulad ng alam mo, ang isang computer ay gumagana lamang sa mga numero sa binary system, katulad ng mga zero at isa ("Boolean algebra", kung sinuman ang kumuha nito sa isang institute o paaralan). Ang isang byte ay binubuo ng walong bits, na ang bawat isa ay kumakatawan sa dalawa hanggang sa kapangyarihan ng dalawa, simula sa zero, at hanggang dalawa hanggang sa ikapito: Hindi mahirap maunawaan na ang lahat ng posibleng kumbinasyon ng mga zero at isa sa naturang konstruksiyon ay maaaring maging 256 lamang. I-convert ang isang numero mula sa binary system sa decimal ay medyo simple. Kailangan mo lang idagdag ang lahat ng kapangyarihan ng dalawa na may mga nasa itaas nila. Sa aming halimbawa, ito ay lumalabas na 1 (2 sa kapangyarihan ng zero) plus 8 (dalawa sa kapangyarihan ng 3), plus 32 (dalawa hanggang sa ikalimang kapangyarihan), plus 64 (sa ikaanim na kapangyarihan), plus 128 (sa ikapitong kapangyarihan). Ang kabuuan ay 233 sa decimal notation. Tulad ng nakikita mo, ang lahat ay napaka-simple. Ngunit kung titingnan mo nang mabuti ang talahanayan na may mga character na ASCII, makikita mo na ang mga ito ay kinakatawan sa hexadecimal encoding. Halimbawa, ang "asterisk" ay tumutugma sa hexadecimal number 2A sa Aski. Malamang alam mo na sa sistema ng numerong hexadecimal, bilang karagdagan sa mga numerong Arabe, ginagamit din ang mga letrang Latin mula A (nangangahulugang sampu) hanggang F (nangangahulugang labinlimang). Well, upang i-convert ang isang binary number sa hexadecimalgumamit ng sumusunod na simpleng pamamaraan. Ang bawat byte ng impormasyon ay nahahati sa dalawang bahagi ng apat na bits. Yung. Sa bawat kalahating byte, labing-anim na halaga lamang (dalawa hanggang ika-apat na kapangyarihan) ang maaaring ma-encode sa binary, na madaling maipakita bilang isang hexadecimal na numero. Bukod dito, sa kaliwang kalahati ng byte, ang mga degree ay kailangang mabilang muli simula sa zero, at hindi tulad ng ipinapakita sa screenshot. Bilang resulta, nakuha namin na ang numero E9 ay naka-encode sa screenshot. Umaasa ako na ang takbo ng aking pangangatwiran at ang solusyon sa palaisipang ito ay naging malinaw sa iyo. Well, ngayon magpatuloy tayo, sa katunayan, ang pakikipag-usap tungkol sa mga text encoding.
Mga pinahabang bersyon ng Asuka - CP866 at KOI8-R encoding na may pseudographics
Kaya, nagsimula kaming pag-usapan ang tungkol sa ASCII, na kung saan ay, tulad nito, ang panimulang punto para sa pagbuo ng lahat ng mga modernong pag-encode (Windows 1251, Unicode, UTF 8). Sa una, naglalaman lamang ito ng 128 na mga character ng alpabetong Latin, mga numerong Arabe at iba pa, ngunit sa pinalawak na bersyon naging posible na gamitin ang lahat ng 256 na halaga na maaaring ma-encode sa isang byte ng impormasyon. Yung. Naging posible na magdagdag ng mga simbolo ng mga titik ng iyong wika sa Aski. Dito kailangan nating lumihis muli upang ipaliwanag kung bakit kailangan ang mga text encoding at kung bakit ito napakahalaga. Ang mga character sa screen ng iyong computer ay nabuo batay sa dalawang bagay - mga hanay ng mga hugis ng vector (mga representasyon) ng iba't ibang mga character (ang mga ito ay nasa mga file na may mga font na naka-install sa iyong computer) at code na nagbibigay-daan sa iyong ilabas nang eksakto ang isang iyon. mula sa set na ito ng mga hugis ng vector (font file). simbolo na kakailanganing ilagay sa tamang lugar. Malinaw na ang mga font mismo ang may pananagutan para sa mga hugis ng vector, ngunit ang operating system at ang mga program na ginamit dito ay responsable para sa pag-encode. Yung. anumang text sa iyong computer ay magiging isang set ng mga byte, na ang bawat isa ay nag-e-encode ng isang character ng mismong text na ito. Ang program na nagpapakita ng tekstong ito sa screen (text editor, browser, atbp.), Kapag nag-parse ng code, binabasa ang pag-encode ng susunod na character at hinahanap ang kaukulang vector form sa kinakailangang font file, na konektado upang ipakita ito tekstong dokumento. Ang lahat ay simple at karaniwan. Nangangahulugan ito na para ma-encode ang anumang character na kailangan namin (halimbawa, mula sa pambansang alpabeto), dalawang kundisyon ang dapat matugunan: ang vector form ng character na ito ay dapat nasa font na ginamit, at ang character na ito ay maaaring ma-encode sa pinahabang ASCII encodings sa isang byte. Samakatuwid, mayroong isang buong grupo ng mga naturang pagpipilian. Para lamang sa pag-encode ng mga character sa wikang Ruso, mayroong ilang uri ng pinahabang Aska. Halimbawa, orihinal na lumitaw ang CP866 , na may kakayahang gumamit ng mga character mula sa alpabetong Ruso, at ito ay isang pinahabang bersyon ng ASCII. Iyon ay, ang itaas na bahagi nito ay ganap na nag-tutugma sa pangunahing bersyon ng Aska (128 Latin na mga character, numero at iba pang crap), na ipinakita sa screenshot sa itaas lamang, ngunit ang ibabang bahagi ng talahanayan na may CP866 encoding ay may hitsura na ipinahiwatig sa screenshot sa ibaba lamang at pinapayagang mag-encode ng isa pang 128 character (mga letrang Ruso at lahat ng uri ng pseudo-graphics): Nakikita mo, sa kanang hanay ang mga numero ay nagsisimula sa 8, dahil ang mga numero mula 0 hanggang 7 ay tumutukoy sa pangunahing bahagi ng ASCII (tingnan ang unang screenshot). Kaya, ang Cyrillic letter na "M" sa CP866 ay magkakaroon ng code 9C (matatagpuan ito sa intersection ng kaukulang linya na may 9 at column na may numero C sa hexadecimal number system), na maaaring isulat sa isang byte ng impormasyon. , at kung mayroong angkop na font na may mga Russian na character ay lilitaw ang liham na ito sa teksto nang walang anumang mga problema. Saan nanggaling ang halagang ito?pseudographics sa CP866 ? Ang buong punto ay ang pag-encode na ito para sa tekstong Ruso ay binuo noong mga malabo na taon na ang mga graphical na operating system ay hindi laganap tulad ng mga ito ngayon. At sa Dosa at katulad na mga operating system ng teksto, ginawang posible ng mga pseudographic na kahit papaano ay pag-iba-ibahin ang disenyo ng mga teksto, at samakatuwid ay marami ang CP866 at lahat ng iba pang mga kapantay nito mula sa kategorya ng mga pinahabang bersyon ng Asuka. Ang CP866 ay ipinamahagi ng IBM, ngunit bilang karagdagan dito, ang isang bilang ng mga pag-encode ay binuo para sa mga character ng wikang Ruso, halimbawa, ang KOI8-R ay maaaring maiugnay sa parehong uri (pinalawak na ASCII) : Ang prinsipyo ng operasyon nito ay nananatiling pareho sa na sa CP866 na inilarawan nang mas maaga - Ang bawat karakter ng teksto ay naka-encode bilang isang solong byte. Ipinapakita ng screenshot ang ikalawang kalahati ng talahanayan ng KOI8-R, dahil ang unang kalahati ay ganap na pare-pareho sa pangunahing Asuka, na ipinapakita sa unang screenshot sa artikulong ito. Kabilang sa mga tampok ng pag-encode ng KOI8-R, mapapansin na ang mga Cyrillic na titik sa talahanayan nito ay wala sa pagkakasunud-sunod ng alpabeto, tulad ng ginawa sa CP866. Kung titingnan mo ang pinakaunang screenshot (ng pangunahing bahagi, na kasama sa lahat ng pinalawak na pag-encode), mapapansin mo na sa KOI8-R ang mga letrang Ruso ay matatagpuan sa parehong mga cell ng talahanayan bilang ang kaukulang mga titik ng alpabetong Latin. mula sa unang bahagi ng talahanayan. Ginawa ito para sa kaginhawaan ng paglipat mula sa Russian patungo sa Latin na mga character sa pamamagitan ng pag-discard ng isang bit lamang (dalawa hanggang sa ikapitong kapangyarihan o 128).
Windows 1251 - ang modernong bersyon ng ASCII at kung bakit lumalabas ang mga bitak
Ang karagdagang pag-unlad ng mga pag-encode ng teksto ay dahil sa ang katunayan na ang mga graphical na operating system ay nakakakuha ng katanyagan at ang pangangailangan na gumamit ng mga pseudographic sa mga ito ay nawala sa paglipas ng panahon. Bilang resulta, bumangon ang isang buong grupo na, sa esensya, ay mga pinahabang bersyon pa rin ng Asuka (isang karakter ng teksto ay naka-encode ng isang byte lamang ng impormasyon), ngunit walang paggamit ng mga pseudographic na simbolo. Nabibilang sila sa tinatawag na ANSI encodings, na binuo ng American Standards Institute. Sa karaniwang pananalita, ginamit din ang pangalang Cyrillic para sa bersyon na may suporta sa wikang Ruso. Ang isang halimbawa nito ay ang Windows 1251 . Naiiba ito sa dating ginamit na CP866 at KOI8-R na ang lugar ng mga pseudographic na simbolo dito ay kinuha ng mga nawawalang simbolo ng Russian typography (maliban sa accent mark), pati na rin ang mga simbolo na ginamit sa Slavic na mga wika malapit sa Russian (Ukrainian, Belarusian, atbp.). ): Dahil sa napakaraming pag-encode ng wikang Ruso, ang mga tagagawa ng font at mga tagagawa ng software ay patuloy na sumasakit ng ulo, at ikaw at ako, mahal na mga mambabasa, ay madalas na nagkakaproblema sa parehong kilalang mga bug . kapag nagkaroon ng kalituhan sa bersyon na ginamit sa teksto. Kadalasan ay lumabas sila kapag nagpapadala at tumatanggap ng mga mensahe sa pamamagitan ng e-mail, na nagsasangkot ng paglikha ng napaka-komplikadong mga talahanayan ng conversion, na, sa katunayan, ay hindi malulutas ang problemang ito sa panimula, at kadalasan ang mga gumagamit ay gumagamit ng transliterasyon ng mga titik na Latin para sa pagsusulatan upang iwasan ang kilalang daldal kapag gumagamit ng mga Russian encoding tulad ng CP866, KOI8-R o Windows 1251. Sa katunayan, ang mga crack na lumilitaw sa halip na Russian text ay resulta ng maling paggamit ng pag-encode ng isang partikular na wika, na hindi tumutugma sa isa sa kung saan ang text message ay orihinal na naka-encode. Sabihin nating kung susubukan mong magpakita ng mga character na naka-encode gamit ang CP866 gamit ang Windows 1251 code table, lalabas ang parehong mga walang kwentang set ng character na ito, na ganap na papalitan ang text ng mensahe. Ang isang katulad na sitwasyon ay madalas na lumitaw kapag lumilikha at nagse-set up ng mga website, forum o blog, kapag ang teksto na may mga Russian na character ay maling nai-save sa maling pag-encode na ginamit sa site bilang default, o sa maling text editor, na nagdaragdag ng hindi nakikitang gag. sa code sa mata. Sa huli, maraming mga tao ang napagod sa sitwasyong ito na may maraming mga pag-encode at patuloy na gumagapang ng crap, at ang mga kinakailangan ay lumitaw para sa paglikha ng isang bagong unibersal na pagkakaiba-iba na papalitan ang lahat ng mga umiiral na at malulutas ang problema sa hitsura ng hindi nababasa na mga teksto . Bilang karagdagan, nagkaroon ng problema sa mga wika tulad ng Chinese, kung saan mayroong higit pang mga character ng wika kaysa sa 256.
Unicode - mga unibersal na encoding na UTF 8, 16 at 32
Ang libu-libong character na ito ng pangkat ng wika sa Southeast Asia ay hindi maaaring ilarawan sa isang byte ng impormasyon na inilaan para sa pag-encode ng mga character sa mga pinahabang bersyon ng ASCII. Bilang resulta, nilikha ang isang consortium na tinatawag na Unicode (Unicode Consortium) sa pakikipagtulungan ng maraming pinuno ng industriya ng IT (mga gumagawa ng software, na nag-encode ng hardware, na gumagawa ng mga font) na interesado sa paglitaw ng isang unibersal na pag-encode ng teksto. Ang unang variation na inilabas sa ilalim ng auspice ng Unicode Consortium ay UTF 32 . Ang numero sa pangalan ng pag-encode ay nangangahulugang ang bilang ng mga bit na ginagamit upang mag-encode ng isang character. Ang 32 bits ay katumbas ng 4 na byte ng impormasyon na kakailanganin para mag-encode ng isang character sa bagong unibersal na UTF encoding. Bilang resulta, ang parehong file na may text na naka-encode sa pinalawig na bersyon ng ASCII at sa UTF-32, sa huling kaso, ay magkakaroon ng sukat (timbang) ng apat na beses na mas malaki. Ito ay masama, ngunit ngayon ay mayroon kaming pagkakataon na mag-encode gamit ang UTF ng isang bilang ng mga character na katumbas ng dalawa hanggang sa tatlumpu't segundong kapangyarihan ( bilyun-bilyong mga character na sasakupin ang anumang talagang kinakailangang halaga na may napakalaking margin). Ngunit maraming mga bansa na may mga wika ng pangkat ng Europa ay hindi kailangang gumamit ng napakalaking bilang ng mga character sa pag-encode, gayunpaman, kapag gumagamit ng UTF-32, sila ay walang dahilan na nakatanggap ng apat na beses na pagtaas sa bigat ng mga dokumento ng teksto, at bilang resulta, isang pagtaas sa dami ng trapiko sa Internet at dami ng nakaimbak na data. Ito ay marami, at walang sinuman ang makakaya ng ganoong basura. Bilang resulta ng pag-unlad ng Unicode, lumitaw ang UTF-16 , na naging matagumpay kaya ito ay pinagtibay bilang default bilang base space para sa lahat ng mga character na ginagamit namin. Gumagamit ito ng dalawang byte para i-encode ang isang character. Tingnan natin kung ano ang hitsura ng bagay na ito. Sa Windows operating system, maaari mong sundin ang landas na "Start" - "Programs" - "Accessories" - "System Tools" - "Character Table". Bilang resulta, magbubukas ang isang talahanayan na may mga hugis ng vector ng lahat ng mga font na naka-install sa iyong system. Kung pipiliin mo ang Unicode character set sa "Mga advanced na opsyon", makikita mo para sa bawat font nang hiwalay ang buong hanay ng mga character na kasama dito. Sa pamamagitan ng paraan, sa pamamagitan ng pag-click sa alinman sa mga ito, makikita mo ang two-byte code nito sa format na UTF-16 , na binubuo ng apat na hexadecimal na digit: Ilang character ang maaaring ma-encode sa UTF-16 gamit ang 16 bits? 65,536 (dalawa sa kapangyarihan ng labing-anim), at ito ang numero na pinagtibay bilang base space sa Unicode. Bilang karagdagan, may mga paraan para mag-encode ng humigit-kumulang dalawang milyong character gamit ito, ngunit limitado ang mga ito sa pinalawak na espasyo ng isang milyong character ng teksto. Ngunit kahit na ang matagumpay na bersyong ito ng Unicode encoding ay hindi nagdulot ng labis na kasiyahan sa mga sumulat, halimbawa, mga programa lamang sa Ingles, dahil pagkatapos ng paglipat mula sa pinahabang bersyon ng ASCII hanggang UTF-16, ang bigat ng mga dokumento ay nadoble (isang byte bawat character sa Aski at dalawang byte para sa parehong karakter sa YUTF-16). Ito ay tiyak upang masiyahan ang lahat at lahat ng bagay sa Unicode consortium na napagpasyahan na magkaroon ng isang variable na haba ng encoding . Tinawag itong UTF-8. Sa kabila ng walo sa pangalan, mayroon talaga itong variable na haba, i.e. Ang bawat karakter ng teksto ay maaaring i-encode sa isang pagkakasunud-sunod ng isa hanggang anim na byte ang haba. Sa pagsasagawa, ginagamit lamang ng UTF-8 ang hanay mula isa hanggang apat na byte, dahil higit sa apat na byte ng code ay hindi na posible na isipin ang anuman. Ang lahat ng Latin na character dito ay naka-encode sa isang byte, tulad ng sa magandang lumang ASCII. Ang kapansin-pansin ay sa kaso ng pag-encode lamang ng alpabetong Latin, kahit na ang mga programang iyon na hindi nakakaunawa sa Unicode ay magbabasa pa rin kung ano ang naka-encode sa YTF-8. Iyon ay, ang pangunahing bahagi ng Asuka ay inilipat lamang sa ideyang ito ng Unicode consortium. Ang mga cyrillic na character sa UTF-8 ay naka-encode sa dalawang byte, at, halimbawa, ang mga Georgian na character ay naka-encode sa tatlong byte. Ang Unicode Consortium, pagkatapos lumikha ng UTF 16 at 8, ay nalutas ang pangunahing problema - ngayon ay mayroon na kaming isang puwang ng code sa aming mga font . At ngayon ang kanilang mga tagagawa ay maaari lamang punan ito ng mga vector form ng mga character ng teksto batay sa kanilang mga lakas at kakayahan. Sa "Character Table" sa itaas makikita mo na ang iba't ibang font ay sumusuporta sa iba't ibang bilang ng mga character. Ang ilang mga font na mayaman sa Unicode ay maaaring maging mabigat. Ngunit ngayon sila ay naiiba hindi sa katotohanan na sila ay nilikha para sa iba't ibang mga pag-encode, ngunit sa katotohanan na ang tagagawa ng font ay napunan o hindi ganap na napunan ang solong puwang ng code na may ilang mga vector form.
Mga nakatutuwang salita sa halip na mga letrang Ruso - kung paano ito ayusin
Tingnan natin ngayon kung paano lumilitaw ang mga krakozyabrs sa halip na teksto o, sa madaling salita, kung paano napili ang tamang pag-encode para sa Russian text. Sa totoo lang, ito ay nakatakda sa programa kung saan mo nilikha o i-edit ang mismong tekstong ito, o code gamit ang mga fragment ng teksto. Upang i-edit at lumikha ng mga text file, personal akong gumagamit ng isang napakahusay, sa aking opinyon, Html at PHP editor Notepad++ . Gayunpaman, maaari nitong i-highlight ang syntax ng daan-daang iba pang mga programming at markup na wika, at mayroon ding kakayahang palawigin gamit ang mga plugin. Basahin ang isang detalyadong pagsusuri ng kahanga-hangang programang ito sa ibinigay na link. Sa tuktok na menu ng Notepad++ mayroong isang item na "Mga Pag-encode", kung saan magkakaroon ka ng pagkakataong i-convert ang isang umiiral na opsyon sa isa na ginagamit sa iyong site bilang default: Sa kaso ng isang site sa Joomla 1.5 at mas mataas, bilang pati na rin sa kaso ng isang blog sa WordPress, dapat mong iwasan ang hitsura Krakozyabrov piliin ang UTF 8 opsyon na walang BOM . Ano ang prefix ng BOM? Ang katotohanan ay kapag sila ay bumubuo ng YUTF-16 encoding, sa ilang kadahilanan ay nagpasya silang ilakip dito ang isang bagay tulad ng kakayahang isulat ang code ng character kapwa sa direktang pagkakasunud-sunod (halimbawa, 0A15) at sa kabaligtaran (150A) . At upang maunawaan ng mga programa kung anong pagkakasunud-sunod na basahin ang mga code, ang BOM (Byte Order Mark o, sa madaling salita, lagda) ay naimbento, na ipinahayag sa pagdaragdag ng tatlong karagdagang mga byte sa pinakadulo simula ng mga dokumento. Sa pag-encode ng UTF-8, walang BOM na ibinigay para sa Unicode consortium, at samakatuwid ang pagdaragdag ng isang pirma (mga kilalang-kilalang dagdag na tatlong byte sa simula ng dokumento) ay pinipigilan lamang ang ilang mga programa sa pagbabasa ng code. Samakatuwid, kapag nagse-save ng mga file sa UTF, dapat nating palaging piliin ang opsyon na walang BOM (walang pirma). Kaya, protektahan mo ang iyong sarili nang maaga mula sa pag-crawl palabas ng krakozyabrs . Ang kapansin-pansin ay ang ilang mga programa sa Windows ay hindi maaaring gawin ito (hindi nila mai-save ang teksto sa UTF-8 nang walang BOM), halimbawa, ang parehong kilalang Windows Notepad. Ini-save nito ang dokumento sa UTF-8, ngunit nagdaragdag pa rin ng lagda (tatlong dagdag na byte) sa simula nito. Bukod dito, ang mga byte na ito ay palaging magiging pareho - basahin ang code sa direktang pagkakasunod-sunod. Ngunit sa mga server, dahil sa maliit na bagay na ito, maaaring magkaroon ng problema - lalabas ang mga manloloko. Samakatuwid, huwag gumamit ng regular na Windows Notepad sa anumang sitwasyon.upang i-edit ang mga dokumento sa iyong site kung ayaw mong lumitaw ang anumang mga bitak. Itinuturing kong ang nabanggit na Notepad++ editor ay ang pinakamahusay at pinakasimpleng opsyon, na halos walang mga disbentaha at binubuo lamang ng mga pakinabang. Sa Notepad++, kapag pumili ka ng encoding, magkakaroon ka ng opsyong i-convert ang text sa UCS-2 encoding, na napakalapit sa Unicode standard. Gayundin sa Notepad posible na mag-encode ng teksto sa ANSI, i.e. kaugnay ng wikang Ruso, ito ay magiging Windows 1251, na inilarawan na namin sa itaas. Saan nagmula ang impormasyong ito? Ito ay nakarehistro sa registry ng iyong Windows operating system - kung saan ang pag-encode ay pipiliin sa kaso ng ANSI, na pipiliin sa kaso ng OEM (para sa wikang Ruso ito ay magiging CP866). Kung magtatakda ka ng isa pang default na wika sa iyong computer, ang mga pag-encode na ito ay papalitan ng mga katulad na mula sa kategorya ng ANSI o OEM para sa parehong wika. Pagkatapos mong i-save ang dokumento sa Notepad++ sa pag-encode na kailangan mo o buksan ang dokumento mula sa site para sa pag-edit, makikita mo ang pangalan nito sa kanang sulok sa ibaba ng editor: Upang maiwasan ang pagkalito , bilang karagdagan sa mga hakbang na inilarawan sa itaas , magiging kapaki-pakinabang na isulat ang source code sa header nito sa lahat ng pahina ng impormasyon ng site tungkol sa mismong pag-encode na ito, upang walang kalituhan sa server o lokal na host. Sa pangkalahatan, ang lahat ng hypertext markup language maliban sa Html ay gumagamit ng isang espesyal na deklarasyon ng xml, na tumutukoy sa pag-encode ng teksto.
<?xml version="1.0" encoding="windows-1251"?>
Bago i-parse ang code, alam ng browser kung aling bersyon ang ginagamit at kung paano eksaktong kailangan nitong bigyang-kahulugan ang mga code ng character ng wikang iyon. Ngunit ang kapansin-pansin ay kung ise-save mo ang dokumento sa default na Unicode, ang xml declaration na ito ay maaaring tanggalin (ang pag-encode ay ituturing na UTF-8 kung walang BOM o UTF-16 kung mayroong BOM). Sa kaso ng isang HTML na dokumento, ang Meta element ay ginagamit upang ipahiwatig ang pag-encode , na inilalagay sa pagitan ng pagbubukas at pagsasara ng Head tag:
<head>...<meta charset="utf-8">...</head>
Ang entry na ito ay medyo naiiba sa pamantayan sa Html 4.01, ngunit ganap na sumusunod sa pamantayan ng Html 5, at ito ay mauunawaan ng tama ng anumang mga browser na kasalukuyang ginagamit. Sa teorya, ang elementong Meta na nagsasaad ng pag-encode ng Html na dokumento ay mas mainam na mailagay nang mataas hangga't maaari sa header ng dokumento , upang sa oras na matugunan ng teksto ang unang character na hindi mula sa pangunahing ANSI (na palaging binabasa nang tama at nasa anumang pagkakaiba-iba), ang browser ay dapat mayroon nang impormasyon tungkol sa kung paano binibigyang kahulugan ang mga code ng mga character na ito. Link sa orihinal na pinagmulan: ASCII text encoding (Windows 1251, CP866, KOI8-R) at Unicode (UTF 8, 16, 32) - kung paano ayusin ang problema sa crackers
Ang 128 character na ito mula sa orihinal na bersyon ng ASCII ang naging pamantayan, at sa anumang iba pang pag-encode ay tiyak na mahahanap mo ang mga ito at lilitaw ang mga ito sa ganitong pagkakasunud-sunod. Ngunit ang katotohanan ay sa tulong ng isang byte ng impormasyon maaari kang mag-encode hindi 128, ngunit kasing dami ng 256 iba't ibang mga halaga (dalawa sa kapangyarihan ng walong katumbas ng 256), samakatuwid, pagkatapos ng pangunahing bersyon ng Asuka, isang buo lumitaw ang serye ng mga pinahabang pag-encode ng ASCII , kung saan posible, bilang karagdagan sa 128 pangunahing mga character ay maaari ding i-encode gamit ang mga pambansang encoding na character (halimbawa, Russian). Dito, marahil ay nagkakahalaga ng pagsasabi ng kaunti pa tungkol sa mga sistema ng numero na ginagamit sa paglalarawan. Una, tulad ng alam mo, ang isang computer ay gumagana lamang sa mga numero sa binary system, katulad ng mga zero at isa ("Boolean algebra", kung sinuman ang kumuha nito sa isang institute o paaralan). Ang isang byte ay binubuo ng walong bits, na ang bawat isa ay kumakatawan sa dalawa hanggang sa kapangyarihan ng dalawa, simula sa zero, at hanggang dalawa hanggang sa ikapito: 
Hindi mahirap maunawaan na ang lahat ng posibleng kumbinasyon ng mga zero at isa sa naturang konstruksiyon ay maaaring maging 256 lamang. I-convert ang isang numero mula sa binary system sa decimal ay medyo simple. Kailangan mo lang idagdag ang lahat ng kapangyarihan ng dalawa na may mga nasa itaas nila. Sa aming halimbawa, ito ay lumalabas na 1 (2 sa kapangyarihan ng zero) plus 8 (dalawa sa kapangyarihan ng 3), plus 32 (dalawa hanggang sa ikalimang kapangyarihan), plus 64 (sa ikaanim na kapangyarihan), plus 128 (sa ikapitong kapangyarihan). Ang kabuuan ay 233 sa decimal notation. Tulad ng nakikita mo, ang lahat ay napaka-simple. Ngunit kung titingnan mo nang mabuti ang talahanayan na may mga character na ASCII, makikita mo na ang mga ito ay kinakatawan sa hexadecimal encoding. Halimbawa, ang "asterisk" ay tumutugma sa hexadecimal number 2A sa Aski. Malamang alam mo na sa sistema ng numerong hexadecimal, bilang karagdagan sa mga numerong Arabe, ginagamit din ang mga letrang Latin mula A (nangangahulugang sampu) hanggang F (nangangahulugang labinlimang). Well, upang i-convert ang isang binary number sa hexadecimalgumamit ng sumusunod na simpleng pamamaraan. Ang bawat byte ng impormasyon ay nahahati sa dalawang bahagi ng apat na bits. Yung. Sa bawat kalahating byte, labing-anim na halaga lamang (dalawa hanggang ika-apat na kapangyarihan) ang maaaring ma-encode sa binary, na madaling maipakita bilang isang hexadecimal na numero. Bukod dito, sa kaliwang kalahati ng byte, ang mga degree ay kailangang mabilang muli simula sa zero, at hindi tulad ng ipinapakita sa screenshot. Bilang resulta, nakuha namin na ang numero E9 ay naka-encode sa screenshot. Umaasa ako na ang takbo ng aking pangangatwiran at ang solusyon sa palaisipang ito ay naging malinaw sa iyo. Well, ngayon magpatuloy tayo, sa katunayan, ang pakikipag-usap tungkol sa mga text encoding.
Nakikita mo, sa kanang hanay ang mga numero ay nagsisimula sa 8, dahil ang mga numero mula 0 hanggang 7 ay tumutukoy sa pangunahing bahagi ng ASCII (tingnan ang unang screenshot). Kaya, ang Cyrillic letter na "M" sa CP866 ay magkakaroon ng code 9C (matatagpuan ito sa intersection ng kaukulang linya na may 9 at column na may numero C sa hexadecimal number system), na maaaring isulat sa isang byte ng impormasyon. , at kung mayroong angkop na font na may mga Russian na character ay lilitaw ang liham na ito sa teksto nang walang anumang mga problema. Saan nanggaling ang halagang ito?pseudographics sa CP866 ? Ang buong punto ay ang pag-encode na ito para sa tekstong Ruso ay binuo noong mga malabo na taon na ang mga graphical na operating system ay hindi laganap tulad ng mga ito ngayon. At sa Dosa at katulad na mga operating system ng teksto, ginawang posible ng mga pseudographic na kahit papaano ay pag-iba-ibahin ang disenyo ng mga teksto, at samakatuwid ay marami ang CP866 at lahat ng iba pang mga kapantay nito mula sa kategorya ng mga pinahabang bersyon ng Asuka. Ang CP866 ay ipinamahagi ng IBM, ngunit bilang karagdagan dito, ang isang bilang ng mga pag-encode ay binuo para sa mga character ng wikang Ruso, halimbawa, ang KOI8-R ay maaaring maiugnay sa parehong uri (pinalawak na ASCII) : 
Ang prinsipyo ng operasyon nito ay nananatiling pareho sa na sa CP866 na inilarawan nang mas maaga - Ang bawat karakter ng teksto ay naka-encode bilang isang solong byte. Ipinapakita ng screenshot ang ikalawang kalahati ng talahanayan ng KOI8-R, dahil ang unang kalahati ay ganap na pare-pareho sa pangunahing Asuka, na ipinapakita sa unang screenshot sa artikulong ito. Kabilang sa mga tampok ng pag-encode ng KOI8-R, mapapansin na ang mga Cyrillic na titik sa talahanayan nito ay wala sa pagkakasunud-sunod ng alpabeto, tulad ng ginawa sa CP866. Kung titingnan mo ang pinakaunang screenshot (ng pangunahing bahagi, na kasama sa lahat ng pinalawak na pag-encode), mapapansin mo na sa KOI8-R ang mga letrang Ruso ay matatagpuan sa parehong mga cell ng talahanayan bilang ang kaukulang mga titik ng alpabetong Latin. mula sa unang bahagi ng talahanayan. Ginawa ito para sa kaginhawaan ng paglipat mula sa Russian patungo sa Latin na mga character sa pamamagitan ng pag-discard ng isang bit lamang (dalawa hanggang sa ikapitong kapangyarihan o 128).
Dahil sa napakaraming pag-encode ng wikang Ruso, ang mga tagagawa ng font at mga tagagawa ng software ay patuloy na sumasakit ng ulo, at ikaw at ako, mahal na mga mambabasa, ay madalas na nagkakaproblema sa parehong kilalang mga bug . kapag nagkaroon ng kalituhan sa bersyon na ginamit sa teksto. Kadalasan ay lumabas sila kapag nagpapadala at tumatanggap ng mga mensahe sa pamamagitan ng e-mail, na nagsasangkot ng paglikha ng napaka-komplikadong mga talahanayan ng conversion, na, sa katunayan, ay hindi malulutas ang problemang ito sa panimula, at kadalasan ang mga gumagamit ay gumagamit ng transliterasyon ng mga titik na Latin para sa pagsusulatan upang iwasan ang kilalang daldal kapag gumagamit ng mga Russian encoding tulad ng CP866, KOI8-R o Windows 1251. Sa katunayan, ang mga crack na lumilitaw sa halip na Russian text ay resulta ng maling paggamit ng pag-encode ng isang partikular na wika, na hindi tumutugma sa isa sa kung saan ang text message ay orihinal na naka-encode. Sabihin nating kung susubukan mong magpakita ng mga character na naka-encode gamit ang CP866 gamit ang Windows 1251 code table, lalabas ang parehong mga walang kwentang set ng character na ito, na ganap na papalitan ang text ng mensahe. 
Ang isang katulad na sitwasyon ay madalas na lumitaw kapag lumilikha at nagse-set up ng mga website, forum o blog, kapag ang teksto na may mga Russian na character ay maling nai-save sa maling pag-encode na ginamit sa site bilang default, o sa maling text editor, na nagdaragdag ng hindi nakikitang gag. sa code sa mata. Sa huli, maraming mga tao ang napagod sa sitwasyong ito na may maraming mga pag-encode at patuloy na gumagapang ng crap, at ang mga kinakailangan ay lumitaw para sa paglikha ng isang bagong unibersal na pagkakaiba-iba na papalitan ang lahat ng mga umiiral na at malulutas ang problema sa hitsura ng hindi nababasa na mga teksto . Bilang karagdagan, nagkaroon ng problema sa mga wika tulad ng Chinese, kung saan mayroong higit pang mga character ng wika kaysa sa 256.
Ilang character ang maaaring ma-encode sa UTF-16 gamit ang 16 bits? 65,536 (dalawa sa kapangyarihan ng labing-anim), at ito ang numero na pinagtibay bilang base space sa Unicode. Bilang karagdagan, may mga paraan para mag-encode ng humigit-kumulang dalawang milyong character gamit ito, ngunit limitado ang mga ito sa pinalawak na espasyo ng isang milyong character ng teksto. Ngunit kahit na ang matagumpay na bersyong ito ng Unicode encoding ay hindi nagdulot ng labis na kasiyahan sa mga sumulat, halimbawa, mga programa lamang sa Ingles, dahil pagkatapos ng paglipat mula sa pinahabang bersyon ng ASCII hanggang UTF-16, ang bigat ng mga dokumento ay nadoble (isang byte bawat character sa Aski at dalawang byte para sa parehong karakter sa YUTF-16). Ito ay tiyak upang masiyahan ang lahat at lahat ng bagay sa Unicode consortium na napagpasyahan na magkaroon ng isang variable na haba ng encoding . Tinawag itong UTF-8. Sa kabila ng walo sa pangalan, mayroon talaga itong variable na haba, i.e. Ang bawat karakter ng teksto ay maaaring i-encode sa isang pagkakasunud-sunod ng isa hanggang anim na byte ang haba. Sa pagsasagawa, ginagamit lamang ng UTF-8 ang hanay mula isa hanggang apat na byte, dahil higit sa apat na byte ng code ay hindi na posible na isipin ang anuman. Ang lahat ng Latin na character dito ay naka-encode sa isang byte, tulad ng sa magandang lumang ASCII. Ang kapansin-pansin ay sa kaso ng pag-encode lamang ng alpabetong Latin, kahit na ang mga programang iyon na hindi nakakaunawa sa Unicode ay magbabasa pa rin kung ano ang naka-encode sa YTF-8. Iyon ay, ang pangunahing bahagi ng Asuka ay inilipat lamang sa ideyang ito ng Unicode consortium. Ang mga cyrillic na character sa UTF-8 ay naka-encode sa dalawang byte, at, halimbawa, ang mga Georgian na character ay naka-encode sa tatlong byte. Ang Unicode Consortium, pagkatapos lumikha ng UTF 16 at 8, ay nalutas ang pangunahing problema - ngayon ay mayroon na kaming isang puwang ng code sa aming mga font . At ngayon ang kanilang mga tagagawa ay maaari lamang punan ito ng mga vector form ng mga character ng teksto batay sa kanilang mga lakas at kakayahan. Sa "Character Table" sa itaas makikita mo na ang iba't ibang font ay sumusuporta sa iba't ibang bilang ng mga character. Ang ilang mga font na mayaman sa Unicode ay maaaring maging mabigat. Ngunit ngayon sila ay naiiba hindi sa katotohanan na sila ay nilikha para sa iba't ibang mga pag-encode, ngunit sa katotohanan na ang tagagawa ng font ay napunan o hindi ganap na napunan ang solong puwang ng code na may ilang mga vector form.
Sa kaso ng isang site sa Joomla 1.5 at mas mataas, bilang pati na rin sa kaso ng isang blog sa WordPress, dapat mong iwasan ang hitsura Krakozyabrov piliin ang UTF 8 opsyon na walang BOM . Ano ang prefix ng BOM? Ang katotohanan ay kapag sila ay bumubuo ng YUTF-16 encoding, sa ilang kadahilanan ay nagpasya silang ilakip dito ang isang bagay tulad ng kakayahang isulat ang code ng character kapwa sa direktang pagkakasunud-sunod (halimbawa, 0A15) at sa kabaligtaran (150A) . At upang maunawaan ng mga programa kung anong pagkakasunud-sunod na basahin ang mga code, ang BOM (Byte Order Mark o, sa madaling salita, lagda) ay naimbento, na ipinahayag sa pagdaragdag ng tatlong karagdagang mga byte sa pinakadulo simula ng mga dokumento. Sa pag-encode ng UTF-8, walang BOM na ibinigay para sa Unicode consortium, at samakatuwid ang pagdaragdag ng isang pirma (mga kilalang-kilalang dagdag na tatlong byte sa simula ng dokumento) ay pinipigilan lamang ang ilang mga programa sa pagbabasa ng code. Samakatuwid, kapag nagse-save ng mga file sa UTF, dapat nating palaging piliin ang opsyon na walang BOM (walang pirma). Kaya, protektahan mo ang iyong sarili nang maaga mula sa pag-crawl palabas ng krakozyabrs . Ang kapansin-pansin ay ang ilang mga programa sa Windows ay hindi maaaring gawin ito (hindi nila mai-save ang teksto sa UTF-8 nang walang BOM), halimbawa, ang parehong kilalang Windows Notepad. Ini-save nito ang dokumento sa UTF-8, ngunit nagdaragdag pa rin ng lagda (tatlong dagdag na byte) sa simula nito. Bukod dito, ang mga byte na ito ay palaging magiging pareho - basahin ang code sa direktang pagkakasunod-sunod. Ngunit sa mga server, dahil sa maliit na bagay na ito, maaaring magkaroon ng problema - lalabas ang mga manloloko. Samakatuwid, huwag gumamit ng regular na Windows Notepad sa anumang sitwasyon.upang i-edit ang mga dokumento sa iyong site kung ayaw mong lumitaw ang anumang mga bitak. Itinuturing kong ang nabanggit na Notepad++ editor ay ang pinakamahusay at pinakasimpleng opsyon, na halos walang mga disbentaha at binubuo lamang ng mga pakinabang. Sa Notepad++, kapag pumili ka ng encoding, magkakaroon ka ng opsyong i-convert ang text sa UCS-2 encoding, na napakalapit sa Unicode standard. Gayundin sa Notepad posible na mag-encode ng teksto sa ANSI, i.e. kaugnay ng wikang Ruso, ito ay magiging Windows 1251, na inilarawan na namin sa itaas. Saan nagmula ang impormasyong ito? Ito ay nakarehistro sa registry ng iyong Windows operating system - kung saan ang pag-encode ay pipiliin sa kaso ng ANSI, na pipiliin sa kaso ng OEM (para sa wikang Ruso ito ay magiging CP866). Kung magtatakda ka ng isa pang default na wika sa iyong computer, ang mga pag-encode na ito ay papalitan ng mga katulad na mula sa kategorya ng ANSI o OEM para sa parehong wika. Pagkatapos mong i-save ang dokumento sa Notepad++ sa pag-encode na kailangan mo o buksan ang dokumento mula sa site para sa pag-edit, makikita mo ang pangalan nito sa kanang sulok sa ibaba ng editor: 
Upang maiwasan ang pagkalito , bilang karagdagan sa mga hakbang na inilarawan sa itaas , magiging kapaki-pakinabang na isulat ang source code sa header nito sa lahat ng pahina ng impormasyon ng site tungkol sa mismong pag-encode na ito, upang walang kalituhan sa server o lokal na host. Sa pangkalahatan, ang lahat ng hypertext markup language maliban sa Html ay gumagamit ng isang espesyal na deklarasyon ng xml, na tumutukoy sa pag-encode ng teksto.
GO TO FULL VERSION