Boekharbaeva N.A. Coderen van tekstinformatie

1. Laten we onze website als voorbeeld nemen: www.yourmaster.ru
2. Alle siteteksten worden gecodeerd geschreven en op de site geplaatst "windows-1251" en de browser wordt hierover niet geïnformeerd
3. De hostingserver verzendt standaard automatisch de volgende header:
   Inhoudstype: tekst/html; tekenset=utf-8

Als er een dergelijke discrepantie bestaat tussen de feitelijke codering van de site en de coderingsinformatie in de header die door de server wordt verzonden, zullen er problemen optreden bij het weergeven van de sitepagina's in de browser van de bezoeker.

Correcte codering is erg belangrijk!

Laten we proberen uit te leggen waarom.

Met de hierboven beschreven instellingen kan de browser van de gebruiker niet automatisch bepalen in welke codering de teksten op de bekeken site zijn geschreven. En hoogstwaarschijnlijk worden de pagina's onleesbaar weergegeven. Als u een dergelijke “miscommunicatie” tussen de browser en uw site tegenkomt, moet u dringend passende actie ondernemen. Anders zal dit hoogstwaarschijnlijk tot een reeks ernstige problemen leiden.

Ten eerste In dergelijke omstandigheden en site-instellingen zullen bezoekers voortdurend handmatig (met behulp van de selectiemethode) de codering voor de browser moeten opgeven om de site weer te geven. Om dit te doen, moet je er verschillende doen extra klikken muis. Maar je moet toegeven dat niet iedereen graag 2-3 muisklikken extra wil maken om de informatie op de pagina te zien. leesbare vorm. Bovendien weten veel mensen niet alleen niet hoe ze de weergavecodering in de browserinstellingen moeten wijzigen, maar ook wat codering in het algemeen is! De meeste bezoekers kunnen besluiten dat de site door de eigenaar is verlaten of door iemand is gehackt, en zullen proberen er niet meer naar terug te keren.

Ten tweede, als er een dubbelzinnige definitie is van de codering van de sitepagina, zoekmachines indexeren mogelijk de tekstinhoud van de site niet correct. Wat op zijn beurt brengt ernstige problemen met gebruikersverkeer van zoekmachines. Natuurlijk proberen sommige zoekmachines op de een of andere manier de juiste codering uit de inhoud van pagina's te bepalen, maar dit maakt het niet veel eenvoudiger. In de regel blijft het probleem bestaan.

Ik hoop dat je je hebt gerealiseerd dat problemen met codering een zeer ernstig obstakel kunnen worden voor het functioneren van de site, de ontwikkeling ervan en het aantrekken van regelmatige bezoekers.

Om te soortgelijke problemen er waren geen problemen met de codering, u moet de juiste instellingen maken, zowel op de hostingserver als op de sitepagina's.

De site-instellingen moeten zodanig zijn dat elke browser of elke robot zoekmachine ondubbelzinnig zou kunnen bepalen in welke codering de informatie van de site wordt verzonden!

Een probleem met de codering van een site oplossen

We hebben al gemerkt dat alle teksten op onze site in “windows-1251”-codering worden geschreven en naar de browser van de sitebezoeker worden verzonden. Wat kunnen we doen zodat de server waarop onze site wordt gehost in de header naar de browser verzendt juiste informatie over coderen? Laten we in volgorde verder gaan...

1. Om niet afhankelijk te zijn van serverinstellingen, op alle pagina's van de site, rechtstreeks in de HTML-code, moet u expliciet de volgende richtlijn schrijven met behulp van een metatag:

Het moet op alle pagina's worden geplaatst, bij voorkeur onmiddellijk na de openingstag . Hierdoor kan de browser automatisch de juiste weergavecodering selecteren bij het laden en interpreteren van de pagina in overeenstemming met de ontvangen richtlijn! Deze richtlijn alleen zou voldoende moeten zijn om ons probleem op te lossen. Maar zo was het in theorie ook bedoeld. Maar in de praktijk is deze richtlijn niet altijd voldoende. IN in zeldzame gevallen, maar het komt voor dat de browser als codering voor het weergeven van de pagina niet degene selecteert die is gespecificeerd in de richtlijn op de pagina zelf, maar degene die in de header van de server wordt verzonden! En als de coderingsinformatie die op twee plaatsen is opgegeven niet overeenkomt, kan het probleem blijven bestaan.

2. Zodat de server in zijn antwoord de juiste coderingsinformatie geeft, moet u een bestand maken in de hoofdmap van uw site .htaccess en schrijf daarin de richtlijn:

Standaardtekenset toevoegen Windows-1251

Vervolgens blijft de server standaard de coderingsheader verzenden, maar de naam van de codering komt overeen met de naam die van kracht is op de site zelf. Er zullen geen verschillen meer zijn in de namen.

Als het bestand .htaccess al op uw server bestaat, voeg dan eenvoudigweg de opgegeven richtlijn toe, bijvoorbeeld helemaal aan het begin. En in geen geval mag u onnodig informatie verwijderen die er al in staat!

Dat is de oplossing voor het probleem. Mee eens, dit is allemaal niet zo moeilijk?! Maar het is erg handig om allerlei problemen met de beruchte codering te voorkomen.

Door de twee hierboven genoemde aanbevelingen achtereenvolgens op te volgen, zullen browsers zeker geen fouten kunnen maken automatische selectie correcte codering voor het weergeven van informatie op uw website. We hebben de coderingsinformatie immers ondubbelzinnig, correct en zelfs in twee verschillende richtlijnen aangegeven!

Bijzondere situaties

Situatie één

Websitemakers, en vaker wel dan niet zelfs de klanten zelf, beginnen willekeurig en gedachteloos bepaalde wijzigingen aan de website aan te brengen, teksten te plaatsen zoals ze willen, enz. Tot het punt dat ze als gevolg daarvan op de website terecht kunnen komen. secties met informatie erin verschillende coderingen . Wij kunnen niet zeggen wat het is de juiste aanpak, maar we zullen wegduwen omdat dit gebeurt en dat is het. In dit geval kan er, zelfs als we de twee hierboven genoemde aanbevelingen volgen, nog steeds een situatie ontstaan ​​waarin de server informatie verstrekt over één codering en in de code HTML-pagina's een andere codering zal expliciet worden gespecificeerd. In zo'n geval misschien wel het meest eenvoudige oplossing zal het volgende zijn.

Naar bestand schrijven .htaccess richtlijn:

AddDefaultCharset Uit

Bij gebruik van deze richtlijn verzendt de server eenvoudigweg helemaal geen header met informatie over de codering van de verzonden pagina. Vervolgens zullen browsers uitgaan van de coderingsgegevens, die expliciet worden aangegeven in de HTML-code op de sitepagina's zelf. Bovendien kunnen de gegevens op één pagina worden gecodeerd Windows-1251, en op een andere pagina, bijvoorbeeld in utf-8. Het belangrijkste is om niet te vergeten om op deze pagina's de juiste metatags aan te geven met informatie over de juiste codering voor herkenning en weergave van tekst door de browser.

Hoewel een dergelijke oplossing de eenvoudigste is, is deze misschien niet de meest optimale en correcte. Op een goede manier moet u alle informatie op de site en in alle secties van de site in dezelfde codering plaatsen! En als er meerdere pagina's met een andere codering zijn, is het beter om de informatie daarin bij te werken door alle teksten naar de vereiste codering te converteren.

Situatie twee

Zoals u weet, selecteren de meeste sites bij het genereren van pagina's een deel van de gegevens uit een database, bijvoorbeeld MySQL (als de site is geschreven in PHP-taal). Vaak, bijhet verplaatsen van een website van de ene hosting naar de andere, kunnen er problemen ontstaan ​​als gevolg van coderingsmismatches tussen de gegevens die in de database zijn opgeslagen MySQL-gegevens en gegevens die bijvoorbeeld rechtstreeks in sitesjablonen zijn opgeslagen. Er kan zich dus een situatie voordoen dat bij het maken van één pagina deze gegevens in verschillende coderingen kan bevatten. Dit is misschien wel een van de meest onbeschofte mogelijke fouten met de codering op de site en het moet onmiddellijk worden opgelost. Anders kunnen er later extra problemen optreden bij het invullen en bewerken van de site.

De oplossing van dergelijke meningsverschillen met gegevens die in de database zijn opgeslagen, wordt bereikt door de coderingsinstellingen correct en expliciet in te stellen wanneer verbinding wordt gemaakt met de database en voordat gegevens daaruit worden opgehaald. Als de gegevens op onze website bijvoorbeeld zijn opgeslagen in Windows-1251-codering, dan moeten we gegevens uit de database in dezelfde codering lezen. Om dit te doen, na verbinding te hebben gemaakt met de database met behulp van PHP-functies mysql_connect() (of mysql_pconnect()) wel volgende verzoek SQL:

mysql_query("NAMEN INSTELLEN cp1251");

Dit verzoek, vertelt de MySQL-databaseserver dat alle gegevens worden opgeslagen en moeten worden verzonden in cp1251-codering (dit is de coderingsnaam die in MySQL wordt gebruikt in plaats van de eerder genoemde naam windows-1251, die wordt gebruikt bij het verzenden van HTML-gegevens).

Maar de beste manier is om de gegevenscodering te wijzigen in MySQL-database naar degene die op de site zelf wordt gebruikt. Dan hoeft de databaseserver geen onnodige bewerking uit te voeren om gegevens van het ene formaat naar het andere te converteren.

Opmerking

Als u een site heeft bezocht waarvan de codering om de een of andere reden verkeerd is gegaan, maar u deze echt nodig heeft nuttige informatie(zonder te wachten tot de site-ontwikkelaars de aanbevelingen opvolgen die we hierboven hebben vermeld), moet u handmatig de juiste paginacodering opgeven in de browserinstellingen. Dit kan meestal gedaan worden via het hoofdbrowsermenu: Weergave -> Codering-> Selecteer vervolgens de naam van de beoogde paginacodering uit de lijst. Misschien moet u, om te raden, deze procedure meer dan eens uitvoeren, waarbij u een of andere naam uit de lijst met coderingen kiest. Om het selectieproces te versnellen, raden wij u aan ze in de volgende volgorde te doorlopen: Cyrillisch (Windows-1251), Cyrillisch (UTF-8), Cyrillisch (KOI)8-R). Dit zijn de meest gebruikte coderingen op websites op RuNet.

De afgelopen twee jaar zijn er verschillende opmerkelijke vorderingen gemaakt bij de constructie van foutcorrectiecodes. Er zijn methoden gevonden om efficiënte, zeer lange codes te construeren; en, belangrijker nog, deze codes bleken geschikt te zijn praktische uitvoering. Tegelijkertijd is er een toenemende behoefte aan communicatiekanalen met een zeer hoge betrouwbaarheid, die gebruikt zouden kunnen worden in computercomplexen en diverse automatische uitrusting. Naarmate de behoefte aan grotere betrouwbaarheid toeneemt, neemt ook de kosteneffectiviteit van elektronica toe logische apparaten en de codeertheorie dieper wordt ontwikkeld, nadert de tijd waarin apparaten voor het detecteren en corrigeren van fouten, d.w.z. apparaten van het type dat in dit boek wordt beschreven, steeds belangrijker zullen worden belangrijke rol bij het creëren van complexe informatiesystemen.

Dit hoofdstuk introduceert het concept van een communicatiekanaal, beschrijft de rol van codes bij het verzenden van informatie en definieert blokcodes en andere belangrijke concepten worden geïntroduceerd.

1.1. Communicatiekanaal

Schematisch diagram digitaal systeem verbinding is te zien in afb. 1.1. Hetzelfde model beschrijft ook het informatieopslagsysteem, als de omgeving waarin de informatie is opgeslagen als een kanaal wordt beschouwd. Een typisch kanaal voor het verzenden van informatie is telefoon kanaal. Typisch apparaat voor het opslaan van informatie is een bandrecorder, inclusief opname- en leeskoppen.

Rijst. 1.1. Blokdiagram gemeenschappelijk systeem overdracht of opslag van informatie.

Een typische informatiebron is een bericht dat bestaat uit binaire of decimale cijfers, of tekst geschreven in een of ander alfabet. Een encoder zet deze berichten om in signalen die kunnen worden verzonden

per kanaal. Typische signalen zijn elektrisch, met enkele beperkingen in vermogen, bandbreedte en duur. Deze signalen komen het kanaal binnen en worden vervormd door ruis. Het vervormde signaal komt vervolgens een decodeerapparaat binnen, dat het verzonden bericht reconstrueert en doorstuurt naar de ontvanger. De taak van de communicatie-ingenieur is in de eerste plaats het bouwen van de encoder en de decoder, maar kan ook de taak omvatten om het kanaal zelf te verbeteren. Merk op dat de encoder een apparaat bevat dat een bewerking uitvoert die gewoonlijk modulatie wordt genoemd, en dat de decoder een apparaat bevat dat detectie uitvoert.

Het systeem getoond in afb. 1.1 is te algemeen om gemakkelijk in theoretische analyses te kunnen worden gebruikt. De algemene coderingstheorie geeft aan dat een communicatiekanaal een bepaalde capaciteit heeft, dat typische bronnen een bepaalde snelheid hebben bij het creëren van informatie, en dat in het geval dat de snelheid van het creëren van informatie door een bron minder is bandbreedte kanaal, codering en decodering kunnen zo worden uitgevoerd dat de kans op foutieve decodering willekeurig klein is.

Rijst. 1.2, Blokdiagram typisch systeem overdracht of opslag van informatie.

Hoewel er dus hoop is voor de toekomst, biedt de theorie voorlopig niet meer dan vage aanwijzingen over hoe een informatieoverdrachtsysteem moet worden ontworpen.

Typisch modern systeem informatieoverdracht wordt getoond in Fig. 1.2. Bijna alles computers binnenkomende informatie omzetten in binair formaat en deze vervolgens in binaire vorm verwerken. Veel systemen gebruiken code waarin verschillende

combinaties van zes binaire tekens vertegenwoordigen cijfers, letters, spaties en speciale tekens zoals leestekens. Een andere veel voorkomende code gebruikt vier binaire cijfers voor elk decimaal cijfer en twee decimale cijfers voor elk alfabetisch of speciaal teken.

Een apparaat voor het coderen van binaire symbolen in signalen aan de ingang van een kanaal wordt soms een modulator genoemd. In de meeste gevallen associeert het een één met een impuls, en een nul met de afwezigheid van een impuls of een impuls die duidelijk te onderscheiden is van de code voor één. Deze afzonderlijke conversie van elk binair teken is een beperking die zeker een vermindering van de kanaaldoorvoer veroorzaakt. De decoder bepaalt of de volgende ontvangen puls een nul of een één is. Het onafhankelijk decoderen van individuele pulsen resulteert in een verdere reductie van de doorvoer. Theorie laat dat meer zien complexe methoden codering en decodering verhogen de transmissiesnelheid met dezelfde foutkans. Het is echter nog niet bekend effectieve manieren implementatie van deze methoden.

Apparaten gebruiken binair om binaire tekens te coderen en decoderen. binaire codes, het opsporen en corrigeren van fouten.

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 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 de bytes die niet in de huidige codering passen simpelweg weg te gooien, of ze te vervangen door vraagtekens. Of op speciaal karakter Unicode-vervangingen: � (U+ FFFD). Als u na de procedure voor het verwijderen van ongepaste tekens het document opslaat, 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 gebroken 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 uiteraard 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 het. 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 zoals 11100111 10111000 10100111 van een applicatie ontvangt, slaat hij deze graag 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 uiteraard 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 eenvoudigweg deze reeks uitvoert, wordt de tekst in UTF-8 uitgevoerd. 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 het. "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 tekst via utf8_encode moet worden uitgevoerd, of andere onzin.

Gelukkig is dat zo speciale uitbreiding, dat alle belangrijke stringfunctionaliteit toevoegt, 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 wat plezier beleven.

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 met tekenreeksen doet 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 een 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 DIARESIS”) 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

Als de codering onjuist is, wordt de hele site of een deel ervan weergegeven als “kryapozyablov”, d.w.z. vreemde karakters, waardoor de tekst onleesbaar wordt. Deze situatie kan zich voordoen wanneer onjuiste instelling webservercodering of als er geen instellingen zijn. Laten we eens overwegen mogelijke opties en manieren om problemen op te lossen

Onjuiste HTML-paginacodering

Laten we een testbestand maken:

Sudo gedit /var/www/html/encoding.html

Laten we ernaar kopiëren:

Laten we dit bestand in de browser openen

Zoals u kunt zien, wordt de codering onjuist gedetecteerd door de browser:

Er zijn verschillende manieren om deze situatie te corrigeren. Laten we beginnen met het eenvoudigste: specificeer expliciet de codering voor de webpagina. Dit wordt gedaan door een metatag, die zich binnen de tag moet bevinden hoofd:

Laten we deze regel aan ons testbestand toevoegen, zodat het er als volgt uitziet:

Testbestand om de codering te controleren

Zoals we in de volgende schermafbeelding kunnen zien, is het probleem opgelost:

Als de codering van uw bestand anders is dan UTF-8 en vervang het dan door Windows-1251 of een die overeenkomt met de codering van de webpagina. Kijk eens naar hoe je bestandscodering kunt detecteren.

Dit was de gemakkelijkste manier om het coderingsprobleem op te lossen - zonder de serverinstellingen te wijzigen.

Laten we ons testbestand terugsturen naar initiële staat en ga door met het bestuderen van manieren om de codering te specificeren.

Als bestanden .htaccess inbegrepen Apache-instellingen, dan kunnen deze bestanden worden gebruikt om de codering te specificeren van pagina's die door de webserver worden verzonden. Bestandsondersteuning inschakelen .htaccess V configuratiebestand Apache ( /etc/apache2/apache2.conf) zoek een groep lijnen

Opties Indexen FollowSymLinks AllowOverride Geen Vereist alles toegekend

En vervang deze

AllowOverride Geen

Alles overschrijven toestaan

Hierna moet de server opnieuw worden opgestart.

Sudo systemctl herstart apache2.service

Bestand .htaccess moet in dezelfde map als de site worden geplaatst. Mijn site wordt gehost in de hoofdmap van de webserver. Als je hetzelfde hebt, dan nu in de map /var/www/html/ maak een bestand aan .htaccess en voeg de richtlijn eraan toe Standaardtekenset toevoegen geef daarna de gewenste codering aan. Voorbeelden

AddDefaultCharset UTF-8

AddDefaultCharset Windows-1251

U kunt een codering opgeven die alleen wordt toegepast op bestanden met een bepaald formaat:

AddCharset utf-8 .atom .css .js .json .rss .vtt .xml

De set bestanden kan van alles zijn, bijvoorbeeld:

AddCharset utf-8 .html .css .php .txt .js

De volgende optie is een alternatief en biedt u ook de mogelijkheid de codering voor bestanden in te stellen bepaald soort, moet deze worden ingeschakeld mod_headers:

Headerset Inhoudstype "text/html; charset=utf-8"

Een andere optie die ook in het bestand kan worden gebruikt .htaccess om de UTF-8-codering in te stellen:

IndexOptions + Tekenset=UTF-8

Als de site in PHP is, moet u mogelijk ook de codering dupliceren met php_value standaard_charset:

AddDefaultCharset windows-1251 php_value standaard_charset "cp1251"

In plaats van een .htaccess-bestand te maken, kunt u de codering instellen in het configuratiebestand van de webserver. Voor Apache CentOS/Fedora is dit het bestand httpd.conf, en voor Debian/Ubuntu is dit het bestand apache2.conf. Toevoegen volgende regel om de codering in te stellen en de webserver opnieuw op te starten zodat de wijzigingen van kracht worden:

AddDefaultCharset UTF-8

Hoe UTF-8-codering in PHP in te stellen

IN PHP-script Het wordt gebruikt om de codering in te stellen koptekst, Bijvoorbeeld:

Header("Inhoudstype: charset=utf-8");

Meestal wordt naast de codering ook het contenttype aangegeven (in het voorbeeld de optie voor een HTML-pagina):

Header("Inhoudstype: tekst/html; charset=utf-8");

Een andere optie voor RSS-feed:

Header("Inhoudstype: tekst/xml; charset=utf-8");

Vergeet niet dat de functie koptekst moet worden aangeroepen vóór enige uitvoer naar de browser. Anders (als er al uitvoer naar de browser is gemaakt), zijn de headers al verzonden. Uiteraard is het in dit geval niet meer mogelijk om ze te wijzigen. Als er een foutmelding naar de browser is verzonden, zijn de headers al verzonden en zal het gebruik van de header een fout veroorzaken. Om te controleren of er al headers zijn verzonden, gebruikt u headers_verzonden.

De beschreven methode werkt alleen wanneer het PHP-script de inhoud van de pagina volledig genereert. Statische pagina's (zoals html) dient u op te slaan in utf-8-codering. De meeste webservers zullen kennis nemen van de codering van het bestand en dienovereenkomstig een header toevoegen. Eigenlijk sparen PHP-bestand in utf-8-codering zal tot hetzelfde resultaat leiden.

Onjuiste codering van resultaten uit de MySQL-database

Als uw site bestaat uit een statisch deel (sjabloon) en een dynamisch deel, dat wordt gevormd op basis van gegevens ontvangen uit de database, dan kan er een situatie ontstaan ​​waarin een deel van de site de juiste codering heeft en een ander deel van de site de verkeerde codering. een. In dit geval heeft het geen zin om de instellingen van de webserver te wijzigen, aangezien een deel van de pagina toch de verkeerde codering zal hebben.

U moet beginnen met het bepalen van de codering van uw tabellen. Je kunt ernaar kijken phpMijnAdmin:

Let op de kolom " Vergelijking", binnenkomst " utf8_unicode_ci" betekent dat de codering wordt gebruikt UTF-8.

U kunt verbinding maken met MySQL-DBMS en controleer de codering van tabellen zonder phpMyAdmin. Om dit te doen:

Mysql -u root-p

Als u de databasenaam bent vergeten, voert u de opdracht uit:

TOON DATABASES;

Stel dat ik de codering voor tabellen in de database information_schema wil opzoeken

GEBRUIK informatie_schema;

Als u de namen van de tabellen bent vergeten, voert u het volgende uit:

TOON VOLLEDIGE KOLOMMEN UIT tabelnaam;

Bijvoorbeeld:

VOLLEDIGE KOLOMMEN VAN GLOBAL_STATUS TONEN;

Je zult zoiets als dit zien:

Zie kolom Sortering. In mijn geval daar utf8_general_ci, het is alsof utf8_unicode_ci, codering UTF-8. Trouwens, als je niet weet wat het verschil tussen coderingen is utf8_general_ci, utf8_unicode_ci, utf8mb4_general_ci, utf8mb4_unicode_ci, en ook welke codering u moet kiezen voor de MySQL-database, kijk dan.

Nu we de codering kennen (in mijn geval is het UTF-8), moet u elke keer dat u verbinding maakt met het MySQL DBMS de query's opeenvolgend uitvoeren:

NAMEN INSTELLEN UTF8 KARAKTER INSTELLEN SET UTF8 SET karakter_set_client = UTF8 SET karakter_set_connection = UTF8 SET karakter_set_results = UTF8

In PHP kan dit ongeveer als volgt gedaan worden:

$this->mysqli = nieuwe mysqli($server, $gebruikersnaam, $wachtwoord, $basisnaam); if ($this->mysqli->connect_error) ( $this->errorHandler_c->logError(1, "Verbindingsfout (" . $this->mysqli->connect_errno . ") " . $this->mysqli->connect_error , $_SERVER ["REQUEST_URI"] ) $this->mysqli->query("SET NAMES UTF8"); $this->mysqli->query("SET CHARACTER SET UTF8"); $this->mysqli->query("SET karakter_set_client = UTF8"); $this->mysqli->query("SET karakter_set_connection = UTF8"); $this->mysqli->query("SET karakter_set_results = UTF8");

merk dat op UTF8 u moet deze vervangen door de codering die voor uw tabellen wordt gebruikt.

Bestandscodering wijzigen

Als u besluit de andere kant op te gaan en in plaats van een nieuwe codering te installeren, de codering van uw bestanden wijzigt, kijk dan naar het artikel “”. Het vertelt u hoe u de huidige codering van bestanden kunt achterhalen en hoe u bestanden naar welke codering dan ook kunt converteren (niet alleen UTF-8).

Hoe u kunt achterhalen welke codering de server verzendt

Als je wilt weten welke coderingsinstellingen de webserver heeft (welke codering deze in headers verzendt), gebruik dan de volgende opdracht:

Curl-URL -s -o /dev/null -D /dev/stdout | grep -E "tekenset"

In plaats daarvan URL invoegen echt adres website wordt gecontroleerd. Als de site HTTPS gebruikt, geef dan bijvoorbeeld het siteadres samen met het protocol op

Krul https://softocracy.ru -s -o /dev/null -D /dev/stdout | grep -E "tekenset"

Welke codering u moet kiezen voor een website

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 hiervan afhankelijk besturingssysteem, evenals 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. En het programma dat afgedrukte informatie op het scherm weergeeft (dit kan een browser of een tekstverwerker zijn) ontleedt de code, vindt een geschikte weergave aan de hand van de code in de coderingstabel, converteert deze naar de vereiste vectorvorm en geeft deze weer in een tekst bestand.

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 die verband houden 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 enorm bedrag 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.

Een andere nuttige tip voor het bestrijden van krakozyabrs is om in de kop van de code van elke pagina van de site informatie te schrijven over de juiste tekstcodering, zodat er geen lokalehost, was er ook geen verwarring op de server.

Bijvoorbeeld zoals dit