Le problème de l'encodage chinois dans la programmation PHP a troublé de nombreuses personnes. La raison de ce problème est en fait très simple. Chaque pays (ou région) stipule l'encodage de caractères défini pour l'échange d'informations informatiques, comme le code ASCII étendu aux États-Unis et en Chine. GB2312 en Chine -80, JIS du Japon, etc. En tant que base du traitement de l'information dans ce pays/région, les jeux de codage de caractères jouent un rôle important dans l'unification du codage. Les jeux de codage de caractères sont divisés en deux catégories selon leur longueur : SBCS (jeu de caractères à un octet) et DBCS (jeu de caractères à deux octets). Dans les premiers logiciels (en particulier les systèmes d'exploitation), afin de résoudre le traitement informatique des informations de caractères locales, diverses versions localisées (L10N) sont apparues afin de se différencier, des concepts tels que LANG et Codepage ont été introduits. Cependant, en raison du chevauchement des plages de codes des différents jeux de caractères locaux, il est difficile d'échanger des informations entre eux ; le coût de la maintenance indépendante de chaque version localisée du logiciel est élevé. Par conséquent, il est nécessaire d’extraire les points communs du travail de localisation et de les traiter de manière cohérente afin de minimiser le contenu spécial du traitement de localisation. C'est ce qu'on appelle également l'internationalisation (118N). Diverses informations linguistiques sont en outre standardisées en tant qu'informations locales. Le jeu de caractères sous-jacent traité est devenu Unicode, qui contient presque tous les glyphes.
À l'heure actuelle, la plupart du traitement des caractères de base des logiciels aux caractéristiques internationales est basé sur Unicode. Lorsque le logiciel est en cours d'exécution, les paramètres de codage de caractères locaux correspondants sont déterminés en fonction des paramètres régionaux/Lang/Page de code du moment, et les caractères locaux sont déterminés. traitées en conséquence. Pendant le traitement, il est nécessaire de réaliser la conversion mutuelle entre Unicode et les jeux de caractères locaux, voire la conversion mutuelle entre deux jeux de caractères locaux différents avec Unicode comme milieu. Cette méthode est encore étendue dans l'environnement réseau, et toute information de caractère aux deux extrémités du réseau doit également être convertie en contenu acceptable en fonction des paramètres du jeu de caractères.
Problèmes de codage des jeux de caractères dans les bases de données
Les systèmes de bases de données relationnelles populaires prennent tous en charge le codage des jeux de caractères de base de données, ce qui signifie que vous pouvez spécifier ses propres paramètres de jeu de caractères lors de la création d'une base de données et que les données de la base de données sont stockées dans le codage spécifié. Lorsqu'une application accède aux données, il y aura une conversion de codage de jeu de caractères aux points d'entrée et de sortie. Pour les données chinoises, le paramètre de codage des caractères de la base de données doit garantir l'intégrité des données. GB2312, GBK, UTF-8, etc. sont tous des codages de jeux de caractères de base de données facultatifs ; bien sûr, nous pouvons également choisir ISO8859-1 (8 bits), mais nous devons convertir un caractère chinois ou Unicode de 16 bits avant
l'application.
écrit les données.Divisé en deux caractères de 8 bits. Après avoir lu les données, vous devez fusionner les deux octets et identifier les caractères SBCS. Par conséquent, nous ne recommandons pas d'utiliser ISO8859-1 comme codage du jeu de caractères de la base de données. Non seulement cela ne permet pas d'exploiter pleinement la prise en charge du codage des jeux de caractères de la base de données elle-même, mais cela augmente également la complexité de la programmation. Lors de la programmation, vous pouvez d'abord utiliser les fonctions de gestion fournies par le système de gestion de base de données pour vérifier si les données chinoises sont correctes.
Avant d'interroger la base de données, le programme PHP exécute d'abord mysql_query("SET NAMES xxxx"); où xxxx est l'encodage de votre page Web (charset=xxxx dans la page Web, alors xxxx=utf8, si charset). =gb2312 dans la page web, Puis xxxx=gb2312, presque tous les programmes WEB ont un code commun pour se connecter à la base de données, qui est placé dans un fichier, il suffit d'ajouter mysql_query("SET NAMES xxxx").
SET NAMES indique quel jeu de caractères est utilisé dans l'instruction SQL envoyée par le client. Par conséquent, l'instruction SET NAMES 'utf-8' indique au serveur que « les futures informations de ce client utiliseront le jeu de caractères utf-8 ». Il spécifie également le jeu de caractères pour les résultats que le serveur renvoie au client (par exemple, si vous utilisez une instruction SELECT, il indique quel jeu de caractères est utilisé pour les valeurs de colonne).
Techniques couramment utilisées pour localiser les problèmes.
La localisation des problèmes d'encodage chinois utilise généralement la méthode la plus stupide et la plus efficace : imprimer le code interne de la chaîne après traitement par le programme que vous pensez suspect. En imprimant le code interne d'une chaîne, vous pouvez savoir quand les caractères chinois sont convertis en Unicode, quand Unicode est reconverti en code interne chinois, quand un caractère chinois devient deux caractères Unicode, quand une chaîne chinoise est convertie en une chaîne de points d'interrogation, quand les bits de poids fort de la chaîne de caractères chinois ont-ils été tronqués...
Prendre un échantillon de chaîne approprié peut également aider à distinguer le type de question. Par exemple : " aaahaa?@aa " et d'autres chaînes qui alternent entre le chinois et l'anglais et comportent à la fois des caractères caractéristiques GB et GBK. D'une manière générale, les caractères anglais ne seront pas déformés quelle que soit la manière dont ils sont convertis ou traités (si vous les rencontrez, vous pouvez essayer d'augmenter la longueur des lettres anglaises consécutives).
Résoudre les problèmes de code tronqué dans diverses applications
1) Utiliser des balises pour définir l'encodage de la page
La fonction de cette balise est de déclarer quel jeu de caractères l'encodage utilisé par le navigateur du client pour afficher la page xxx peut être GB2312, GBK, UTF-8 (différent de. MySQL, qui est UTF8), etc. Par conséquent, la plupart des pages peuvent utiliser cette méthode pour indiquer au navigateur quel encodage utiliser lors de l'affichage de cette page, afin d'éviter les erreurs d'encodage et les caractères tronqués. Mais parfois, nous constaterons que cette phrase ne fonctionne toujours pas. Quel que soit le nom de xxx, le navigateur utilise toujours le même codage. Je reviendrai sur cette situation plus tard.
Veuillez noter qu'il appartient aux informations HTML et qu'il ne s'agit que d'une déclaration qui indique uniquement que le serveur a transmis les informations HTML au navigateur.
2) header("content-type:text/html; charset=xxx");
La fonction de cette fonction header() est d'envoyer les informations entre parenthèses à l'en-tête http. Si le contenu entre parenthèses est celui mentionné dans l'article, alors la fonction est fondamentalement la même que l'étiquette. Si vous la comparez avec la première, vous constaterez que les caractères sont similaires. Mais la différence est que s’il existe cette fonction, le navigateur utilisera toujours l’encodage xxx que vous avez demandé et ne désobéira jamais, cette fonction est donc très utile. Pourquoi cela se produit-il ? Ensuite, nous devons parler de la différence entre l'en-tête http et les informations HTML :
l'en-tête http est une chaîne envoyée par le serveur avant d'envoyer les informations HTML au navigateur à l'aide du protocole http. La balise appartient aux informations HTML, donc le contenu envoyé par header() atteint le navigateur en premier. Le point populaire est que header() a une priorité plus élevée (je ne sais pas si je peux le dire). Si une page php a à la fois header("content-type:text/html;charset=xxx") et header("content-type:text/html;charset=xxx"), le navigateur ne reconnaîtra que l'ancien en-tête http et pas la méta. Bien entendu, cette fonction ne peut être utilisée que dans les pages php.
Il reste également une question : pourquoi le premier fonctionne-t-il définitivement, mais le second ne fonctionne parfois pas ? C'est la raison pour laquelle nous parlerons ensuite d'Apache ?
3) AddDefaultCharset
Dans le dossier conf du répertoire racine d'Apache, se trouve l'intégralité du document de configuration d'Apache httpd.conf.
Ouvrez httpd.conf avec un éditeur de texte. La ligne 708 (peut être différente selon les versions) contient AddDefaultCharset xxx, où xxx est le nom de codage. La signification de cette ligne de code : définissez le jeu de caractères dans l'en-tête http du fichier de page Web sur l'ensemble du serveur sur votre jeu de caractères xxx par défaut. Avoir cette ligne équivaut à ajouter un en-tête ("content-type: text/html; charset=xxx") à chaque fichier. Vous pouvez maintenant comprendre pourquoi le navigateur utilise toujours gb2312 même s'il est défini sur utf-8.
S'il y a un en-tête("content-type:text/html; charset=xxx") dans la page Web, le jeu de caractères par défaut sera remplacé par le jeu de caractères que vous avez défini, cette fonction sera donc toujours utile. Si vous ajoutez un "#" devant AddDefaultCharset xxx, commentez cette phrase et que la page ne contient pas d'en-tête ("content-type..."), alors c'est au tour de la balise méta de prendre effet.
L'ordre de priorité des éléments ci-dessus est répertorié ci-dessous :
.. header("content-type:text/html; charset=xxx")
.. AddDefaultCharset xxx
..
Si vous êtes un programmeur Web, il est recommandé d'ajouter un en-tête à chaque de vos pages. ("content-type:text/html;charset=xxx"), cela garantit qu'il peut être affiché correctement sur n'importe quel serveur et a une forte portabilité.
4) Configuration Default_charset dans php.ini :
default_charset = "gb2312" dans php.ini définit le jeu de caractères de langue par défaut de php. Il est généralement recommandé de commenter cette ligne et de laisser le navigateur sélectionner automatiquement la langue en fonction du jeu de caractères dans l'en-tête de la page Web au lieu de créer une exigence obligatoire, afin que les services Web dans plusieurs langues puissent être fournis sur le même serveur.
Conclusion
En fait, le codage chinois dans le développement PHP n'est pas aussi compliqué qu'on l'imagine. Bien qu'il n'y ait pas de règles fixes pour positionner et résoudre les problèmes, et que les différents environnements d'exploitation soient également différents, les principes sous-jacents sont les mêmes. Comprendre la connaissance des jeux de caractères est la base pour résoudre les problèmes de personnages. Cependant, avec les changements apportés au jeu de caractères chinois, non seulement la programmation PHP, mais aussi les problèmes de traitement de l'information chinoise persisteront pendant un certain temps.