Статьи

différents encodages php

  1. Éditeur
  2. x64 (aka andi)

Les scénaristes novices ne s’intéressent pas à l’encodage

Les scénaristes novices ne s’intéressent pas à l’encodage. Par conséquent, sur des sites, vous pouvez parfois trouver un désordre épouvantable, lorsque les données de la base de données sont obtenues dans un codage, la page est formée dans un autre et le serveur reçoit le troisième. Par conséquent, si la page peut être déchiffrée, au moins 2 fois. Alors, pourquoi un tel problème se pose-t-il et comment le surmonter?

Dans le segment russe, le plus souvent, vous pouvez trouver ce qu'on appelle l'encodage Windows. Appelez autrement: windows-1251, cp1251 ou même ansi. le prochain est utf-8. Vous pouvez également trouver le nom Unicode, mais ce n'est pas tout à fait correct, car Unicode est le nom général du groupe entier (utf-8, utf-16, utf-32). et une rareté très populaire est koi8-r ou simplement koi-8 - le codage Linux jadis populaire. Bien sûr, il est possible de rencontrer autre chose dans le segment russe, mais il s'agit plutôt d'une «indulgence» de l'auteur.

La principale différence entre utf-8 et les autres (principalement windows-1251 et koi8-r) réside dans le dernier octet, et le nombre maximal de caractères pouvant être représentés à l'aide de ces codages est limité à 256. Il va sans dire que pour un texte intégral peut ne pas suffire. et pour html, une solution a été trouvée - l’utilisation de soi-disant mnémoniques. par exemple:

© - & copy;

Outre le fait que chacun de ces caractères est décrit par un groupe de caractères, le code devient illisible et le travail avec le texte devient plus compliqué. C’est là que le multi-octets utf-8 vient à la rescousse. il est très pratique d’utiliser des lettres de différents alphabets et différents symboles dans un même texte.

Ainsi, l'ensemble de conditions initiales le plus confortable est le suivant: le codage de la base de données, des scripts php et des scripts html pages / js doit être identique. Bien sûr, vous pouvez en utiliser différentes, mais dans ce cas, vous risquez de vous perdre. Peu importe la page de code utilisée. si le site est réservé à un public russophone, windows-1251 suffira amplement. sinon, utf-8 serait le choix logique. la première option est plus ou moins claire. l'encodage sur plusieurs octets nécessitera quelques gestes.

Lorsque vous travaillez avec utf-8, un bloc-notes standard ne fonctionnera pas ! Le fait est que cet éditeur, lors de l'enregistrement d'un fichier dans cet encodage, ajoute une signature au début - 3 caractères, appelés bom (marque d'ordre d'octet), qui peuvent être utilisés pour déterminer l'encodage lors de l'ouverture d'un fichier. il vaut mieux choisir un autre éditeur: bloc-notes2 ou bloc-notes ++ . dans les paramètres, vous devez choisir de sauvegarder sans signature.

La prochaine étape importante consiste à travailler avec la base de données. Il est hautement souhaitable que l'encodage du champ base / table / text corresponde à l'encodage du script (cp1251 ou utf-8, ou autre chose). si les données de la base de données sont obtenues sous la forme de "zyuk", le codage de la connexion est fort probablement différent des données stockées dans la base de données. La requête suivante aidera à surmonter la situation (exécuter immédiatement après la connexion à la base de données):

si le site utilise Windows-1251, vous devez le spécifier - cp1251.

en général, il n'y a rien de difficile. seulement, les fonctions php standard ne sont pas conçues pour fonctionner avec des chaînes multi-octets. mais il existe des bibliothèques standard qui aideront à corriger la situation: iconv et mbstring . pour les expressions régulières, il existe également un commutateur nécessaire qui est activé avec le modificateur u .

Eh bien, les données de la base de données sont obtenues, les scripts sont écrits selon toutes les règles. Il reste à envoyer le titre correct et à afficher le code de la page dans le navigateur de l'utilisateur. nous envoyons l'en-tête alors:

en-tête ('Type de contenu: text / html; charset = utf-8');

si un codage sur un octet est utilisé, la valeur du jeu de caractères sera différente - windows-1251 . Après cela, les problèmes ne devraient pas rester.

Quelques exemples les plus simples d'utilisation de utf-8 en php:

exemple 1: iconv, nombre de caractères par ligne

$ s = 'chaîne'; # chaîne dans utf-8 $ cnt1 = strlen ($ s); # contiendra la valeur $ 12 cnt2 = iconv_strlen ($ s, 'UTF-8'); # valeur correcte, 6

exemple 2: mbstring, le nombre de caractères dans une chaîne

$ s = 'chaîne'; # chaîne dans utf-8 $ cnt1 = strlen ($ s); # contiendra la valeur $ 12 cnt2 = mb_strlen ($ s, 'UTF-8'); # valeur correcte, 6

exemple 3: expressions régulières, rechercher et remplacer

$ s = 'Chaîne'; # ligne dans utf-8 $ s = preg_replace ('/ p / i', 'd', $ s); # le remplacement n'aura pas lieu $ s = preg_replace ('/ p / iu', 'd', $ s); # résultat mot dock

le modificateur i prescrit une recherche insensible à la casse et le modificateur u indique au moteur des expressions régulières de travailler avec les chaînes utf-8.

si quelqu'un dit que php ne peut pas fonctionner avec utf-8, ce sera une erreur. Depuis plusieurs années, je réalise tous mes projets dans cet encodage et je n’ai rencontré aucun problème. Les moteurs de recherche eux-mêmes utilisent depuis longtemps ce merveilleux encodage.

Éditeur

hors ligne 11 heures

x64 (aka andi)

Commentaires: 2846 Publications: 395 Inscription: 02-04-2009

Alors, pourquoi un tel problème se pose-t-il et comment le surmonter?
2011.11.19
Карта