verschillende php-coderingen

  1. auteurs
  2. x64 (aka andi)

beginnende scriptschrijvers geven niets om zoiets als coderen

beginnende scriptschrijvers geven niets om zoiets als coderen. Daarom kun je op sites soms een vreselijke puinhoop vinden, wanneer de gegevens uit de database in één codering worden verkregen, wordt de pagina in een andere gevormd en krijgt de server de derde. als gevolg hiervan, als de pagina kan worden gedecodeerd, dan minstens 2 keer. Dus, waarom gebeurt er zo'n probleem en hoe het te overwinnen?

in het Russische segment vindt u meestal de zogenaamde Windows-codering. noem het anders: windows-1251, cp1251 of zelfs ansi. de volgende is utf-8. Je kunt ook de naam unicode vinden, maar dit is niet helemaal correct, omdat Unicode de algemene naam voor de hele groep is (utf-8, utf-16, utf-32). en een zeer populaire zeldzaamheid is koi8-r of simpelweg koi-8 - de ooit populaire Linux-codering. Natuurlijk is het mogelijk om iets anders in het Russische segment te ontmoeten, maar dit is eerder een "aflaat" van de auteur.

Het grootste verschil tussen utf-8 en anderen (voornamelijk windows-1251 en koi8-r) is de laatste één-byte, en het maximale aantal tekens dat kan worden weergegeven met behulp van deze coderingen is beperkt tot 256. Het spreekt vanzelf dat voor een volledige presentatie van de tekst van deze misschien niet genoeg. en voor html werd een oplossing gevonden - het gebruik van zogenaamde mnemonics. bijvoorbeeld:

© - & copy;

Naast het feit dat elk van deze tekens wordt beschreven door een groep tekens, wordt de code onleesbaar en wordt het werken met de tekst gecompliceerder. dit is waar de multibyte utf-8 te hulp schiet. het is erg handig om letters van verschillende alfabetten en verschillende symbolen in één tekst te gebruiken.

De meest comfortabele set beginvoorwaarden is dus als volgt: de codering van de database, php-scripts en html-pagina's / js-scripts moeten hetzelfde zijn. Natuurlijk kunt u verschillende gebruiken, maar in dit geval bestaat het risico verward te raken. het maakt niet uit welke codepagina wordt gebruikt. als de site alleen voor een Russisch sprekend publiek is, zal windows-1251 voldoende zijn. anders zou utf-8 de logische keuze zijn. de eerste optie is min of meer duidelijk. multibyte-codering vereist enkele gebaren.

Wanneer u met utf-8 werkt, zal een standaardblocnote-kladblok niet werken ! Het feit is dat deze editor, bij het opslaan van een bestand in deze codering, een handtekening toevoegt aan het begin - 3 tekens, de zogenaamde bom (byte-opdrachtmarkering), die kan worden gebruikt om de codering te bepalen bij het openen van een bestand. het is beter om een ​​andere editor te kiezen: Notepad2 of notepad ++ . in de instellingen die u moet kiezen om op te slaan zonder een handtekening.

De volgende belangrijke stap is het werken met de database. Het is zeer wenselijk dat de codering van het basis / tabel / tekstveld overeenkomt met de scriptcodering (het zou cp1251 of utf-8 kunnen zijn, of iets anders). als de gegevens uit de database worden verkregen in de vorm van "zyuk", verschilt de codering van de verbinding hoogstwaarschijnlijk van de gegevens die in de database zijn opgeslagen. De volgende query zal helpen om de situatie te verhelpen (direct uitvoeren na het verbinden met de database):

als de site windows-1251 gebruikt, moet u dit specificeren - cp1251.

over het algemeen is er niets moeilijks. alleen de standaard php-functies zijn niet ontworpen om te werken met multibyte-reeksen. maar er zijn standaardbibliotheken die de situatie helpen corrigeren: iconv en mbstring . voor reguliere expressies is er ook een noodzakelijke schakelaar die wordt geactiveerd met de modifier u .

Welnu, de gegevens uit de database zijn verkregen, de scripts zijn volgens alle regels geschreven. Het blijft om de juiste titel te verzenden en de paginacode weer te geven in de browser van de gebruiker. we sturen rubriek zo:

header ('Content-type: text / html; charset = utf-8');

als single-byte codering wordt gebruikt, zal de waarde voor de karakterset anders zijn - windows-1251 . Daarna zouden problemen niet moeten blijven.

Enkele eenvoudigste voorbeelden van werken met utf-8 in php:

voorbeeld 1: iconv, aantal tekens per regel

$ s = 'string'; # string in utf-8 $ cnt1 = strlen ($ s); # bevat de waarde $ 12 cnt2 = iconv_strlen ($ s, 'UTF-8'); # juiste waarde, 6

voorbeeld 2: mbstring, het aantal karakters in een string

$ s = 'string'; # string in utf-8 $ cnt1 = strlen ($ s); # bevat de waarde $ 12 cnt2 = mb_strlen ($ s, 'UTF-8'); # juiste waarde, 6

voorbeeld 3: reguliere expressies, zoeken en vervangen

$ s = 'String'; # regel in utf-8 $ s = preg_replace ('/ p / i', 'd', $ s); # vervanging zal niet gebeuren $ s = preg_replace ('/ p / iu', 'd', $ s); # result word dock

de i- modifier schrijft een niet-hoofdlettergevoelig zoeken voor, en de u- modifier vertelt de reguliere expressie-engine om te werken met utf-8-reeksen.

als iemand zegt dat php niet met utf-8 kan werken, is het verkeerd. Sinds enkele jaren heb ik al mijn projecten in deze codering gedaan en er waren helemaal geen problemen. Zoekmachines zelf hebben deze prachtige codering al lang gebruikt.

auteurs

offline 11 uur

x64 (aka andi)

Toelichting: 2846 Publicaties: 395 Registratie: 02-04-2009

Dus, waarom gebeurt er zo'n probleem en hoe het te overwinnen?