Problemen met onjuiste codering van webpagina's oplossen.

Goede dag allemaal. Alexey Gulynin heeft contact opgenomen. In het laatste artikel hebben we gekeken tabellen maken in html. In dit artikel wil ik het hebben over een probleem dat u zeker tegen zult komen (als u het nog niet bent tegengekomen) in uw praktijk. En dit probleem houdt verband met codering op de site. Deze situatie komt vaak voor: je gaat zitten, bedenkt iets en uiteindelijk worden je gedachten uitgedrukt in geschreven code. Je opent je creatie in de browser en er staat complete onzin geschreven, of zoals ze deze onzin gewoonlijk noemen - "krakozyabry". Eén ding is hier duidelijk: dat probleem met codering op de site. Waarschijnlijk is uw standaardcodering Windows-1251 (Cyrillisch), en de browser probeert uw bestand te openen in UTF-8-codering. Kort over wat codering is. Een codering is een soort tabel die aan elk teken een bepaalde machinecode toewijst. Dienovereenkomstig hebben onze Russische letters in één codering één code, in andere - een andere code. Vrienden, gebruik overal utf-8-codering en je zult gelukkig zijn. Utf-8 wordt ook wel Unicode genoemd.

Laten we een testdocument maken in Notepad++ en de volgende code schrijven.

Coderingsproblemen testen

Zorg ervoor dat in het Notepad++-menu "Coders" bovenaan staat - "Coderen in ANSI". Nu zullen we kunstmatig een probleem met codering creëren. Probeer dit bestand nu in uw browser te openen. We zullen hiërogliefen zien. Het punt hier is dat we ons bestand in ANSI (Cyrillische) codering hebben gemaakt en dat de browser te horen kreeg dat ons bestand in codering was utf-8 ( ) .

De redenen waarom problemen met codering op de site:

1) Ongeldige waarde charset-attribuut van de metatag.

2) Controleer in het Notepad++-menu of de bestandscodering utf-8 is. Dit moet worden gedaan "Coders" - "Coderen in UTF-8 (zonder stuklijst)". Op internet kun je een definitie vinden van wat “BOM” is, maar deze is onduidelijk. Zoals ik het begrijp, staat het aan het begin van het document geschreven niet-brekende ruimte met een breedte van nul. Wij hebben het niet nodig, dus zet altijd "zonder stuklijst".

3) Het komt voor dat de eerste twee punten zijn voltooid, maar er verschijnt nog steeds onzin op de pagina's van de site. Hier ligt het probleem mogelijk in de serverinstellingen, d.w.z. hosting draagt ​​rechtstreeks headers voor onze bestanden over en stelt de standaardcodering in. Laten we proberen hem ervan te weerhouden dit te doen. Er zou een .htaccess-bestand in de hoofdmap van de site moeten staan. Met dit bestand kunt u aanpassingen aanbrengen in de hostingoperatie. Als u dit bestand niet heeft, moet u het maken. Het is handig om dit binnen te doen Kladblok-editor++. IN dit bestand je moet de volgende code schrijven:

AddDefaultCharset UTF-8

Met deze instructie vertellen we de server dat onze standaardcodering "utf-8" is. Als dit niet helpt, moet u de volgende code in hetzelfde bestand schrijven:

Charsetdisable op AddDefaultCharset Uit

Hier proberen we de server te vertellen dat we geen standaardcodering willen. Als na deze machinaties niets helpt, moet je naar de host schrijven en beslissen dit probleem met hem. Misschien zal hij je iets vertellen.

Als de volgorde van de bits er niet redelijk uitziet (vanuit menselijk oogpunt), dan is dit een geval waarin het document hoogstwaarschijnlijk op een gegeven moment onjuist is geconverteerd. We nemen bijvoorbeeld de tekst ÉGÉìÉRÅ[ÉfÉBÉìÉOÇÕìÔǵÇ≠ǻǢ, en, zonder aan iets beters te denken, slaan we deze op in UTF-8. De teksteditor ging ervan uit dat hij de tekst correct had gelezen met Mac Roman-codering en nu moet deze in een andere codering worden opgeslagen. Al deze tekens zijn immers geldig in Unicode. Ik bedoel, Unicode heeft een clausule voor É, voor G, enzovoort. Dus we slaan het gewoon op in 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

Dit is hoe de tekst ÉGÉìÉRÅ[ÉfÉBÉìÉOÇÕìÔǵÇ≠ǻǢ nu wordt weergegeven als een reeks UTF-8-bits. Deze bitreeks staat volledig los van wat er in het originele document stond. Welke codering we ook gebruiken om deze reeks te openen, we zullen nooit de originele tekst エンコーディングは難しくない zien. Hij is gewoon verdwaald. Het zou kunnen worden hersteld als we de originele Shift-JIS-codering kenden en de tekst behandelden als Mac Roman en deze vervolgens opsloegen als UTF-8. Maar zulke wonderen zijn zeldzaam.

Vaak is een bepaalde bitreeks onjuist in een bepaalde codering. Als we zouden proberen het originele document in ASCII te openen, zouden we zien dat sommige tekens wel werden herkend, maar andere niet. Het programma dat u gebruikt, kan besluiten om simpelweg de bytes weg te gooien die niet in de huidige codering passen, of ze te vervangen door vraagtekens. Of met een speciaal Unicode-vervangingsteken: � (U+ FFFD). Als u het document opslaat na de procedure voor het verwijderen van ongepaste tekens, raakt u ze voor altijd kwijt.

Als u de codering verkeerd raadt en deze vervolgens in een andere opslaat, verpest u het document. U kunt proberen het probleem te verhelpen, maar deze pogingen eindigen meestal niet in succes. Bit-shifted magie blijft meestal niet-werkende magie: als een kompres voor de doden.

En hoe verander je de coderingen correct?

Het is heel eenvoudig! U moet de codering van een specifiek stuk tekst (bitreeks) kennen en deze gebruiken om het te decoderen. Dat is alles wat er is. Als u een programma schrijft dat tekst van de gebruiker ontvangt, bepaal dan in welke codering het dit zal doen. Elk tekstveld moet weten in welke codering het gegevens accepteert. Voor elk type bestand dat een gebruiker in een programma kan laden, moet een codering worden gedefinieerd. Of er zou een manier moeten zijn om de gebruiker ernaar te vragen. De informatie kan worden geleverd door het bestandsformaat of door de gebruiker (de meesten van hen zullen dit natuurlijk niet weten totdat ze het artikel hebben gelezen).

Als u tekst van de ene codering naar de andere moet converteren, gebruikt u speciaal gereedschap. Conversie is de vervelende taak om twee codepagina's te vergelijken en te beslissen dat teken 152 in codering A hetzelfde is als teken 4122 in codering B, en vervolgens de bits te veranderen. Het is niet nodig om het wiel opnieuw uit te vinden: elke gangbare programmeertaal beschikt over bit- en codepagina-abstracte hulpmiddelen voor het converteren van tekst van codering naar codering.

Stel dat uw toepassing bestanden in GB18030 moet accepteren, maar dat u intern in UTF-32 draait. De iconv-tool kan de conversie in één regel uitvoeren: iconv("GB18030", "UTF-32", $string). De karakters blijven hetzelfde, ook al is de bitrepresentatie veranderd.

teken GB18030-codering UTF-32-codering
縧 10111111 01101100 00000000 00000000 01111110 00100111

Dat is alles. De inhoud van de string is in menselijk opzicht niet veranderd, maar het is nu een geldige UTF-32-string. Als je er in UTF-32 mee blijft werken, heb je geen last van onleesbare karakters. Zoals we eerder hebben besproken, kunnen echter niet alle coderingen alle tekens weergeven. Het is in geen enkele Europese taalcodering mogelijk om het teken 縧 te coderen. En er kan iets vreselijks gebeuren.

Alles is in Unicode-formaat

Dit is de reden waarom er in de 21e eeuw geen excuus meer is om Unicode niet te gebruiken. Sommige gespecialiseerde coderingen voor Europese talen kunnen beter presteren dan taalspecifieke Unicode. Maar zolang u niet met terabytes aan speciale tekst hoeft te werken (wat VEEL is), hoeft u zich daar geen zorgen over te maken. Problemen die voortkomen uit incompatibele coderingen zijn veel erger dan een verloren gigabyte. En dit argument zal alleen maar sterker worden naarmate de dataopslag en de kanaalbreedte groeien en goedkoper worden.

Als het systeem met andere coderingen moet werken, converteer de tekst dan eerst naar Unicode en converteer deze weer terug als u deze ergens moet uitvoeren. Anders zult u elk geval van toegang tot gegevens zeer zorgvuldig moeten controleren en de nodige conversies moeten uitvoeren, indien mogelijk zonder informatie te verliezen.

Gelukkige ongelukken

Ik had een website gekoppeld aan een database. Mijn applicatie verwerkte alles als UTF-8 en sloeg het als zodanig in de database op, en alles was geweldig, maar toen ik naar het databasebeheergebied ging, kon ik niets begrijpen.
- anonieme redneck-codeur

Er doen zich situaties voor waarin coderingen verkeerd worden verwerkt, maar alles werkt nog steeds prima. Het komt vaak voor dat de databasecodering is ingesteld op latin-1, maar de applicatie werkt met UTF-8 (of een andere). Over het algemeen is elke combinatie van 1 en 0 geldig in single-byte Latin-1. Als de database gegevens ontvangt van een applicatie zoals 11100111 10111000 10100111, dan slaat hij deze met plezier op, in de veronderstelling dat de applicatie 縧 bedoelde. Waarom niet? Later stuurt de database dezelfde bits terug naar de applicatie, die blij is omdat deze het bedoelde UTF-8-teken 縧 heeft ontvangen. Maar de databasebeheerinterface weet dat Latin-1 wordt gebruikt, en dit is het resultaat: er kan niets worden begrepen.
De dwaas won eenvoudigweg de loterij, ook al stonden de sterren niet aan zijn kant. Elke bewerking op tekst in de database kan werken, maar wordt mogelijk niet uitgevoerd zoals bedoeld, omdat de database de tekst niet correct waarneemt. In het ergste geval zal de database onbedoeld alle tekst vernietigen en twee jaar na de installatie een willekeurige bewerking uitvoeren vanwege onjuiste codering (en natuurlijk geen back-up voor u).

UTF-8 en ASCII

Het geniale van UTF-8 is de binaire compatibiliteit met ASCII, die de facto de basis vormt voor alle coderingen. Alle ASCII-tekens bezetten maximaal bytes in UTF-8 en gebruiken dezelfde bits als in ASCII. Met andere woorden: ASCII kan 1:1 worden toegewezen aan UTF-8. Elk niet-ASCII-teken neemt 2 of meer bytes in beslag in UTF-8. De meeste programmeertalen die ASCII als broncodecodering gebruiken, maken het mogelijk dat UTF-8-tekst rechtstreeks in de tekst wordt opgenomen:

Opslaan in UTF-8 levert de reeks op:

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

Slechts 12 van de 17 bytes (die beginnen met 1) zijn UTF-8-tekens (2 tekens van 3 bytes). Overige karakters zijn in ASCII. De parser leest het volgende:

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

De parser behandelt alles achter het citaat als een reeks bits die moeten worden behandeld zoals ze zijn, helemaal tot aan het andere citaat. Als u deze reeks eenvoudigweg uitvoert, voert u de tekst uit in UTF-8. U hoeft verder niets te doen. De parser hoeft utf-8 niet specifiek te ondersteunen, hij hoeft strings alleen maar letterlijk te nemen. Eenvoudige parsers kunnen Unicode op deze manier ondersteunen zonder Unicode daadwerkelijk te ondersteunen. Veel programmeertalen ondersteunen echter expliciet Unicode.

Coderingen en PHP.

PHP ondersteunt geen Unicode. Toegegeven, hij ondersteunt het vrij goed. De vorige paragraaf laat zien hoe je zonder problemen UTF-8-tekens rechtstreeks in programmatekst kunt opnemen, omdat UTF-8 achterwaarts compatibel is met ASCII, en dat is alles wat PHP nodig heeft. De bewering dat "PHP Unicode niet ondersteunt" is echter waar en heeft voor veel verwarring gezorgd in de PHP-gemeenschap.

Valse beloften

Een van mijn grootste ergernissen waren de functies utf8_encode en utf8_decode. Ik zie vaak domme dingen als "Om Unicode in PHP te gebruiken, moet je utf8_encode aanroepen bij de invoertekst en utf8_decode bij de uitvoer." Deze twee functies beloven een soort automatische conversie van UTF-8-tekst, wat zogenaamd nodig is, omdat “PHP Unicode niet ondersteunt.” Als je dit artikel niet diagonaal leest, dan weet je dat

1. Er is niets bijzonders aan UTF-8
2. Je kunt achteraf geen tekst naar UTF-8 coderen

Laat me punt 2 uitleggen: elke tekst is al ergens mee gecodeerd. Wanneer u regels invoegt in broncode, ze hebben al codering. Om precies te zijn, de codering die de jouwe momenteel gebruikt. teksteditor. Als u ze uit de database haalt, zijn ze al gecodeerd. Als je ze uit een bestand leest... weet je het al, toch?

De tekst is UTF-8-gecodeerd of ongecodeerd. Zo niet, dan is het gecodeerd in ASCII, ISO-8859-1, UTF-16 of iets anders. Als het niet in UTF-8 staat, maar wel "UTF-8-tekens" zou moeten bevatten, dan is er sprake van cognitieve dissonantie. Als de tekst nog steeds de benodigde tekens bevat die in UTF-8 zijn gecodeerd, dan is deze in UTF-8.

Dus wat doet utf8_encode in vredesnaam?

"Converteert een ISO-8859-1-tekenreeks naar UTF-8-codering"

Ja! De auteur wilde zeggen dat de functie tekst converteert van ISO-8859-1 naar UTF-8. Daar is het voor. Waarschijnlijk heeft een onvoorzichtige Europeaan er zo'n vreselijke naam aan gegeven. Hetzelfde geldt voor utf8_decode. Deze functies zijn voor niets anders toepasbaar dan het converteren van ISO-8859-1 naar UTF-8. Als je een ander coderingspaar nodig hebt, gebruik dan iconv.
utf8_encode is niets voor jou toverstaf, die over elk woord moet worden bewogen omdat “PHP Unicode niet ondersteunt.” Ze belt meer problemen, dan besluit - zeg dank aan die Europese en onwetende programmeurs.

Inheems-shmativny

Dus wat bedoelen ze als ze zeggen dat een taal Unicode ondersteunt? Waar het om gaat is of de taal ervan uitgaat dat één teken één byte in beslag neemt of niet. PHP geeft je dus toegang tot het geselecteerde karakter door de string als een karakterarray te behandelen:

Als $string een codering van één byte heeft, geeft dit ons het eerste teken. Maar alleen omdat 'karakter' hetzelfde is als 'byte' bij codering van één byte. PHP geeft gewoon de eerste byte zonder zelfs maar aan de karakters te denken. Strings voor PHP zijn niets meer dan reeksen bytes, niet meer en niet minder. Deze “leesbare karakters” van jou zijn niets meer dan een menselijke uitvinding, PHP geeft er niets om.

01000100 01101111 01101110 00100111 01110100
Doe het niet
01100011 01100001 01110010 01100101 00100001
c a r e!

Voor velen geldt hetzelfde standaard kenmerken, zoals substr, strpos, trim en andere. Ondersteuning stopt waar de byte-naar-teken-toewijzing eindigt:

11100110 10111100 10100010 11100101 10101101 10010111
漢 字

$tekenreeks voor de opgegeven lijn zal opnieuw alleen de eerste byte retourneren, gelijk aan 11100110. Met andere woorden, de derde byte van het teken 漢. De reeks 11100110 is onjuist voor UTF-8, dus de string is nu ook onjuist. Als u dat ook denkt, kunt u een andere codering proberen, waarbij 11100110 een geldig willekeurig teken zal zijn. Je kunt plezier hebben, maar niet op de gevechtsserver.

Dat is alles. "PHP ondersteunt Unicode niet" betekent dat de meeste functies in de taal ervan uitgaan dat één byte gelijk is aan één teken, wat ertoe leidt dat multi-byte tekens worden afgekapt of dat de tekenreekslengte onjuist wordt berekend. Dit betekent niet dat je Unicode niet kunt gebruiken in PHP, of dat elke tekst via utf8_encode moet worden uitgevoerd, of andere onzin.

Gelukkig is dat zo speciale uitbreiding, wat al het belangrijke toevoegt string-functies, maar met ondersteuning voor multibyte-coderingen. mb_substr($string, 0, 1, ‘UTF-8’) op de bovenstaande regel retourneert correct de reeks 11100110 10111100 10100010, overeenkomend met het teken 漢. Omdat de functie moet nadenken over wat hij doet, moet er een codering aan worden doorgegeven. Daarom gebruiken deze functies een parameter $encoding. Overigens kan de codering globaal worden ingesteld voor alle mb_-functies met behulp van mb_internal_encoding.

Het gebruik en misbruik van PHP-foutafhandeling

Het hele probleem met (niet-)Unicode-ondersteuning in PHP is dat het de tolk niets kan schelen. Bytereeksen, ha. Het maakt niet uit wat ze bedoelen. Er wordt niets anders gedaan dan strings in het geheugen opslaan. PHP heeft niet eens zo’n concept: codering. En zolang je de snaren niet hoeft te manipuleren, maakt het niet uit. Er wordt gewerkt met reeksen bytes die door iemand als karakters kunnen worden waargenomen. PHP vereist alleen dat u de broncode opslaat in iets dat ASCII-compatibel is. De PHP-parser zoekt naar specifieke tekens die vertellen wat hij moet doen. 00100100 zegt: “declareer een variabele”, 00111101 – “toewijzen”, 00100010 – het begin of einde van een regel, enz. Alles wat niet belangrijk is voor de parser, wordt behandeld als letterlijke bytereeksen. Dit geldt ook voor alles wat tussen aanhalingstekens staat. Dit betekent:

1. U kunt de PHP-broncode niet opslaan in een codering die niet compatibel is met ASCII. In UTF-16 wordt het aanhalingsteken bijvoorbeeld gecodeerd als 00000000 00100010. Voor PHP, dat alles als ASCII behandelt, is dit een NUL-byte gevolgd door een aanhalingsteken. PHP zou waarschijnlijk voor elk karakter haperen en NUL blijken te zijn.
2. U kunt PHP opslaan in een ASCII-compatibele codering. Als de eerste 128 coderingspunten overeenkomen met ASCII, zal PHP ze opeten. Alle belangrijke karakters voor PHP vallen binnen de eerste 128 punten gedefinieerd door ASCII. Als stringletterlijke waarden iets bevatten dat deze limiet overschrijdt, zal PHP er geen aandacht aan besteden. U kunt de bron opslaan in ISO-8859-1, Mac Roman, UTF-8 of een andere codering. Tekenreekstekens in uw code krijgen de codering waarin u het bestand opslaat.
3. Elk extern bestand voor PHP kan het elke codering hebben. Als de parser het bestand niet hoeft te verwerken, zal hij blij zijn.

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

   Het bovenstaande plaatst eenvoudigweg de bytes van bar.txt in de variabele $foo. PHP zal niet proberen de inhoud te interpreteren, coderen of anderszins te manipuleren. Het bestand kan binaire gegevens of een afbeelding bevatten, PHP maakt het niet uit.

4. Als de externe en interne coderingen moeten overeenkomen, dan zou dat ook echt moeten gebeuren. Een veelvoorkomend geval is lokalisatie: in de code schrijf je iets als echo localize('Foobar'), en in het externe bestand is het:

   msgstr "Foobar"
   msgstr "フーバー"
   

   Beide Foobar-strings moeten een identieke bitsgewijze representatie hebben. Als de broncode in ASCII is en de lokalisatiecode in UTF-16, heeft u pech. Er moet extra conversie worden uitgevoerd.

Een scherpzinnige lezer zou zich bijvoorbeeld kunnen afvragen of het mogelijk is om een ​​UTF-16-byte opeenvolgend op te slaan in een letterlijke bronbestand in ASCII, en het antwoord zal altijd zijn: natuurlijk.

01100101 01100011 01101000 01101111 00100000 00100010
e c ho "
11111110 11111111 00000000 01010101 00000000 01010100
(UTF-16-markering) UT
00000000 01000110 00000000 00101101 00000000 00110001
F-1
00000000 00110110 00100010 00111011
6 " ;

De eerste regel en de laatste 2 bytes zijn afkomstig van ASCII. De rest wordt weergegeven in UTF-16, 2 bytes per teken. De leidende 11111110 11111111 op de tweede regel is een markering voor het begin van tekst in UTF-16 (vereist door de standaard, PHP heeft hier nog nooit van gehoord). Dit script voert de string “UTF-16” uit, gecodeerd in UTF-16, omdat het eenvoudigweg de bytes tussen twee aanhalingstekens uitvoert, wat resulteert in de tekst “UTF-16”, gecodeerd in UTF-16. Aan de andere kant is de broncode niet helemaal correct in ASCII of UTF-16, dus je kunt een editor openen en plezier maken.

Totaal

PHP ondersteunt Unicode, of beter gezegd, elke codering redelijk nauwkeurig, zolang je de parser maar zijn werk kunt laten doen en de ontwikkelaar kan laten begrijpen wat hij doet. U hoeft alleen voorzichtig te zijn bij het werken met tekenreeksen: delen, spaties verwijderen, tellen en alle andere bewerkingen waarbij met tekens moet worden gewerkt, niet met bytes. Als u niets anders doet met tekenreeksen dan lezen en uitvoeren, is het onwaarschijnlijk dat u problemen tegenkomt die in andere talen niet voorkomen.

Talen met coderingsondersteuning

Dus wat betekent het dat een taal Unicode ondersteunt? Javascript ondersteunt bijvoorbeeld Unicode. In feite is elke string in Javascript gecodeerd in UTF-8. En dit is de enige codering waarmee Javascript werkt. Je komt er gewoon niet in JavaScript-reeks niet in UTF-8. Javascript aanbidt Unicode in die mate dat er eenvoudigweg geen tools in de kern van de taal zijn om met andere coderingen te werken. Omdat Javascript meestal in de browser draait, heb je geen probleem: de browser kan triviale I/O-codering en decoderingslogica uitvoeren.

Andere talen ondersteunen eenvoudigweg coderingen. Innerlijk werk uitgevoerd in een enkele codering, vaak UTF-16. Maar dit betekent dat hen moet worden verteld in welke codering de tekst staat, anders zullen ze proberen deze zelf te bepalen. Het is noodzakelijk om aan te geven in welke codering de broncode is opgeslagen, in welke codering het te lezen bestand is opgeslagen en in welke codering de uitvoer moet worden gemaakt. De taal voert de conversie direct uit als is opgegeven dat Unicode moet worden gebruikt. Ze doen alles wat in PHP semi-automatisch ergens op de achtergrond moet gebeuren. Niet beter of slechter dan PHP, gewoon anders. Goed nieuws Het punt is dat stringfuncties eindelijk gewoon werken, en dat je je geen zorgen hoeft te maken over de vraag of de string multi-bytetekens bevat of niet, met welke functies je moet werken en andere dingen die je in PHP zou moeten doen.

Wild Unicode

Omdat Unicode zoveel oplost verschillende problemen en werkt in veel verschillende scenario's, je moet ervoor betalen door in de wildernis te graven. De Unicode-standaard bevat bijvoorbeeld informatie over het oplossen van problemen zoals het verenigen van de hiërogliefen YAKK. Veel symbolen die Japan, China en Korea gemeen hebben, worden enigszins anders weergegeven. Of problemen bij het converteren van tekens uit kleine letters naar boven, omgekeerd, of heen en weer, wat niet altijd zo eenvoudig is als bij de coderingen van West-Europese talen. Sommige symbolen kunnen door verschillende items worden weergegeven. De letter ö kan bijvoorbeeld worden weergegeven door het item U+00F6 (“LATIJNSE KLEINE LETTER O MET DIERESIS”) of als twee items U+006F (“KLEINE LETTER O”) EN U+0308 (“VERVANGENDE DIARESIS”) , wat de letter o Met betekent. In UTF-8 is het 2 bytes of 3 bytes, wat in beide gevallen een normaal teken vertegenwoordigt. Daarom zijn er normalisatieregels in de standaard, d.w.z. hoe u deze formulieren van de ene naar de andere kunt converteren. Dit en nog veel meer valt buiten het bestek van dit artikel, maar u moet wel op de hoogte zijn van deze punten.

Ik heb het niet nog een keer geforceerd!

1. Tekst is altijd een reeks bits die met behulp van tabellen in natuurlijke taal moeten worden vertaald. Ongeldige tabel - ongeldig symbool.
2. Je kunt niet rechtstreeks met tekst werken; je werkt altijd met stukjes die verpakt zijn in abstracties. De fouten zijn te wijten aan fouten in een van de abstracties.
3. Systemen die informatie naar elkaar verzenden, moeten altijd de werkende codering aangeven. De site vertelt de browser bijvoorbeeld dat deze informatie in UTF-8 levert.
4. Tegenwoordig is UTF-8 achterwaarts compatibel met ASCII, ondanks het feit dat het vrijwel elk teken kan coderen, en in de meeste gevallen nog steeds relatief efficiënt is. Andere coderingen hebben ook hun nut, maar er moet een goede reden zijn om je bezig te houden met coderingen die slechts een deel van Unicode ondersteunen.
5. Zowel het programma als de programmeur moeten omgaan met het probleem van het matchen van een byte en een teken.

Nu hoef je geen excuses meer te verzinnen als je de tekst opnieuw verprutst.

Tags: tags toevoegen

Vandaag de codering ASCII is een standaard voor het weergeven van de eerste 128 tekens (inclusief cijfers en leestekens) van het Engelse alfabet, gepresenteerd in een specifieke volgorde.

Met zelfs 1 byte kunt u echter 2 keer meer waarden coderen, dat wil zeggen niet 128, maar maar liefst 256 verschillende betekenissen. Daarom snel genoeg om de basis te vervangen ASCII er begonnen meer uitgebreide versies van deze beroemde en populaire codering te verschijnen, waarin ook karakters van alfabetten en dienovereenkomstig tekst van verschillende talen, waaronder Russisch, werden gecodeerd.

ASCII-extensies voor Rusland

Vandaag voor Russische gebruikers prioriteit is codering Windows1251 en ook Unicode-codering UTF 8 waaruit voortkwam ASCII.

In feite kan iemand een heel terechte vraag hebben: “Waarom zijn deze tekstcoderingen überhaupt nodig?”
Het is de moeite waard eraan te denken dat een computer slechts een machine is die strikt volgens de instructies moet handelen. Om duidelijk te maken wat er met elk geschreven teken moet gebeuren, wordt het weergegeven als een set vectorvormen, waarvan elke set wordt verzonden naar juiste plaats zodat de ene of de andere aanduiding op het scherm verschijnt.

Lettertypen zijn verantwoordelijk voor de vorming van vectorvormen en het coderingsproces zelf is afhankelijk van het besturingssysteem en de programma's die daarin worden gebruikt. Elke tekst is dus in essentie een bepaalde reeks bytes, elk vertegenwoordigt de codering van één geschreven teken. Een programma dat afgedrukte informatie op het scherm weergeeft (dit kan een browser of tekstverwerker), parseert de code, vindt een geschikte mapping op basis van de code in de coderingstabel, converteert deze naar de vereiste vectorvorm en geeft deze weer in een tekstbestand.

Codering CP866 en KOI8-R werden op grote schaal gebruikt vóór de komst van het grafische besturingssysteem, dat over de hele wereld populair werd - Ramen. Nu is de meest populaire codering die Russisch ondersteunt Windows1251.

Het is echter niet de enige, dus fabrikanten van lettertypen voor het Russisch worden gebruikt software Van tijd tot tijd, zelfs tot op de dag van vandaag, doen zich problemen voor in verband met de onjuiste weergave van symbolen en het verschijnen van de zogenaamde krakozyabry. Deze lastige hiërogliefen zijn het resultaat onjuist gebruik coderingstabellen, dat wil zeggen dat er tijdens het coderen en decoderen verschillende tabellen werden gebruikt.

Dezelfde situatie doet zich voor op websites, blogs en andere bronnen waar informatie in het Russisch en andere buitenlandse karakters dan het Engels staat. Deze situatie bepaalde de belangrijkste voorwaarde voor het creëren van een universele codering waarmee je tekst in elke taal kunt coderen, zelfs in het Chinees, waar er aanzienlijk meer tekens zijn dan 256.

Universele coderingen

De eerste versie van de universele codering die binnen het Unicode-consortium werd ontwikkeld, was de codering UTF32. Er werden 32 bits gebruikt om elk teken te coderen. De codering is nu geïmplementeerd enorme hoeveelheid tekenen, maar er verscheen een ander probleem - voor de meerderheid Europese landen zo'n nummer extra karakters het was volkomen onnodig. De documenten bleken immers erg zwaar. Daarom vervangen UTF32 kwam UTF 16, die de basis is geworden voor alle symbolen die in ons land en daarbuiten worden gebruikt.

Maar er waren nog steeds heel veel ontevreden mensen. Bijvoorbeeld degenen die alleen binnen communiceerden Engels, sinds bij verhuizing van ASCII naar UTF 16 hun documenten werden nog steeds groter, en aanzienlijk, bijna twee keer.
Het resultaat was codering met variabele lengte UTF 8, waardoor het mogelijk werd het gewicht van de tekst niet te vergroten.

Krakozyabry en methoden om ermee om te gaan

Over het algemeen wordt de codering ingesteld op de pagina waar het informatie bericht. Als gevolg hiervan wordt aan het begin van het document een soort markering gevormd waarin het direct wordt onthouden omgekeerde volgorde tekencodes worden geschreven UTF16.

Als er iets is afgedrukt UTF-8, dan is er aan het begin geen markering, omdat de mogelijkheid om de tekencode in omgekeerde volgorde in deze codering te schrijven afwezig is.

Daarom moet u alles wat u in de editor typt, zonder markeringen opslaan ( BOM) om de kans te verkleinen dat er wartaal in het document verschijnt.

Nog één nuttig advies om krakozyabrs te bestrijden - schrijf in de kop van de code van elke pagina van de site informatie over de juiste tekstcodering, zodat geen lokalehost, was er ook geen verwarring op de server.

Bijvoorbeeld zoals dit

Alle getallen (binnen bepaalde grenzen) in het computergeheugen worden gecodeerd als getallen binair systeem Afrekening. Om dit te doen, zijn er eenvoudige en duidelijke vertaalregels. Tegenwoordig wordt de computer echter veel breder gebruikt dan als een uitvoerder van arbeidsintensieve berekeningen. Tekst- en multimedia-informatie wordt bijvoorbeeld opgeslagen in het computergeheugen. Daarom rijst de eerste vraag:

Hoe worden tekens (letters) opgeslagen in het computergeheugen?

Elke letter behoort tot een specifiek alfabet waarin de symbolen elkaar opvolgen en dus genummerd kunnen worden met opeenvolgende gehele getallen. Elke letter kan worden geassocieerd met een positief geheel getal en de tekencode ervan worden genoemd. Het is deze code die in het geheugen van de computer wordt opgeslagen en wanneer deze op het scherm of papier wordt weergegeven, wordt deze "geconverteerd" naar het overeenkomstige symbool. Om de weergave van getallen te onderscheiden van de weergave van symbolen in het computergeheugen, is het ook nodig om informatie op te slaan over welke gegevens in een bepaald geheugengebied zijn gecodeerd.

De correspondentie van letters van een bepaald alfabet met codenummers vormt de zogenaamde coderingstabel. Met andere woorden, elk teken van een bepaald alfabet heeft zijn eigen numerieke code in overeenstemming met een bepaalde code codering tabel.

Er zijn echter veel alfabetten in de wereld (Engels, Russisch, Chinees, enz.). De volgende vraag is dus:

Hoe codeer ik alle alfabetten die op een computer worden gebruikt?

Laten we, om deze vraag te beantwoorden, de historische route volgen.

In de jaren zestig van de twintigste eeuw ontwikkelde het American National Standards Institute (ANSI) een tekencoderingstabel, die vervolgens in alle besturingssystemen. Deze tabel heet ASCII (American Standard Codeer voor Informatie-uitwisseling - Amerikaans standaardcode voor informatie-uitwisseling). Even later verscheen een uitgebreide versie van ASCII.

In overeenstemming met de tabel ASCII-codering Er wordt 1 byte (8 bits) toegewezen om één teken weer te geven. Een set van 8 cellen kan 28 = 256 accepteren verschillende betekenissen. De eerste 128 waarden (van 0 tot 127) zijn constant en vormen het zogenaamde hoofdgedeelte van de tabel, dat decimale cijfers, letters van het Latijnse alfabet (hoofdletters en kleine letters), leestekens (punt, komma, haakjes) bevat , enz.), evenals spaties en diverse dienst karakters(tabellering, regelinvoer, enz.). Waarden van 128 tot 255 vormen een extra deel van de tabel, waar het gebruikelijk is om tekens uit nationale alfabetten te coderen.

Omdat er zoveel nationale alfabetten zijn, zijn uitgebreide ASCII-tabellen in vele varianten verkrijgbaar. Zelfs voor de Russische taal zijn er verschillende coderingstabellen (Windows-1251 en Koi8-r zijn gebruikelijk). Dit alles zorgt voor extra moeilijkheden. We sturen bijvoorbeeld een brief die in de ene codering is geschreven en de ontvanger probeert deze in een andere codering te lezen. Als gevolg hiervan ziet hij Krakozabry. Daarom moet de lezer een andere coderingstabel voor de tekst toepassen.

Er is nog een probleem. De alfabetten van sommige talen hebben te veel tekens om in de toegewezen posities 128 tot en met 255 van de single-byte tekenset te passen.

Het derde probleem is wat te doen als de tekst meerdere talen gebruikt (bijvoorbeeld Russisch, Engels en Frans)? Je kunt niet twee tabellen tegelijk gebruiken...

Om deze problemen in één keer op te lossen, werd Unicode ontwikkeld.

Unicode-tekencoderingsstandaard

Om bovenstaande problemen op te lossen werd begin jaren ’90 een karaktercoderingsstandaard ontwikkeld, genaamd Unicode. Deze standaard Hiermee kunt u vrijwel elke taal en symbolen in de tekst gebruiken.

Unicode biedt 31 bits (4 bytes min één bit) om tekens te coderen. Hoeveelheid mogelijke combinaties geeft een ongelooflijk getal: 231 = 2.147.483.684 (dat wil zeggen meer dan twee miljard). Daarom beschrijft Unicode de alfabetten van alle bekende talen, zelfs ‘dode’ en fictieve talen, en bevat het veel wiskundige en andere talen. speciale karakters. Echter informatie capaciteit 31-bit Unicode is nog steeds te groot. Daarom wordt vaker de verkorte 16-bits versie (216 = 65.536 waarden) gebruikt, waarin alle moderne alfabetten zijn gecodeerd.

In Unicode zijn de eerste 128 codes hetzelfde als de ASCII-tabel.

Maak een feedbackformulier

Over problemen met bestandscodering

Bij het maken van een feedbackformulier ontstaan ​​er vaak problemen met de bestandscodering, vandaar het binnenkomende bericht E-mail brief bestaat uit prachtige vierkanten, ruiten en andere “crackers”.

Laten we dit flagrante misverstand eens nader bekijken. Zoals u weet, is codering (charset) een methode om tekens weer te geven voor hun verzending. Alle informatie die in een computer circuleert, bestaat immers uit een reeks nullen en enen. De tekencodering bestaat uit verschillende bytes, meestal van 1 tot 4. Er zijn veel coderingen en de browser moet correct bepalen in welke daarvan de geopende websitepagina is geschreven.

In de meeste gevallen moderne browsers deze taak met succes zelfstandig aan. Echter voor juiste definitie Het is gebruikelijk om in de HTML-code een hint te geven met behulp van bijvoorbeeld een metatag:
of
.
.

Beginnende webontwerpers denken soms ten onrechte dat het voldoende is om de gewenste metatag bovenaan de pagina in te voegen - en alles komt goed! Dit is een misvatting. Zoals Kozma Prutkov terecht schreef: “Als je de inscriptie “Buffalo” ziet op een kooi met een olifant, geloof je ogen dan niet.” Het is niet alleen nodig om bijvoorbeeld charset=utf-8 te schrijven, maar ook om ervoor te zorgen dat de pagina daadwerkelijk gemaakt in de opgegeven codering.

De eenvoudigste manier om de daadwerkelijke codering van een pagina te achterhalen, is door deze in een willekeurige browser te openen en het item in het menu te selecteren Bekijken - Coderen. Wanneer u de coderingen wijzigt, bepaal dan welke de pagina correct zal weergeven - dit zal uw echte codering zijn. Geef dit aan in de metatag. Als u de codering wilt wijzigen, moet u hiervoor naar de instellingen gaan van het programma waarmee u de site maakt en de vereiste codering instellen. In het programma bijvoorbeeld Adobe Dreamweaver Om dit te doen, moet u een menusectie selecteren Bewerken - Instellingen... - Document aanmaken - Standaardcodering. Meestal gebruikte coderingen tekenset=utf-8 of tekenset=windows-1251.

Opmerking: Het is raadzaam om de metatag die de codering aangeeft helemaal aan het begin van de HTML-code te plaatsen, direct na de tag zodat de browser de juiste codering selecteert voordat de paginatitel (tag ), dat verschijnt in de blauwe balk bovenaan het browservenster. Anders, in plaats van