Servir UTF-8 avec une nomenclature présente-t-il des inconvénients?
En travaillant avec un client, je viens de remarquer que tous leurs fichiers sont enregistrés sous Windows-1252, mais ils les servent avec charset=utf-8 sur l'en-tête Content-Type (par exemple, Content-Type: text/html; charset=utf-8 et similaire pour leurs fichiers JS et CSS).
Je leur ai recommandé d'utiliser réellement UTF-8, ce qu'ils sont heureux de faire. Mais leur principal outil de création est VS.Net 2012, qui utilise par défaut Windows-1252 (les paramètres régionaux anglais sont installés par Windows), à moins que le fichier ne comporte une signature indiquant le contraire. (J'ai été très surpris de ne pas trouver de réglage pour cela, mais j'ai trouvé plusieurs réponses sur Stack Overflow qui semblent confirmer que ce n'est pas le cas: 1 , 2 , .)
Nous pouvons donc résoudre ce problème en enregistrant leurs fichiers au format UTF-8 avec une nomenclature (et éventuellement en mettant à jour les modèles de manière à ce que les nouveaux fichiers soient créés de cette manière), car si VS.Net voit la nomenclature, il se souviendra de les enregistrer ultérieurement. Le standard Unicode ( PDF ) indique que l'utilisation d'une nomenclature avec UTF-8 est autorisée mais (curieusement, à mon sens) "non recommandée":
L'utilisation d'une nomenclature n'est ni requise ni recommandée pour UTF-8, mais peut se produire ... lorsque la nomenclature est utilisée comme signature UTF-8.
Existe-t-il des inconvénients importants à ce que servir UTF-8 avec une nomenclature soit destiné aux utilisateurs généraux du Web? Problèmes avec les agents utilisateurs qui se trompent, ou ...? Je veux dire, tout ce qui comprend Unicode est nécessaire pour comprendre la nomenclature, donc ça devrait , mais nous savons tous que la réalité s'écarte parfois de la théorie. .
Non, l'utilisation de documents HTML au format UTF-8 avec nomenclature ne présente aucun inconvénient majeur. Les affirmations contraires sont encore courantes, mais elles reposent sur un malentendu. Certains navigateurs très anciens, que vous pouvez maintenant trouver dans un musée si vous êtes très chanceux, ont converti une nomenclature littéralement en codage. Même à notre époque, le logiciel PHP ne peut toujours pas gérer correctement la nomenclature. Par conséquent, vous ne devez pas utiliser la nomenclature au début d'un PHP, car cela peut poser problème lorsque ce fichier est concaténé ou inséré par PHP. Mais c'est un problème intrinsèque à PHP.
Les logiciels utilisés pour les documents HTML doivent gérer la nomenclature. C’est une exigence assez fondamentale, et UTF-8 avec nomenclature est si courant qu’un tel logiciel devrait être évité. Les personnes qui dérangent encore avec de tels programmes ne doivent pas être considérées comme un inconvénient majeur.
La page W3C La marque d'ordre en octets (HTML) en HTML ne mentionne plus aucun problème de navigateur. Il mentionne des problèmes de traitement de documents HTML avec du code de programme, mais cela signifie simplement que lorsque vous écrivez du code pour traiter des pages HTML codées en UTF-8, ou tout ce qui est codé en UTF-8, vous devez être préparé à la nomenclature.
L'un des avantages de l'UTF-8 est qu'un logiciel ne connaissant que ASCII peut toujours lire les fichiers. Lorsqu'un repère d'ordre d'octet est présent dans le fichier, certains logiciels qui attendent _ du texte ASCII peuvent se plaindre du fait que le fichier est "binaire".
Les navigateurs Web modernes sont tous capables de consommer UTF-8 avec une nomenclature. Je recommanderais toujours de supprimer la nomenclature, car la compatibilité avec des outils Unix tels que grep est moins simple.
De plus, je ne connais aucun avantage à inclure une nomenclature pour UTF-8. Il semble donc évident de l'omettre. (Ceci est différent de UTF-16 qui a des variantes big endian et little endian qui doivent être distinguées avec une nomenclature).