Pourquoi les caractères de "contrôle" sont-ils illégaux dans XML 1.0?
Il existe une variété de caractères qui ne sont pas légalement encodables dans XML 1.0, par exemple U+0007 ('cloche') et U+001B ('échapper'). La plupart des caractères intéressants sont des caractères de "contrôle" non blancs.
Il est clair (par exemple) cette question et d'autres que c'est la spécification XML qui est le problème - mais quelqu'un peut-il m'éclairer sur pourquoi la spécification XML interdit ces caractères?
Il semble qu'il aurait pu être nécessaire de les coder dans des échappements, par exemple comme  et  respectivement, mais peut-être y a-t-il une raison pratique pour laquelle les caractères étaient interdits plutôt que requis pour être échappés?
Les répondants ont suggéré qu'il y avait une certaine motivation à éviter les caractères de contrôle de transmission, mais Unicode inclut de nombreux autres caractères de type contrôle (pensez à U+200C "sans jointure de largeur nulle"). Je reconnais qu'il n'y a peut-être aucune bonne raison à ce comportement, mais j'aimerais quand même mieux le comprendre.
C'est particulièrement frustrant parce que lorsque ces valeurs de caractères apparaissent dans d'autres encodages formats de données, je finis par "double échapper" de nouveaux documents XML qui doivent encoder cela.
Il semble qu'il aurait pu être nécessaire de les coder dans des échappements, par exemple comme # x0007; et # x001B;
Vous pouvez faire exactement cela dans XML 1.1, pour tous sauf\0.
C'était il y a longtemps, mais je me souviens mieux qu'ils n'ont pas de représentation graphique ni de sémantique convenue. En choisissant un couple au hasard, nous voyons U + 0006 "Acquitter" ou U + 0016 "Ralenti synchrone" ... qu'est-ce que cela signifie? Unicode ne le dit pas. Même à l'époque où tout le monde prétendait prendre en charge ASCII, il n'y avait aucune interopérabilité autour de cette ordure. XML est censé concerner l'interopérabilité.
L'expérience a été que les gens qui veulent utiliser ces choses veulent vraiment brouiller des données binaires dans leurs éléments XML (et la prochaine chose qu'ils veulent est d'inclure U + 0000 NULL), ce qui est un objectif explicite de XML depuis le jour 1. Si vous voulez représenter les nombres 0x6 ou 0x16, il existe de nombreuses bonnes façons de faire cela qui ne brouillent pas la notion de "caractère".
Il est probablement temps de résumer, également avec une vue sur XML 1.1.
Quels sont les points de code des caractères de contrôle dans Unicode?
U+0000ÀU+001f, Hérité de l'ASCII.U+007F, Hérité de ASCIIU+0080ÀU+009F, Hérité de Latin-1- diverses gammes spéciales, standardisées explicitement pour Unicode, et surtout utiles en particulier dans des contextes non-balisage. Ils sont discuté ici bloc par bloc, y compris les raisons pour lesquelles et comment les utiliser ou ne pas les utiliser en XML et quoi faire si vous les rencontrez de toute façon.
Comment XML regarde-t-il ces caractères de contrôle?
Il s'agit d'une classification différente.
- La tabulation et la nouvelle ligne (quelle que soit la dépendance de la plate-forme de ce qu'est une nouvelle ligne) sont bonnes. Tout le monde les utilise. Tout le monde sait ce qu'ils sont censés représenter. Autorisé sous presque toutes les formes connues, souvent même pour une jolie impression du balisage lui-même.
U+0000Est mauvais. Caractère nul? Terminateur de chaîne? Bruit binaire? Antithèse à la fois de l'interopérabilité et du balisage. Interdit sous toutes ses formes.- Rien d'autre? Interopérabilité peu utilisée et problématique, mais il existe des moyens de les tolérer même sans trop savoir ce qu'ils sont censés "contrôler".
Passons maintenant à cette dernière catégorie uniquement, les codes de contrôle proprement dits. Autrement dit, le résumé suivant ne s'applique PAS aux onglets et aux nouvelles lignes: U+0009, U+000a, U+000D, U+0085, U+2028.
XML 1.0 autorise toutes les plages de caractères de contrôle ci-dessus, sauf U+0000 À U+001f, Sous forme de texte (caractères directement inclus) et sous forme de références de caractères numériques . Autoriser U+007F À U+009F Était apparemment par omission et cette incohérence a été corrigée dans XML 1.1, mais l'inverse. Ils ont même donné une justification détaillée à l'intérieur de la norme:
Enfin, il existe une demande considérable pour définir une représentation standard des caractères Unicode arbitraires dans les documents XML. Par conséquent, XML 1.1 permet l'utilisation de références de caractères aux caractères de contrôle # x1 à # x1F, dont la plupart sont interdits dans XML 1.0. Cependant, pour des raisons de robustesse, ces caractères ne peuvent toujours pas être utilisés directement dans les documents. Afin d'améliorer la robustesse de la détection du codage de caractères, les caractères de contrôle supplémentaires # x7F à # x9F, qui étaient librement autorisés dans les documents XML 1.0, doivent désormais également apparaître uniquement en tant que références de caractères. (Les caractères d'espaces sont bien sûr exemptés.) Le sacrifice mineur de la compatibilité descendante est considéré comme non significatif. En raison de problèmes potentiels avec les API, # x0 est toujours interdit à la fois directement et comme référence de caractère.
Pourquoi Unicode et XML permettent-ils l'utilisation gratuite de caractères de contrôle de type balisage, en dehors des quelques plages "héritées"? Les gens devraient utiliser le balisage pour ceux-ci.
Unicode est également utilisé dans des contextes non-balisage, et c'est un jeu de caractères en constante évolution. Il serait trop difficile d'implémenter un processeur XML conforme si l'ensemble de caractères non contrôlés était une cible mobile.
OK, quel est le problème avec les plages héritées, par rapport aux caractères de contrôle spécifiques à Unicode?
Manque de standardisation. Le consortium Unicode n'a pas vraiment pu choisir les numéros attribués à ces "personnages", ni quelle est leur présentation visuelle ou leur signification typiques. Rétrocompatibilité totale avec ASCII (au niveau UTF-8 codé) et avec Latin-1 (au niveau de l'affectation des points de code), inclusion brute forcée de ces points de code indépendamment des diverses significations spécialisées et surchargées souvent attaché à eux dans divers contextes de traitement de texte.
Attendez, dites-vous que XML n'est pas censé être entièrement rétrocompatible avec ASCII, contrairement à UTF-8?
Ouais. C'est correct. Vous avez besoin d'un élément de document. Vous ne pouvez même pas mettre un < Ou & Brut. Alors pourquoi auriez-vous besoin de mettre des caractères de contrôle bruts?
XML a été spécialement conçu autour d'Unicode (en particulier UTF-8 et UTF-16) et ISO/IEC 10646, qui tous les deux (je ne suis pas tout à fait positif à propos d'ISO 10646) contiennent les caractères de contrôle de transmission/flux qui restaient de ASCII et les jours des terminaux basés sur des caractères. Bien que ces caractères aient encore des utilisations, ils n'appartiennent pas à un format comme XML.
Quant à ces nouveaux encodages qui utilisent ces codes pour autre chose, eh bien, il semble que la spécification XML devra peut-être s'adapter.
Pourquoi leur échappez-vous deux fois? Cela semble être un bon endroit pour & bell; et & escape ;. (Non défini, géré par rappel de l'analyseur à votre code)