Baza elementelor de bază este codificarea ASCII și interpretările sale moderne. Rezolvarea problemelor legate de codificarea incorectă a paginilor web

Dacă secvența de biți nu pare rezonabilă (din punct de vedere uman), atunci acesta este un caz în care documentul a fost cel mai probabil convertit greșit la un moment dat. De exemplu, luăm textul ÉGÉìÉRÅ[ÉfÉBÉìÉOÇÕìÔǵÇ≠ǻǢ și, fără să ne gândim la nimic mai bun, îl salvăm în UTF-8. Editorul de text a presupus că a citit corect textul cu codificarea Mac Roman și acum trebuie să fie salvat într-o altă codificare. La urma urmei, toate aceste caractere sunt valide în Unicode. Adică, Unicode are o clauză pentru É, pentru G și așa mai departe. Așa că îl salvăm doar în UTF-8:

11000011 10001001 01000111 11000011 10001001 11000011 10101100 11000011 10001001 01010010 11000011 10000101 01011011 11000011 10001001 01100110 11000011 10001001 01000010 11000011 10001001 11000011 10101100 11000011 10001001 01001111 11000011 10000111 11000011 10010101 11000011 10101100 11000011 10010100 11000011 10000111 11000010 10110101 11000011 10000111 11100010 10001001 10100000 11000011 10000111 11000010 10111011 11000011 10000111 11000010 10100010

Acesta este modul în care textul ÉGÉìÉRÅ[ÉfÉBÉìÉOÇÕìÔǵÇ≠ǻǢ este acum reprezentat ca o secvență de biți UTF-8. Această secvență de biți este complet divorțată de ceea ce era în documentul original. Indiferent de codificarea pe care o folosim pentru a deschide această secvență, nu vom vedea niciodată textul original エンコーディングは難しくない. Doar e pierdut. Ar putea fi restaurat dacă am cunoaște codarea Shift-JIS originală și că am trata textul ca Mac Roman și apoi l-am salvat ca UTF-8. Dar astfel de minuni sunt rare.

De multe ori o anumită secvență de biți este incorectă într-o anumită codificare. Dacă am încerca să deschidem documentul original în ASCII, am vedea că unele caractere au fost recunoscute, dar altele nu. Programul pe care îl utilizați ar putea decide să arunce pur și simplu octeții care nu se potrivesc codării curente sau să îi înlocuiască cu semne de întrebare. Sau cu un caracter special de înlocuire Unicode: � (U+ FFFD). Dacă salvați documentul după procedura de eliminare a caracterelor neadecvate, le veți pierde pentru totdeauna.

Dacă ghiciți codarea incorect și apoi o salvați în alta, veți distruge documentul. Puteți încerca să o remediați, dar aceste încercări de obicei nu se termină cu succes. Magia deplasată de biți rămâne de obicei magie ruptă: ca o cataplasmă pentru morți.

Și cum se schimbă corect codificările?

Este chiar simplu! Trebuie să cunoașteți codificarea unei anumite părți de text (secvență de biți) și să o utilizați pentru a o decripta. Cam despre asta e. Dacă scrieți un program care primește text de la utilizator, determinați în ce codificare va face acest lucru. Orice câmp de text trebuie să știe în ce codificare acceptă date. Pentru orice tip de fișier pe care un utilizator îl poate încărca într-un program, trebuie definită o codificare. Sau ar trebui să existe o modalitate de a întreba utilizatorul despre asta. Informațiile pot fi furnizate de formatul fișierului sau de utilizator (este puțin probabil ca majoritatea dintre ei să știe până când nu termină de citit articolul, desigur).

Dacă trebuie să convertiți textul dintr-o codificare în alta, utilizați unelte speciale. Conversia este sarcina plictisitoare de a compara două pagini de cod și de a decide că caracterul 152 din codificarea A este același cu caracterul 4122 din codificarea B, apoi schimbarea biților. Nu este nevoie să reinventăm roata: fiecare limbaj de programare obișnuit are instrumente abstracte de biți și pagini de cod pentru conversia textului de la codificare la codificare.

Să presupunem că aplicația dvs. trebuie să accepte fișiere în GB18030, dar în interior rulați în UTF-32. Instrumentul iconv poate face conversia într-o singură linie: iconv("GB18030", "UTF-32", $string). Caracterele vor rămâne aceleași chiar dacă reprezentarea biților s-a schimbat.

codificarea caracterului GB18030 codificarea UTF-32
縧 10111111 01101100 00000000 00000000 01111110 00100111

Asta e tot. Conținutul șirului în înțelegerea sa umană nu s-a schimbat, dar acum este un șir UTF-32 valid. Dacă continuați să lucrați cu el în UTF-32, nu veți avea probleme cu caractere imposibil de citit. Cu toate acestea, așa cum am discutat mai devreme, nu toate codificările sunt capabile să afișeze toate caracterele. Nu este posibilă codificarea caracterului 縧 în niciuna dintre codificările limbii europene. Și s-ar putea întâmpla ceva groaznic.

Totul este în Unicode

Acesta este motivul pentru care nu există nicio scuză în secolul 21 pentru a nu folosi Unicode. Unele codificări specializate pentru limbi europene pot fi mai performante decât Unicode specifice limbii. Dar atâta timp cât nu trebuie să lucrați cu terabytes de text special (ceea ce este MULT), nu trebuie să vă faceți griji pentru asta. Problemele care decurg din codificări incompatibile sunt mult mai grave decât un gigabyte pierdut. Și acest argument va deveni mai puternic pe măsură ce stocarea datelor și lățimea canalului cresc și devin mai ieftine.

Dacă sistemul trebuie să funcționeze cu alte codificări, mai întâi convertiți textul în Unicode și convertiți-l înapoi dacă trebuie să îl scoateți undeva. În caz contrar, va trebui să monitorizați foarte atent fiecare caz de accesare a datelor și să efectuați conversiile necesare, dacă este posibil fără a pierde informații.

Accidente fericite

Aveam un site conectat la o bază de date. Aplicația mea a procesat totul ca UTF-8 și l-a stocat în baza de date ca atare și totul a fost grozav, dar când am intrat în zona de administrare a bazei de date, nu am putut înțelege nimic.
- codificator anonim roșu

Apar situații când codările sunt procesate incorect, dar totul funcționează în continuare bine. Se întâmplă adesea ca codificarea bazei de date să fie setată la latin-1, dar aplicația funcționează cu UTF-8 (sau oricare altul). În general, orice combinație de 1 și 0 este valabilă în Latin-1 cu un singur octet. Dacă baza de date primește date de la o aplicație precum 11100111 10111000 10100111, atunci o salvează cu plăcere, crezând că aplicația înseamnă 縧. De ce nu? Mai târziu, baza de date returnează aceiași biți aplicației, ceea ce este fericit pentru că a primit caracterul UTF-8 縧 care a fost intenționat. Dar interfața de administrare a bazei de date știe că se folosește Latin-1 și acesta este rezultatul: nimic nu poate fi înțeles.
Prostul a câștigat pur și simplu la loterie, deși vedetele nu erau de partea lui. Orice operațiune asupra textului din baza de date poate funcționa, dar este posibil să nu fie efectuată conform intenției, deoarece baza de date nu percepe textul corect. În cel mai rău caz, baza de date va distruge din neatenție tot textul, efectuând o operațiune arbitrară la 2 ani de la instalare din cauza codificării incorecte (și, desigur, fără backup pentru dvs.).

UTF-8 și ASCII

Geniul lui UTF-8 este compatibilitatea sa binară cu ASCII, care este baza de facto pentru toate codificările. Toate caracterele ASCII ocupă maximum octeți în UTF-8 și folosesc aceiași biți ca în ASCII. Cu alte cuvinte, ASCII poate fi mapat 1:1 la UTF-8. Orice caracter non-ASCII ocupă 2 sau mai mulți octeți în UTF-8. Majoritatea limbajelor de programare care folosesc ASCII ca codificare cod sursa, vă permite să includeți text UTF-8 direct în text:

Salvarea în UTF-8 va da secvența:

00100100 01110011 01110100 01110010 01101001 01101110 01100111 00100000
00111101 00100000 00100010 11100110 10111100 10100010 11100101 10101101
10010111 00100010 00111011

Doar 12 din cei 17 octeți (cei care încep cu 1) sunt caractere UTF-8 (2 caractere de 3 octeți). Alte caractere sunt în ASCII. Analizorul va citi următoarele:

$string = "11100110 10111100 10100010 11100101 10101101 10010111";

Analizorul tratează totul din spatele citatului ca pe o secvență de biți care trebuie tratați așa cum sunt, până la celălalt citat. Dacă pur și simplu scoateți această secvență, veți scoate textul în UTF-8. Nu trebuie să faci nimic altceva. Analizorul nu trebuie să accepte în mod specific utf-8, trebuie doar să ia șiruri la propriu. Analizatorii simpli pot suporta Unicode în acest fel fără a suporta de fapt Unicode. Cu toate acestea, multe limbaje de programare acceptă în mod explicit Unicode.

Codificări și PHP.

PHP nu acceptă Unicode. Adevărat, o susține destul de bine. Paragraful anterior arată cum să includeți caractere UTF-8 direct în textul programului fără probleme, deoarece UTF-8 este compatibil cu ASCII și asta este tot ce are nevoie PHP. Cu toate acestea, afirmația că „PHP nu acceptă Unicode” este adevărată și a provocat multă confuzie în comunitatea PHP.

Promisiuni false

Unul dintre nemulțumirile mele au fost funcțiile utf8_encode și utf8_decode. Văd adesea lucruri stupide precum „Pentru a utiliza Unicode în PHP, trebuie să apelați utf8_encode pe textul de intrare și utf8_decode pe ieșire”. Aceste două funcții promit un fel de conversie automată a textului UTF-8, care se presupune că este necesară, deoarece „PHP nu acceptă Unicode”. Dacă citiți acest articol nu în diagonală, atunci știți asta

1. Nu este nimic special la UTF-8
2. Nu puteți codifica textul în UTF-8 după fapt

Permiteți-mi să explic punctul 2: orice text este deja codificat cu ceva. Când inserați șiruri în codul sursă, acestea sunt deja codificate. Mai precis, codificarea pe care o folosește în prezent editorul de text. Dacă le obțineți din baza de date, sunt deja codificate. Dacă le citești dintr-un fișier... știi deja, nu?

Textul este fie codificat UTF-8, fie necodat. Dacă nu, atunci este codificat în ASCII, ISO-8859-1, UTF-16 sau altceva. Dacă nu este în UTF-8, dar ar trebui să conțină „caractere UTF-8”, atunci aveți disonanță cognitivă. Dacă textul conține încă caracterele necesare codificate în UTF-8, atunci este în UTF-8.

Deci, ce naiba face utf8_encode?

„Conversie un șir ISO-8859-1 la codificare UTF-8”

Da! Autorul a vrut să spună că funcția convertește textul din ISO-8859-1 în UTF-8. Pentru asta e. Un nume atât de groaznic i-a fost dat probabil de un european imprudent. Același lucru este valabil și pentru utf8_decode. Aceste funcții nu sunt aplicabile pentru altceva decât pentru conversia de la ISO-8859-1 la UTF-8. Dacă aveți nevoie de o pereche de codare diferită, utilizați iconv.
utf8_encode nu este pentru tine bagheta magica, care trebuie fluturat peste fiecare cuvânt, deoarece „PHP nu acceptă Unicode”. Ea suna mai multe probleme, decât decide - spune-i mulțumesc că programatorilor europeni și ignoranți.

Nativ-shmativny

Deci, ce se referă atunci când spun că o limbă acceptă Unicode? Ceea ce contează este dacă limba presupune că un caracter ocupă un octet sau nu. Astfel, PHP vă permite să accesați caracterul selectat tratând șirul ca o matrice de caractere:

Dacă $șir are o codificare pe un singur octet, atunci ne va oferi primul caracter. Dar numai pentru că „caracter” este același cu „octet” în codificarea pe un singur octet. PHP dă doar primul octet fără să se gândească măcar la caractere. Șirurile pentru PHP nu sunt altceva decât secvențe de octeți, nici mai mult, nici mai puțin. Aceste „personaje lizibile” ale tale nu sunt altceva decât o invenție umană, PHP nu-i pasă de ele.

01000100 01101111 01101110 00100111 01110100
D o n "t
01100011 01100001 01110010 01100101 00100001
c a r e!

Același lucru este valabil și pentru mulți specificații standard, cum ar fi substr, strpos, trim și altele. Asistența se oprește acolo unde se termină maparea octet la caracter:

11100110 10111100 10100010 11100101 10101101 10010111
漢 字

$șir pentru șirul specificat va returna din nou doar primul octet, egal cu 11100110. Cu alte cuvinte, al treilea octet al caracterului 漢. Secvența 11100110 este incorectă pentru UTF-8, așa că șirul este acum incorect. Dacă și tu crezi așa, poți încerca o altă codificare, în care 11100110 va fi cumva acceptabil simbol aleatoriu. Te poți distra, doar că nu pe serverul de luptă.

Asta e tot. „PHP nu acceptă Unicode” înseamnă că majoritatea funcțiilor din limbă presupun că un octet este egal cu un caracter, ceea ce duce la trunchierea caracterelor pe mai mulți octeți sau la calcularea incorect a lungimii șirului. Acest lucru nu înseamnă că nu puteți folosi Unicode în PHP sau că orice text trebuie să fie rulat prin utf8_encode sau alte prostii.

Din fericire, există extensie specială, care adaugă toate funcționalitățile importante de șir, dar cu suport pentru codificări pe mai mulți octeți. mb_substr($șir, 0, 1, ‘UTF-8’) pe linia de mai sus va returna corect secvența 11100110 10111100 10100010, corespunzătoare caracterului 漢. Deoarece funcția trebuie să se gândească la ceea ce face, trebuie să i se transmită o codificare. Prin urmare, aceste funcții iau un parametru $encoding. Apropo, codificarea poate fi setată global pentru toate funcțiile mb_ folosind mb_internal_encoding.

Utilizarea și abuzul de gestionare a erorilor PHP

Întreaga problemă cu suportul (non-)Unicode în PHP este că interpretului nu-i pasă. Secvențe de octeți, ha. Nu-ți pasă ce înseamnă. Nu se face nimic altceva decât stocarea șirurilor de caractere în memorie. PHP nici măcar nu are un astfel de concept - codificare. Și atâta timp cât nu ai nevoie să manipulezi șirurile, nu contează. Se lucrează cu secvențe de octeți care pot fi percepute de cineva ca personaje. PHP vă cere doar să salvați codul sursă în ceva compatibil ASCII. Analizorul PHP caută caractere specifice care îi spun ce să facă. 00100100 spune: „declară o variabilă”, 00111101 – „atribuie”, 00100010 – începutul sau sfârșitul unei linii etc. Tot ceea ce nu este important pentru parser este tratat ca literali de secvență de octeți. Acest lucru este valabil și pentru tot ce este cuprins între ghilimele. Acest lucru înseamnă:

1. Nu veți putea salva sursa PHP într-o codificare care este incompatibilă cu ASCII. De exemplu, în UTF-16, caracterul ghilimeleu este codificat ca 00000000 00100010. Pentru PHP, care tratează totul ca ASCII, acesta este un octet NUL urmat de un citat. PHP ar avea probabil sughițuri pentru fiecare caracter și se va dovedi a fi NUL.
2. Puteți salva PHP într-o codificare compatibilă ASCII. Dacă primele 128 de puncte de codare se potrivesc cu ASCII, PHP le va mânca. Toate personaje semnificative pentru PHP sunt în primele 128 de puncte definite de ASCII. Dacă literalele șir conțin ceva dincolo de această limită, PHP nu va acorda atenție. Puteți salva sursa în ISO-8859-1, Mac Roman, UTF-8 sau orice altă codificare. Sirurile de caractere din codul dvs. vor primi codarea în care salvați fișierul.
3. Orice fișier extern pentru PHP poate avea orice codificare. Dacă analizatorul nu trebuie să proceseze fișierul, atunci va fi fericit.

   $foo = file_get_contents("bar.txt");

   Cele de mai sus vor pune pur și simplu octeții din bar.txt în variabila $foo. PHP nu va încerca să interpreteze, să codifice sau să manipuleze în alt mod conținutul. Fișierul poate conține date binare sau o imagine, PHP nu-i pasă.

4. Dacă codificările externe și interne trebuie să se potrivească, atunci chiar ar trebui. Un caz comun este localizarea: în cod scrieți ceva de genul echo localize('Foobar'), iar în fișierul extern este:

   msgstr "Foobar"
   msgstr "フーバー"
   

   Ambele șiruri Foobar trebuie să aibă o reprezentare identică a biților. Dacă codul sursă este în ASCII și codul de localizare este în UTF-16, nu ai noroc. Trebuie făcută o conversie suplimentară.

Un cititor priceput s-ar putea întreba, să zicem, dacă este posibil să stocați secvențial un octet UTF-16 într-un literal fișier sursăîn ASCII, iar răspunsul va fi întotdeauna: desigur.

01100101 01100011 01101000 01101111 00100000 00100010
e c h o"
11111110 11111111 00000000 01010101 00000000 01010100
(marcator UTF-16) U T
00000000 01000110 00000000 00101101 00000000 00110001
F - 1
00000000 00110110 00100010 00111011
6 " ;

Prima linie și ultimii 2 octeți sunt din ASCII. Restul este reprezentat în UTF-16, 2 octeți per caracter. 11111110 11111111 de pe a doua linie este un marcator pentru începutul textului în UTF-16 (necesar de standard, PHP nu a auzit niciodată de asta). Acest script scoate șirul „UTF-16” codificat în UTF-16, deoarece pur și simplu scoate octeții dintre două ghilimele, ceea ce are ca rezultat textul „UTF-16” codificat în UTF-16. Pe de altă parte, sursa nu este complet corectă nici în ASCII, nici în UTF-16, așa că puteți deschide un editor și vă puteți distra.

Total

PHP acceptă Unicode, sau mai precis, orice codificare destul de precisă, atâta timp cât poți determina analizatorul să-și facă treaba și dezvoltatorul să înțeleagă ce face. Trebuie doar să fii atent când lucrezi cu șiruri de caractere: împărțirea, eliminarea spațiilor, numărarea și toate celelalte operațiuni care necesită lucrul cu caractere, nu cu octeți. Dacă nu faceți nimic cu șiruri în afară de citire și ieșire, este puțin probabil să întâlniți probleme care nu există în alte limbi.

Limbi cu suport de codificare

Deci, ce înseamnă pentru o limbă să accepte Unicode? Javascript, de exemplu, acceptă Unicode. De fapt, orice șir din Javascript este codificat în UTF-8. Și aceasta este singura codificare cu care funcționează Javascript. Pur și simplu nu puteți obține un șir non-UTF-8 în Javascript. Javascript venerează Unicode într-o asemenea măsură încât pur și simplu nu există instrumente în nucleul limbajului care să lucreze cu alte codificări. Deoarece Javascript rulează cel mai adesea în browser, nu aveți nicio problemă: browserul este capabil să efectueze codificare și decodare I/O banale.

Alte limbi acceptă pur și simplu codificări. Lucrările interne se desfășoară într-o singură codificare, adesea UTF-16. Dar asta înseamnă că trebuie să li se spună în ce codificare este textul sau vor încerca să o determine ei înșiși. Este necesar să se indice în ce codificare este salvat codul sursă, în ce codificare este salvat fișierul care va fi citit și în ce codificare ar trebui făcută ieșirea. Limba va efectua conversia din mers dacă este specificat că trebuie folosit Unicode. Ei fac tot ceea ce în PHP trebuie făcut semi-automat undeva în fundal. Nu mai bun sau mai rău decât PHP, doar diferit. Vești bune Ideea este că funcțiile cu șir funcționează în cele din urmă și nu trebuie să vă faceți griji dacă șirul conține caractere pe mai mulți octeți sau nu, cu ce funcții să alegeți să lucrați și alte lucruri pe care ar trebui să le faceți în PHP.

Wilds Unicode

Din moment ce Unicode rezolvă atât de multe diverse problemeși funcționează în multe scenarii diferite, trebuie să plătiți pentru asta săpat în sălbăticie. De exemplu, standardul Unicode conține informații despre rezolvarea unor probleme precum unificarea hieroglifelor YAKK. Multe simboluri comune Japoniei, Chinei și Coreei sunt descrise ușor diferit. Sau problema conversiei caracterelor din litere mici în majuscule, invers sau înainte și înapoi, care nu este întotdeauna la fel de simplă ca în cazul codificărilor limbilor vest-europene. Unele simboluri pot fi reprezentate de elemente diferite. Litera ö, de exemplu, poate fi reprezentată de elementul U+00F6 („LITERA MINUSCULĂ LATINĂ O CU DIAREZA”) sau ca două articole U+006F („SCRISOA MICĂ O”) ȘI U+0308 („DIAREZA DE SUBSTITUȚIE”) , care înseamnă litera o Cu. În UTF-8 este fie 2 octeți, fie 3 octeți, ceea ce în ambele cazuri reprezintă un caracter normal. Prin urmare, în standard există reguli de normalizare, adică. cum să convertiți aceste forme dintr-o formă în alta. Acest lucru și multe altele depășesc domeniul de aplicare al acestui articol, dar trebuie să știți despre aceste puncte.

Nu am forțat din nou!

1. Textul este întotdeauna o secvență de biți care trebuie tradusă în limbaj natural folosind tabele. Tabel nevalid - simbol nevalid.
2. Nu poți lucra direct cu text - lucrezi mereu cu biți care sunt învăluiți în abstracții. Erorile se datorează erorilor dintr-una dintre abstracții.
3. Sistemele care transmit informații între ele trebuie să indice întotdeauna codificarea de lucru. De exemplu, site-ul îi spune browserului că furnizează informații în UTF-8.
4. În zilele noastre, UTF-8 este compatibil cu ASCII, în ciuda faptului că poate codifica aproape orice caracter și este încă relativ eficient în majoritatea cazurilor. Alte codificări au și ele utilizările lor, dar trebuie să existe un motiv întemeiat să te deranjezi cu codificări care acceptă doar o parte din Unicode.
5. Atât programul, cât și programatorul trebuie să se ocupe de problema potrivirii unui octet și a unui caracter.

Acum nu mai este nevoie să te scuzi când dai peste cap textul din nou.

Etichete: Adăugați etichete

Astăzi codificarea ASCII este un standard pentru reprezentarea primelor 128 de caractere (inclusiv numere și semne de punctuație) ale alfabetului englez, prezentate într-o anumită ordine.

Cu toate acestea, chiar și 1 octet vă permite să codificați de 2 ori mai multe valori, adică nu 128, ci până la 256 de valori diferite. Prin urmare, suficient de repede pentru a înlocui elementul de bază ASCII Au început să apară versiuni mai extinse ale acestei codificări celebre și populare, în care au fost codificate și caractere ale alfabetelor și, în consecință, text din diferite limbi, inclusiv rusă.

Extensii ASCII pentru Rusia

Astăzi, codificarea este o prioritate pentru utilizatorii ruși Windows1251și codificare Unicode, de asemenea UTF 8 care provine din ASCII.

De fapt, cineva poate avea o întrebare foarte corectă: „De ce sunt necesare aceste codificări de text?”
Merită să ne amintim că un computer este doar o mașină care trebuie să acționeze strict conform instrucțiunilor. Pentru a clarifica ceea ce trebuie făcut cu fiecare simbol scris, acesta este reprezentat ca un set de forme vectoriale, fiecare set fiind trimis la locul potrivit, astfel încât pe ecran să apară una sau alta desemnare.

Fonturile sunt responsabile pentru formarea formelor vectoriale, iar procesul de codificare în sine depinde sistem de operare, precum și programele utilizate în acesta. Astfel, fiecare text în esența sa este un anumit set de octeți, fiecare dintre ei reprezentând codificarea unui caracter scris. Un program care afișează informații tipărite pe ecran (acesta poate fi un browser sau procesor de cuvinte), analizează codul, găsește o mapare potrivită pe baza codului său în tabelul de codificare, îl convertește în forma vectorială necesară și o afișează într-un fișier text.

Codificare CP866 și KOI8-R au fost utilizate pe scară largă înainte de apariția sistemului de operare grafic, care a câștigat popularitate în întreaga lume - Windows. Acum, cea mai populară codificare care acceptă limba rusă a devenit Windows1251.

Cu toate acestea, nu este singurul, motiv pentru care producătorii de fonturi rusești utilizate periodic în software încă întâmpină dificultăți asociate cu afișarea incorectă a caracterelor și apariția așa-numitului krakozyabry. Aceste hieroglife incomode sunt rezultatul utilizare incorectă tabele de codificare, adică tabele diferite au fost folosite în timpul codificării și decodării.

Aceeași situație se întâmplă și pe site-uri web, bloguri și alte resurse unde există informații în limba rusă și alte caractere străine, altele decât engleza. Această situație a determinat premisa de bază pentru crearea unei codări universale care vă permite să codificați text în orice limbă, chiar și în chineză, unde există semnificativ mai multe caractere decât 256.

Codări universale

Prima versiune a codificării universale dezvoltată în cadrul consorțiului Unicode a fost codificarea UTF 32. Au fost folosiți 32 de biți pentru a codifica fiecare caracter. Acum s-a realizat posibilitatea de a codifica un număr mare de caractere, dar a apărut o altă problemă - majoritatea țărilor europene nu aveau nevoie de un astfel de număr de caractere suplimentare. La urma urmei, documentele s-au dovedit a fi foarte grele. Prin urmare, pentru a înlocui UTF 32 a venit UTF 16, care a devenit baza tuturor simbolurilor folosite în țara noastră și nu numai.

Dar erau încă destul de mulți oameni nemulțumiți. De exemplu, cei care au comunicat doar în Limba engleză, din moment ce la mutarea din ASCII la UTF 16 documentele lor au crescut în continuare în dimensiune și în mod semnificativ, de aproape 2 ori.
Rezultatul a fost codificarea cu lungime variabilă UTF 8, ceea ce a permis să nu se mărească greutatea textului.

Krakozyabry și metodele de a le trata

În general, codificarea este setată pe pagina în care Anunţ. Ca urmare, la începutul documentului se formează un fel de marcaj, în care se reține dacă codurile de caractere sunt scrise în ordine directă sau inversă. UTF16.

Dacă ceva a fost tipărit UTF-8, atunci nu există nici un marcator la început, deoarece însăși posibilitatea de a scrie codul caracterelor în ordine inversă în această codificare este absentă.

Prin urmare, ar trebui să salvați tot ce ați introdus în editor, fără marcatori ( BOM) pentru a reduce probabilitatea de apariție a farfurie în document.

Încă una sfat util pentru a combate krakozyabrs - scrieți în antetul codului fiecărei pagini a site-ului informații despre codificarea corectă a textului, astfel încât să nu gazdă locală, nu a existat nicio confuzie pe server.

De exemplu, așa

Bună ziua, dragi cititori ai blogului. Astăzi vă vom vorbi despre de unde provin krakozyabr-urile pe un site web și în programe, ce codificări de text există și care ar trebui folosite. Să aruncăm o privire mai atentă asupra istoriei dezvoltării lor, pornind de la ASCII de bază, precum și versiunile sale extinse CP866, KOI8-R, Windows 1251 și terminând cu codificări moderne Unicode Consortium UTF 16 și 8.

Pentru unii, această informație poate părea inutilă, dar ați ști câte întrebări primesc în special cu privire la krakozyabrs (setul de caractere imposibil de citit). Acum voi avea ocazia să trimit tuturor la textul acestui articol și să-mi găsesc propriile greșeli. Ei bine, pregătiți-vă să absorbiți informațiile și încercați să urmăriți fluxul poveștii.

ASCII - codificarea de bază a textului pentru alfabetul latin

Dezvoltarea codificărilor de text a avut loc concomitent cu formarea industriei IT, iar în acest timp au reușit să sufere destul de multe schimbări. Din punct de vedere istoric, totul a început cu EBCDIC, care era destul de disonantă în pronunția rusă, ceea ce a făcut posibilă codificarea literelor alfabetului latin, a cifrelor arabe și a semnelor de punctuație cu caractere de control.

Dar inca Punct de start pentru dezvoltare codificări moderne textele ar trebui considerate celebre ASCII(Standard american Cod pentru Schimbul de informații, care în rusă este de obicei pronunțat „aski”). Descrie primele 128 de caractere utilizate cel mai frecvent de utilizatorii vorbitori de limba engleză - scrisori, cifre arabe și semne de punctuație.

Aceste 128 de caractere descrise în ASCII au inclus și unele caractere de serviciu, cum ar fi paranteze, semne hash, asteriscuri etc. De fapt, le puteți vedea singur:

Aceste 128 de caractere din versiunea originală ASCII au devenit standardul, iar în orice altă codificare le veți găsi cu siguranță și vor apărea în această ordine.

Dar adevărul este că cu un octet de informații poți codifica nu 128, ci până la 256 sensuri diferite(doi la puterea lui opt este egal cu 256), deci urmează versiunea de bază A apărut o serie întreagă de Asuka codificări ASCII extinse, în care, pe lângă 128 de caractere de bază, a fost posibilă și codificarea simbolurilor codificării naționale (de exemplu, rusă).

Aici, probabil că merită să spunem puțin mai multe despre sistemele de numere care sunt utilizate în descriere. În primul rând, după cum știți cu toții, un computer funcționează doar cu numere în sistemul binar, și anume cu zerouri și unu („algebră booleană”, dacă cineva a luat-o la un institut sau la școală). , fiecare dintre acestea fiind un doi la putere, începând de la zero și până la doi până la a șaptea:

Nu este greu de înțeles că toată lumea combinatii posibileÎntr-o astfel de construcție, pot fi doar 256 de zerouri și unități sistem binar la zecimală este destul de simplu. Trebuie doar să aduni toate puterile a doi cu una deasupra lor.

În exemplul nostru, acesta se dovedește a fi 1 (2 la puterea lui zero) plus 8 (două la puterea lui 3), plus 32 (două la puterea a cincea), plus 64 (la puterea a șasea), plus 128 (la puterea a saptea). Totalul obține 233 in sistem zecimal Socoteala După cum puteți vedea, totul este foarte simplu.

Dar dacă te uiți îndeaproape la tabelul cu caractere ASCII, vei vedea că acestea sunt reprezentate în codificare hexazecimală. De exemplu, „asteriscul” corespunde numărului hexazecimal 2A din Aski. Probabil știți că în sistemul numeric hexazecimal, pe lângă cifrele arabe, sunt folosite și litere latine de la A (înseamnă zece) la F (înseamnă cincisprezece).

Ei bine, atunci, pentru traducere număr binar la hexazecimal recurge la următoarea metodă simplă și evidentă. Fiecare octet de informații este împărțit în două părți de patru biți, așa cum se arată în captura de ecran de mai sus. Acea. în fiecare jumătate de octet cod binar doar șaisprezece valori pot fi codificate (de la două până la a patra putere), care pot fi ușor reprezentate ca număr hexazecimal.

Mai mult, în jumătatea stângă a octetului, gradele vor trebui să fie numărate din nou începând de la zero și nu așa cum se arată în captura de ecran. Drept urmare, prin calcule simple, obținem că numărul E9 este codificat în captură de ecran. Sper că cursul raționamentului meu și soluția acestui puzzle v-au fost clare. Ei bine, acum să continuăm, de fapt, să vorbim despre codificări de text.

Versiuni extinse de Asuka - codificări CP866 și KOI8-R cu pseudografice

Așadar, am început să vorbim despre ASCII, care a fost, parcă, punctul de plecare pentru dezvoltarea tuturor codificărilor moderne (Windows 1251, Unicode, UTF 8).

Inițial, conținea doar 128 de caractere din alfabetul latin, cifre arabe și altceva, dar în versiunea extinsă a devenit posibilă utilizarea tuturor celor 256 de valori care pot fi codificate într-un octet de informații. Acestea. A devenit posibil să adăugați simboluri ale literelor din limba dvs. la Aski.

Aici va trebui să ne abatem din nou pentru a explica - de ce avem nevoie de codificări? texte și de ce este atât de important. Caracterele de pe ecranul computerului sunt formate pe baza a două lucruri - seturi de forme vectoriale (reprezentări) ale diferitelor caractere (sunt localizate în fișiere cu ) și cod care vă permite să scoateți din acest set de forme vectoriale (fișier cu fonturi). ) exact caracterul care va trebui introdus în Locul corect.

Este clar că fonturile în sine sunt responsabile pentru formele vectoriale, dar sistemul de operare și programele utilizate în el sunt responsabile pentru codificare. Acestea. orice text de pe computer va fi un set de octeți, fiecare dintre care codifică un singur caracter al acestui text.

Programul care afișează acest text pe ecran (editor de text, browser etc.), atunci când parsează codul, citește codificarea următorului caracter și caută forma vectorială corespunzătoare în fișierul necesar font care este conectat pentru a afișa acest document text. Totul este simplu și banal.

Aceasta înseamnă că pentru a codifica orice caracter de care avem nevoie (de exemplu, din alfabetul național), trebuie îndeplinite două condiții - forma vectorială a acestui caracter trebuie să fie în fontul folosit și acest caracter ar putea fi codificat în codificări ASCII extinse în un octet. Prin urmare, există o mulțime de astfel de opțiuni. Doar pentru codificarea caracterelor în limba rusă, există mai multe varietăți de Aska extins.

De exemplu, a apărut inițial CP866, care avea capacitatea de a folosi caractere din alfabetul rus și era o versiune extinsă a ASCII.

Acestea. partea superioară a coincis complet cu versiunea de bază a lui Asuka (128 de caractere latine, numere și alte prostii), care este prezentată în captura de ecran de mai sus, dar acum Partea de jos tabelele cu codificare CP866 aveau forma afișată în captura de ecran de mai jos și vă permiteau să codificați încă 128 de caractere (litere rusești și tot felul de pseudo-grafice):

Vedeți, în coloana din dreapta numerele încep cu 8, pentru că... numerele de la 0 la 7 se referă la partea de bază a ASCII (vezi prima captură de ecran). Acea. litera rusă „M” din CP866 va avea codul 9С (este situată la intersecție linii corespunzătoare de la 9 și o coloană cu cifra C în sistemul numeric hexazecimal), care poate fi scrisă într-un octet de informații, iar dacă aveți un font potrivit cu caractere rusești, această literă va fi afișată în text fără probleme.

De unde aceasta suma? pseudografic în CP866? Ideea este că această codificare pentru textul rusesc a fost dezvoltată în acei ani greșiți, când sistemele de operare grafică nu erau atât de răspândite ca acum. Și în Dosa și sisteme de operare cu text similare, pseudografica a făcut posibilă cel puțin diversificarea designului textelor și, prin urmare, CP866 și toți ceilalți colegi din categoria versiunilor extinse ale Asuka abundă în el.

CP866 a fost distribuit de IBM, dar în plus, au fost dezvoltate o serie de codificări pentru caracterele în limba rusă, de exemplu, același tip (ASCII extins) poate fi atribuit KOI8-R:

Principiul funcționării sale rămâne același cu cel al CP866 descris puțin mai devreme - fiecare caracter al textului este codificat de un singur octet. Captura de ecran arată a doua jumătate a tabelului KOI8-R, deoarece prima jumătate este complet în concordanță cu Asuka de bază, care este afișată în prima captură de ecran din acest articol.

Printre caracteristicile codificării KOI8-R, se poate remarca faptul că literele rusești din tabelul său nu intră în ordine alfabetică, așa cum au făcut, de exemplu, în CP866.

Dacă vă uitați la prima captură de ecran (a părții de bază, care este inclusă în toate codificările extinse), veți observa că în KOI8-R literele rusești sunt situate în aceleași celule ale tabelului ca și literele corespunzătoare ale alfabetului latin din prima parte a tabelului. Acest lucru a fost făcut pentru comoditatea trecerii de la caracterele rusești la caractere latine, eliminând doar un bit (două la a șaptea putere sau 128).

Windows 1251 - versiunea modernă de ASCII și de ce apar fisurile

Dezvoltarea în continuare a codificărilor de text s-a datorat faptului că sistemele de operare grafică câștigau popularitate și nevoia de a folosi pseudografice în ele a dispărut în timp. Ca urmare, a apărut un întreg grup care, în esență, erau încă versiuni extinse ale Asuka (un caracter al textului este codificat cu doar un octet de informații), dar fără utilizarea simbolurilor pseudografice.

Ele aparțineau așa-numitelor codificări ANSI, care au fost dezvoltate de Institutul American de Standarde. În limbajul comun, numele chirilic a fost folosit și pentru versiunea cu suport pentru limba rusă. Un exemplu în acest sens ar fi.

S-a diferențiat în mod favorabil de CP866 și KOI8-R utilizate anterior prin faptul că locul simbolurilor pseudografice în el a fost luat de simbolurile lipsă ale tipografiei ruse (cu excepția semnului de accent), precum și de simbolurile utilizate în limbile slave apropiate de Rusă (ucraineană, belarusă etc.):

Datorită unei astfel de abundențe de codificări în limba rusă, producătorii și producătorii de fonturi software durerile de cap au apărut în mod constant, iar tu și cu mine, dragi cititori, de multe ori am primit aceleași notorii krakozyabry, când a existat confuzie cu versiunea folosită în text.

Foarte des au apărut la trimiterea și primirea mesajelor prin e-mail, care a presupus crearea unor tabele de conversie foarte complexe, care, de fapt, nu au putut rezolva această problemă, iar utilizatorii au folosit adesea pentru corespondență pentru a evita trucurile notorii atunci când foloseau codificări rusești precum CP866, KOI8-R sau Windows 1251.

De fapt, krakozyabrurile care apar în locul textului rusesc au fost rezultatul utilizării incorecte a codificării a acestei limbi, care nu se potrivea cu cel în care a fost codificat mesaj text inițial.

De exemplu, dacă încercați să afișați caractere codificate folosind CP866 folosind codul Masa Windows 1251, atunci vor ieși aceleași farfurii (un set de caractere fără sens), înlocuind complet textul mesajului.

O situație similară apare foarte des în forumuri sau bloguri, când textul cu caractere rusești este salvat din greșeală în codificarea greșită, care este folosită implicit pe site, sau în editorul de text greșit, care adaugă la coduri gaguri care nu sunt vizibile pentru cu ochiul liber.

În cele din urmă, mulți oameni s-au săturat de această situație cu o mulțime de codificări și încontinuu porcării, iar premisele au apărut pentru crearea unei noi variante universale care să le înlocuiască pe toate pe cele existente și să rezolve în sfârșit problema cu aspectul. a textelor ilizibile. În plus, a fost problema limbilor precum chineza, unde erau mult mai multe caractere de limbă decât 256.

Unicode - codificări universale UTF 8, 16 și 32

Aceste mii de caractere ale grupului de limbi din Asia de Sud-Est nu au putut fi descrise într-un octet de informații care au fost alocate pentru codificarea caracterelor în versiunile extinse de ASCII. Ca urmare, a fost creat un consorțiu numit Unicode(Unicode - Unicode Consortium) cu colaborarea multor lideri din industria IT (cei care produc software, care codifică hardware, care creează fonturi), care au fost interesați de apariția unei codări universale de text.

Prima variantă lansată sub auspiciile Consorțiului Unicode a fost UTF 32. Numărul din numele de codificare înseamnă numărul de biți care sunt utilizați pentru a codifica un caracter. 32 de biți echivalează cu 4 octeți de informații care vor fi necesari pentru a codifica un singur caracter în noua codificare UTF universală.

Ca urmare, același fișier cu text codificat în versiunea extinsă a ASCII și în UTF-32, în acest din urmă caz, va avea o dimensiune (greutate) de patru ori mai mare. Acest lucru este rău, dar acum avem posibilitatea de a codifica folosind YTF un număr de caractere egal cu două la puterea de treizeci de secunde ( miliarde de caractere, care va acoperi orice valoare cu adevărat necesară cu o marjă colosală).

Dar pentru multe țări cu limbi ale grupului european acest lucru o cantitate mare Nu a fost deloc nevoie să se utilizeze caractere în codificare, cu toate acestea, atunci când se foloseau UTF-32, acestea nu ar fi primit niciodată o creștere de patru ori a ponderii documentelor text și, ca urmare, o creștere a volumului traficului de internet și a volumul datelor stocate. Este mult și nimeni nu și-ar putea permite o astfel de risipă.

Ca urmare a dezvoltării Unicode, UTF-16, care s-a dovedit a fi atât de reușit încât a fost adoptat implicit ca spațiu de bază pentru toate caracterele pe care le folosim. Folosește doi octeți pentru a codifica un caracter. Să vedem cum arată chestia asta.

În sistemul de operare Windows, puteți urma calea „Start” - „Programe” - „Accesorii” - „Instrumente de sistem” - „Tabel de caractere”. Ca urmare, se va deschide un tabel cu forme vectoriale toate fonturile instalate pe sistemul dvs. Dacă selectați setul de caractere Unicode în „Opțiuni avansate”, veți putea vedea pentru fiecare font separat întreaga gamă de caractere incluse în acesta.

Apropo, făcând clic pe oricare dintre ele, îi puteți vedea pe doi octeți cod în format UTF-16, format din patru cifre hexazecimale:

Câte caractere pot fi codificate în UTF-16 folosind 16 biți? 65.536 (doi la puterea lui șaisprezece), iar acesta este numărul care a fost adoptat ca spațiu de bază în Unicode. În plus, există modalități de a codifica aproximativ două milioane de caractere folosindu-l, dar acestea au fost limitate la un spațiu extins de un milion de caractere de text.

Dar nici această versiune de succes a codificării Unicode nu a adus prea multe satisfacții celor care au scris, să zicem, programe doar în limba engleză, deoarece pentru ei, după trecerea de la versiunea extinsă a ASCII la UTF-16, greutatea documentelor s-a dublat ( un octet per caracter în Aski și doi octeți pentru același caracter în YUTF-16).

Tocmai pentru a-i satisface pe toți și tot în consorțiul Unicode s-a decis să vină codificare de lungime variabilă. Se numea UTF-8. În ciuda celor opt din numele său, are de fapt o lungime variabilă, adică. Fiecare caracter al textului poate fi codificat într-o secvență de la unu până la șase octeți.

În practică, UTF-8 folosește doar intervalul de la unu la patru octeți, deoarece dincolo de patru octeți de cod nu mai este nici măcar posibil teoretic să ne imaginăm ceva. Toate caracterele latine din el sunt codificate într-un octet, la fel ca în vechiul ASCII.

Ceea ce este de remarcat este că, în cazul codificării numai a alfabetului latin, chiar și acele programe care nu înțeleg Unicode vor citi în continuare ceea ce este codificat în YTF-8. Acestea. partea de bază a Asuka a fost pur și simplu transferată la această creație a consorțiului Unicode.

Caracterele chirilice în UTF-8 sunt codificate în doi octeți și, de exemplu, caracterele georgiane sunt codificate în trei octeți. Consorțiul Unicode, după ce a creat UTF 16 și 8, a rezolvat principala problemă - acum avem fonturile au un singur spațiu de cod. Și acum producătorii lor îl pot completa doar cu forme vectoriale de caractere text pe baza punctelor forte și a capacităților lor. Acum vin chiar și în seturi.

În „Tabelul de caractere” de mai sus puteți vedea că diferite fonturi acceptă un număr diferit de caractere. Unele fonturi bogate în Unicode pot fi destul de grele. Dar acum ele diferă nu prin faptul că au fost create pentru diferite codificări, ci prin faptul că producătorul fontului a umplut sau nu complet spațiul unic de cod cu anumite forme vectoriale.

Cuvinte nebunești în loc de litere rusești - cum să o rezolvi

Să vedem acum cum apar krakozyabrurile în loc de text sau, cu alte cuvinte, cum este selectată codificarea corectă pentru textul rusesc. De fapt, este setat în programul în care creați sau editați chiar acest text, sau codați folosind fragmente de text.

Pentru editare și creare fișiere text Personal, folosesc unul foarte bun, după părerea mea, . Cu toate acestea, poate evidenția și sintaxa o sută bună limbaje de programare și de marcare și are, de asemenea, capacitatea de a fi extins folosind plugin-uri. Citit revizuire detaliată acest program minunat la link-ul oferit.

În meniul de sus al Notepad++ există un element „Codări”, unde veți avea posibilitatea de a converti o opțiune existentă în cea utilizată implicit pe site-ul dvs.:

În cazul unui site pe Joomla 1.5 și versiuni ulterioare, precum și în cazul unui blog pe WordPress, ar trebui să selectați opțiunea pentru a evita apariția fisurilor UTF 8 fără BOM. Care este prefixul BOM?

Faptul este că, atunci când dezvoltau codificarea YUTF-16, din anumite motive au decis să-i atașeze un astfel de lucru, cum ar fi capacitatea de a scrie codul caracterelor atât în ​​secvență directă (de exemplu, 0A15), cât și invers (150A). . Și pentru ca programele să înțeleagă exact în ce secvență să citească codurile, a fost inventat BOM(Byte Order Mark sau, cu alte cuvinte, semnătură), care a fost exprimată prin adăugarea a trei octeți suplimentari chiar la începutul documentelor.

În codificarea UTF-8, consorțiul Unicode nu prevedea BOM-uri și, prin urmare, adăugarea unei semnături (acei notorii trei octeți suplimentari la începutul documentului) împiedică pur și simplu unele programe să citească codul. Prin urmare, atunci când salvăm fișiere în UTF, trebuie să selectăm întotdeauna opțiunea fără BOM (fără semnătură). Deci ești în avans protejează-te de crakozyabrs care se târăsc.

Ceea ce este de remarcat este că unele programe din Windows nu pot face acest lucru (nu pot salva text în UTF-8 fără BOM), de exemplu, același Windows Notepad notoriu. Salvează documentul în UTF-8, dar încă adaugă semnătura (trei octeți suplimentari) la începutul acestuia. Mai mult, acești octeți vor fi întotdeauna aceiași - citiți codul în secvență directă. Dar pe servere, din cauza acestui mic lucru, poate apărea o problemă - vor ieși escrocii.

Prin urmare, sub nicio formă nu folosi cu un blocnotes obișnuit Windows pentru a edita documente de pe site-ul dvs. dacă nu doriți să apară crăpături. Consider că editorul Notepad++ deja menționat este cea mai bună și mai simplă opțiune, care practic nu are dezavantaje și constă doar în avantaje.

În Notepad++, atunci când selectați o codificare, veți avea opțiunea de a converti textul în codificare UCS-2, care este foarte apropiată de standardul Unicode. De asemenea, în Notepad va fi posibilă codificarea textului în ANSI, adică. în legătură cu limba rusă, acesta va fi Windows 1251, pe care l-am descris deja mai sus De unde provin aceste informații?

Este înregistrată în registrul blocului dumneavoastră de operație sisteme Windows- ce codificare sa alegeti in cazul ANSI, pe care sa alegeti in cazul OEM (pentru limba rusa va fi CP866). Dacă setați o altă limbă implicită pe computer, atunci aceste codificări vor fi înlocuite cu altele similare din categoria ANSI sau OEM pentru aceeași limbă.

După ce salvați documentul în Notepad++ în codificarea de care aveți nevoie sau deschideți documentul de pe site pentru editare, puteți vedea numele acestuia în colțul din dreapta jos al editorului:

Pentru a evita rednecks Pe lângă acțiunile descrise mai sus, va fi util să scrieți informații despre această codificare în antetul codului sursă al tuturor paginilor site-ului, astfel încât să nu existe confuzii pe server sau pe gazda locală.

În general, toate limbajele de marcare hipertext, cu excepția HTML, folosesc o declarație xml specială, care specifică codificarea textului.

Înainte de a analiza codul, browserul știe ce versiune este utilizată și cât de exact trebuie să interpreteze codurile de caractere ale acelei limbi. Dar ceea ce este de remarcat este că, dacă salvați documentul în Unicode implicit, atunci această declarație xml poate fi omisă (codificarea va fi considerată UTF-8 dacă nu există BOM sau UTF-16 dacă există o BOM).

În cazul unui document limbaj HTML folosit pentru a indica codificarea Element meta, care este scris între etichetele Head de deschidere și de închidere:

... ...

Această intrare este destul de diferită de cea adoptată în, dar este pe deplin compatibilă cu noul standard Html 5 care este introdus încet și va fi înțeles complet corect de orice browser utilizat în prezent.

În teorie, un element Meta cu o indicație codificări HTML ar fi bine sa pui documentul cât mai sus posibil în antetul documentului astfel încât în ​​momentul întâlnirii primului caracter din text nu din ANSI de bază (care sunt întotdeauna citite corect și în orice variație), browserul ar trebui să aibă deja informații despre modul de interpretare a codurilor acestor caractere.

Multă baftă! Inainte de pe curând pe paginile site-ului blogului

Puteți viziona mai multe videoclipuri accesând

");">

S-ar putea să fiți interesat

Ce s-a întâmplat adrese URL Care este diferența dintre linkurile absolute și relative pentru un site?
OpenServer - modern server localși un exemplu de utilizare a acestuia pentru Instalări WordPress pe calculator
Ce este Chmod, ce permisiuni să atribuiți fișierelor și folderelor (777, 755, 666) și cum se face prin PHP
Căutare Yandex după site și magazin online

Ziua bună tuturor. Alexey Gulynin este în legătură. În ultimul articol la care ne-am uitat crearea de tabele în html. În acest articol aș dori să vorbesc despre o problemă pe care cu siguranță o vei întâlni (dacă nu ai întâlnit-o deja) în practica ta. Și această problemă este legată de codificare pe site. Se întâmplă adesea această situație: stai, vii cu ceva, iar în final gândurile tale sunt exprimate în cod scris. Vă deschideți creația în browser și există o prostie completă scrisă acolo, sau așa cum o numesc de obicei această prostie - „krakozyabry”. Un lucru este evident aici, că problema cu codificarea pe site. Cel mai probabil codarea dvs. implicită este windows-1251 (chirilic), iar browserul încearcă să vă deschidă fișierul în codificare utf-8. Pe scurt despre ce este codificarea. O codificare este un fel de tabel care atribuie fiecărui caracter un anumit Codul mașinii. În consecință, literele noastre rusești într-o codificare au un singur cod, în altele - un cod diferit. Prieteni, folosiți codarea utf-8 peste tot și veți fi fericiți. Utf-8 se mai numește și Unicode.

Să creăm un document de testare în Notepad++ și să scriem următorul cod.

Testarea problemelor de codificare

În meniul Notepad++, asigurați-vă că „Codări” este în partea de sus - „Codificare în ANSI”. Acum vom crea artificial o problemă cu codificarea. Încercați să deschideți acest fișier în browser acum. Vom vedea hieroglife. Ideea aici este că am creat fișierul nostru în codificare ANSI (chirilic) și browserului i s-a spus că fișierul nostru este în codificare utf-8 ( ) .

Motivele pentru care probleme cu codarea pe site:

1) Valoarea incorectă a atributului set de caractere al etichetei meta.

2) În meniul Notepad++, verificați dacă codificarea fișierului este utf-8. Acest lucru trebuie făcut „Codări” - „Codificare în UTF-8 (fără BOM)”. Pe Internet puteți găsi o definiție a ceea ce este „BOM”, dar nu este clară. Din câte am înțeles, la începutul documentului este scris spatiu de nerupere cu lățimea zero. Nu avem nevoie, așa că pune întotdeauna „fără BOM”.

3) Se întâmplă ca primele două puncte să fi fost finalizate, dar tot mai apar prostii pe paginile site-ului. Aici problema poate fi în setările serverului, de exemplu. hosting transferă direct antetele fișierelor noastre și setează codarea implicită. Să încercăm să-l înțărcăm de la a face asta. Ar trebui să existe un fișier .htaccess în directorul rădăcină al site-ului. Folosind acest fișier, puteți face ajustări la operațiunea de găzduire. Dacă nu aveți acest fișier, atunci trebuie să îl creați. Este convenabil să faci asta în Editor de notepad++. ÎN acest fișier trebuie sa scrieti urmatorul cod:

AddDefaultCharset UTF-8

Cu această instrucțiune îi spunem serverului că codificarea noastră implicită este „utf-8”. Dacă acest lucru nu ajută, atunci trebuie să scrieți următorul cod în același fișier:

Charset dezactivat pe AddDefaultCharset Off

Aici încercăm să spunem serverului că nu dorim o codificare implicită. Dacă după aceste mașinațiuni nimic nu ajută, atunci trebuie să-i scrieți hosterului și să rezolvați această problemă cu el. Poate iti va spune ceva.

Creați un formular de feedback

Despre problemele legate de codificarea fișierelor

La crearea unui formular de feedback, apar adesea probleme cu codificarea fișierelor, motiv pentru care mesajul primit Scrisoare prin e-mail constă din pătrate minunate, diamante și alte „biscuiți”.

Să aruncăm o privire mai atentă la această neînțelegere flagrantă. După cum știți, codificarea (set de caractere) este o metodă de reprezentare a caracterelor pentru transmiterea lor. La urma urmei, orice informație care circulă într-un computer este o succesiune de zerouri și unu. Codificarea caracterelor este formată din mai mulți octeți, de obicei de la 1 la 4. Există multe codificări, iar browserul trebuie să stabilească corect în care dintre ele este scrisă pagina de site care se deschide.

În cele mai multe cazuri browsere moderne face față cu succes acestei sarcini în mod independent. Cu toate acestea, pentru a determina corect codificarea, se obișnuiește să se furnizeze un indiciu în codul HTML folosind o metaetichetă, de exemplu,
sau
.
.

Designerii web începători cred uneori în mod eronat că este suficient să lipiți metaetichetă necesarăîn partea de sus a paginii - și totul va fi OK! Este o iluzie. După cum a scris pe bună dreptate Kozma Prutkov: „Dacă vezi inscripția „Bivol” pe o cușcă cu un elefant, nu-ți crede ochilor.” Este necesar nu numai să scrieți, de exemplu, charset=utf-8, ci și să vă asigurați că pagina realizat efectiv în codificarea specificată.

Cel mai simplu mod de a afla codarea reală a unei pagini este prin deschiderea acesteia în orice browser și selectarea elementului din meniu Vizualizare - Codificare. Când schimbați codările, determinați care dintre ele va afișa corect pagina - aceasta va fi codificarea dvs. reală. Indicați-o în metaeticheta. Dacă doriți să schimbați codificarea, atunci pentru a face acest lucru trebuie să mergeți la setările programului cu care creați site-ul și să setați codificarea necesară. De exemplu, în program Adobe Dreamweaver Pentru a face acest lucru, trebuie să selectați o secțiune de meniu Editare - Setări... - Creare document - Codare implicită. Codificări utilizate în mod obișnuit set de caractere=utf-8 sau set de caractere=windows-1251.

cometariu: Este recomandabil să plasați metaeticheta care indică codificarea chiar la începutul codului HTML, imediat după etichetă. astfel încât browserul să selecteze codificarea corectă înainte de a afișa titlul paginii (tag ), care apare în bara albastră din partea de sus a ferestrei browserului. Altfel, în loc de