Un problème qui n'a jamais été résolu lors du développement est que la page utilise le codage UTF8 et que l'en-tête et la queue utilisent la méthode d'inclusion de fichiers de modèle. Par conséquent, il y a une ligne vierge supplémentaire d'environ 10 pixels dans l'en-tête et la queue sans aucune. raison, et il n’y a rien.
La raison en est qu'ils sont tous codés en utf8. Lors de l'inclusion de fichiers, le flux binaire final contient plusieurs balises de nomenclature UTF8. IE ne peut pas analyser normalement les pages contenant plusieurs balises de nomenclature UTF8 et les remplace directement par les retours chariot réellement affichés, ce qui entraîne un message. Lignes vides, mais Firefox n'a pas ce problème.
Par conséquent, si le modèle utilise la méthode d'inclusion pour contenir plusieurs fichiers utf8 et doit être enregistré avec ultraedit, sélectionnez simplement utf8 sans format BOM lors de l'enregistrement en tant que fonction.
De plus, si la page chinoise met la balise title devant <meta http-equiv=”content-type” content=”text/html; charset=UTF-8″ /> dans la balise head html, la page sera vide.
Les pages utf8 doivent donc utiliser l'ordre standard
<meta http-equiv=”content-type” content=”text/html;
<méta http-equiv="content-langage" content="zh-CN" />
<meta name=”robots” content=”index,follow” />
<meta name="keywords" content="" />
<meta name="description" content="" />
<meta name="rating" content="general" />
<meta name="auteur" content="" />
<meta name="copyright" content="" />
<meta name="generator" content="" />
<title></title>
En-tête de la BOM : xEFxBBxBF PHP4 et 5 ignorent toujours la BOM, ils sont donc affichés directement avant l'analyse.
Il y a une description spéciale de ce problème dans la FAQ standard de w3.org :
http://www.w3.org/International/questions/qa-utf8-bom
Les détails sont les suivants :
Dans l'encodage UCS, il y a un code appelé caractère "ZERO WIDTH NO" -BREAK SPACE", son encodage est FEFF. FFFE est un caractère qui n'existe pas dans UCS, il ne devrait donc pas apparaître dans la transmission réelle. La spécification UCS recommande de transmettre les caractères "ZERO WIDTH NO-BREAK SPACE" avant de transmettre le flux d'octets. De cette façon, si le récepteur reçoit FEFF, cela indique que le flux d'octets est Big-Endian ; s'il reçoit FFFE, 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 de nomenclature pour indiquer l'ordre des octets, mais peut utiliser la nomenclature pour indiquer la méthode de codage. Le codage UTF-8 du caractère « ZERO WIDTH NO-BREAK SPACE » est EF BB BF. Ainsi, si le récepteur reçoit un flux d'octets commençant par EF BB BF, il sait qu'il est codé en UTF-8.
Windows est un système d'exploitation qui utilise BOM pour marquer la méthode d'encodage des fichiers texte : WindowsXP Professionnel, jeu de caractères par défaut : chinois
1) bloc-notes : peut identifier automatiquement les fichiers au format d'encodage UTF-8 sans BOM, mais ne peut pas contrôler lors de l'enregistrement des fichiers. ajouter une nomenclature Si le fichier est enregistré, la nomenclature sera ajoutée uniformément.
2) editplus : ne peut pas reconnaître automatiquement les fichiers au format d'encodage UTF-8 sans BOM. Lors de l'enregistrement du fichier, sélectionnez le format UTF-8 et n'écrira pas l'en-tête de BOM dans l'en-tête du fichier.
3) UltraEdit : La fonction la plus puissante pour l'encodage de caractères. identifie automatiquement les fichiers UTF-8 avec BOM et sans BOM (peut être configuré) ; lors de l'enregistrement, vous pouvez choisir d'ajouter ou non une BOM via la configuration
(la remarque particulière est que lors de l'enregistrement d'un fichier nouvellement créé, vous devez choisir d'enregistrer au format UTF. -8 sans format bom)
Plus tard, j'ai découvert que Notepad ++ prenait également mieux en charge le bom utf-8, et je recommande à tout le monde de l'utiliser.