Problèmes de LISTA UTF-8 à surveiller dans Wordpress
J’ai rencontré un problème très tôt, c’est-à-dire qu’après avoir installé un certain plugin, un écran blanc apparaissait après avoir cliqué pour activer. Je n’ai jamais compris la raison, et la solution précédente était que si elle ne contient pas de caractères chinois, il faut transférer directement le fichier en code ASCII, ce qui peut généralement être résolu. Quand j’ai reçu un blog pour mon frère aujourd’hui, cette situation s’est reproduite. Après avoir fait de longues recherches, j’ai finalement trouvé la réponse.
Il existe un concept de BOM dans la spécification Unicode. BOM - Byte Order Mark, qui est la marque d’ordre des octets. Trouvez une note sur la BOM ici :
Dans le code UCS, il existe un caractère appelé « ZERO WIDTH NO-BREAK SPACE », qui est codé sous le nom FEFF. FFFE est un personnage inexistant dans UCS, donc il ne devrait pas apparaître dans la transmission réelle. La spécification UCS recommande de transférer le caractère « ZERO WIDTH NO-BREAK SPACE » avant de transmettre le flux d’octets. Ainsi, si le récepteur reçoit un FEFF, cela indique que le flux d’octets est Big-Endian ; Si FFFE est reçu, cela indique que le flux d’octets est Little-Endian. Par conséquent, le caractère « ZERO WIDTH NO-BREAK SPACE » est également appelé BOM.
UTF-8 ne nécessite pas qu’une MAL indique l’ordre des octets, mais il peut utiliser une MAM pour indiquer comment il est encodé. L’encodage UTF-8 du caractère « ZERO WIDTH NO-BREAK SPACE » est EF BB BF. Donc, si le récepteur reçoit un flux d’octets qui commence par EF BB BF, il sait qu’il s’agit d’un codage UTF-8.
Windows utilise la liste des matériaux pour indiquer comment les fichiers texte sont encodés.
De plus, la FAQ sur le site Unicode explique en détail la liste de bases. L’autorité naturelle officielle, mais en anglais, semble plus laborieuse.
Dans un fichier codé en UTF-8, la BOM occupe trois octets. Si vous utilisez Notepad pour enregistrer un fichier texte en encodage UTF-8, ouvrez le fichier avec UE et passez à l’état d’édition hexadécimal pour voir le FFFE au début. C’est un bon moyen d’identifier les fichiers encodés en UTF-8, les logiciels utilisent la liste de matériaux pour déterminer si le fichier est encodé en UTF-8, et de nombreux logiciels exigent également que le fichier importé ait une liste de charge. Cependant, il existe encore beaucoup de logiciels qui ne reconnaissent pas la liste de base. Quand je faisais des recherches sur Firefox, je savais que dans les premières versions de Firefox, les extensions ne pouvaient pas avoir de liste de base, mais Firefox 1.5 et les versions ultérieures ont commencé à prendre en charge la liste de base. J’ai maintenant découvert que PHP ne prend pas non plus en charge la liste de base.
PHP a été conçu sans prendre en compte la liste de base, ce qui signifie qu’il n’ignore pas les trois caractères de la liste de commerce au début du fichier encodé en UTF-8. Puisqu’il doit être dans
Comme je l’ai vu dans le wiki Bo-Blog, Bo-Blog, qui utilise aussi PHP, est également en difficulté avec BOM. Un autre problème est mentionné : « En raison de la limitation du mécanisme d’envoi des COOKIES, dans les fichiers qui ont déjà une lettre de commerce au début de ces fichiers, les COOKIES ne peuvent pas être envoyés (car PHP a déjà envoyé l’en-tête du fichier avant l’envoi du COOKIE), donc les fonctions de connexion et de déconnexion sont invalides. Toutes les fonctions qui dépendent des COOKIES et SESSIONS sont invalides. Cela devrait expliquer la page vierge en arrière-plan WordPress, car n’importe lequel des fichiers exécutés contient une carte mère, et les trois caractères seront envoyés, ce qui entraînera l’échec de la fonctionnalité qui dépend des cookies et des sessions.
La solution consiste à enregistrer le fichier en code ASCII s’il ne contient que des caractères anglais (ou des caractères dans l’encodage ASCII). Si vous utilisez un éditeur tel qu’UE, cliquez sur File->Convert->UTF-8 en ASCII, ou sélectionnez encodage ASCII dans Enregistrer sous . Si c’est une ligne se terminant en format DOS, vous pouvez l’ouvrir avec Notepad, cliquer sur Enregistrer sous et sélectionner encodage ASCII. Si elle contient des caractères chinois, vous pouvez utiliser la fonction sauvegarder en tant que UE et sélectionner « UTF-8 no BOM ». Veuillez vous référer à l’image ci-dessous :
Selon les instructions du wiki Bo-Blog : Editplus doit être enregistré en GB puis en UTF-8. Cependant, soyez prudent en faisant cela, tous les caractères qui ne sont pas inclus dans l’encodage GBK seront perdus. S’il y a des caractères non chinois dans le fichier, n’utilisez pas cette méthode. (D’après ce petit aspect, UE - UltraEdite-32 est en effet bien meilleur qu’Editplus, Editplus est trop léger)
Une autre méthode que j’ai trouvée est d’utiliser l’éditeur de fichiers fourni par Wordpress. Cette méthode n’est pas limitée, et il n’est pas nécessaire de télécharger un éditeur spécial, après tout, tout le monde utilise Wordpress. D’abord, activez l’autorisation d’écriture du fichier que vous souhaitez modifier en ftp, puis saisissez l’arrière-plan WordPress - > l’éditeur de fichiers gestion->, saisissez le chemin pour modifier le fichier, puis cliquez sur Modifier le fichier. Vous ne pourrez pas voir les trois premiers caractères de l’écran d’édition qui apparaît, mais ce n’est pas grave, positionnez votre curseur avant le premier caractère du fichier entier et appuyez sur la touche Retour arrière. OK, clique sur Mettre à jour le fichier, rafraîchis-le en ftp, tu verras que le fichier est 3 octets plus petit, et c’est fini.
Enfin, c’est un gros problème : tous ceux qui veulent écrire leurs propres plugins, modifier ceux des autres pour leur usage personnel, et qui doivent modifier le modèle (cela est estimé nécessaire à tous), il est préférable de comprendre ces connaissances pour ne pas être submergés en cas de problème.
|
Publié sur 30/10/2014 17:38:44
|
|
|
