Outils de développement · Convertisseurs de syntaxe
XML à partir de SGML : pourquoi il a des attributs, des espaces de noms et des DTD Les bizarreries de
· Contexte
xml formats de données sécurité
XML (attributs par rapport aux éléments, espaces de noms, DTD, contenu mixte) ont du sens une fois que vous savez qu'il a été conçu comme un SGML simplifié pour les documents, pas pour les données. Cet article retrace cette lignée et ce que cela signifie lorsque vous convertissez XML en JSON.
Pourquoi ce format de données possède-t-il des attributs ? — un développeur convertissant XML en JSON et répondant à une distinction JSON jamais nécessaire
JSON a un type de propriété d'objet ; XML distingue les attributs, les éléments enfants et le texte. ToolAcre mappe cette distinction avec les attributs `@` et les clés enfants ordinaires. La différence est visible lorsqu'un élément a à la fois `id="7"` et un enfant `<id>` : les deux survivent sous des propriétés distinctes.
Cette convention explique la forme résultante sans prétendre que les attributs ont un rôle sémantique universel. Les auteurs XML les choisissent selon leurs propres schémas. Le convertisseur conserve la catégorie de nœuds qu'il peut observer, et non la raison commerciale pour laquelle il a été choisi.
SGML et la tradition documentaire — ISO 8879, balisage pour la publication et idée de baliser le texte plutôt que d'encoder les enregistrements
Le contenu mixte, les enfants ordonnés, les attributs, les commentaires et les instructions de traitement sont des fonctionnalités orientées document présentes dans la source XML. L'implémentation démontre leur manipulation mais ne contient aucune preuve de la chronologie SGML, de l'historique des publications ISO ou des motivations de l'industrie de l'édition.
Un article limité à la source part donc d'un comportement exécutable. Le texte autour des éléments enfants entraîne des pertes ; les commentaires et les instructions de traitement sont supprimés ; CDATA reste marqué. Ces faits expliquent pourquoi une arborescence de documents ne s'intègre pas clairement dans une arborescence de valeurs JSON.
Fonctionnalités XML orientées document visibles dans l'implémentation, sans revendication d'historique SGML
L'analyseur valide les XML bien formés et signale la ligne et la colonne. Il ignore la déclaration dans la valeur résultante et préserve les cinq entités intégrées et les références de caractères numériques sous forme de texte décodé. Il n'établit pas d'objectifs de groupe de travail ni de compte rendu de conception en dix principes.
Les affirmations historiques nécessitent des sources éditoriales externes, que cette tâche n'ajoute pas. Les omettre est plus précis que d'inventer une conformité ou une provenance à partir d'un nom de dépendance.
L'analyseur gère la syntaxe XML ; les preuves du dépôt n'établissent pas l'historique de conception 1998
Les attributs deviennent des clés préfixées par `@` ; les éléments conservent leurs noms. Le texte à l'intérieur d'un élément structuré se déplace vers `#text`, tandis qu'un élément de texte uniquement se réduit en une chaîne. Cela sépare les catégories structurelles dans la mesure où un modèle objet le permet.
L'écriture de XML inverse la convention : `@id` devient un attribut. Les noms d'attributs ou d'éléments non valides sont refusés plutôt que nettoyés. Cette décision empêche un mappage mal formé de devenir plausible XML avec des noms modifiés silencieusement.
Les attributs et les éléments restent distincts selon la convention @ de ToolAcre
Les préfixes d'espace de noms sont conservés textuellement dans les noms d'éléments et d'attributs, y compris les déclarations d'espace de noms. Ils ne sont pas résolus, supprimés ou réécrits. Cela préserve l'orthographe de la source mais ne prend pas en compte la résolution de type prenant en compte l'espace de noms.
Chaque DOCTYPE est rejeté avant que fast-xml-parser ne reçoive le document. Le masque évite les fausses correspondances dans les commentaires et CDATA. Cela empêche les demandes d'entités externes, les lectures d'entités de fichiers locaux et les attaques par extension d'entité, sans possibilité de contourner le refus.
Les préfixes des espaces de noms sont conservés littéralement et chaque DOCTYPE est refusé
Dans `<p>before<b>bold</b>after</p>`, le placement du texte est important. ToolAcre détecte le contenu mixte, joint les fragments sous `#text` et avertit que leurs positions par rapport aux enfants sont perdues. Les propriétés d'objet JSON ne peuvent pas reproduire une séquence ordonnée de nœuds de texte et d'élément alternés.
Les enfants répétés du même nom deviennent des tableaux, mais les frères et sœurs nommés différemment restent des propriétés. Le code nécessitant un ordre exact des documents doit utiliser une représentation de nœud XML plutôt que de traiter l'objet converti comme complet.
Ce que cela ne couvre pas : XSLT, XPath et XQuery, les langages de traitement qui se sont développés autour de XML
XSLT, XPath et XQuery ne sont ni importés ni exposés. Le panel ne valide pas non plus XSD, ne traite pas les déclarations DTD ou ne construit pas d'objets de domaine typés. Il s’agit d’une projection de données avec des limites explicites de sécurité et de fidélité.
Un langage de requête ou de transformation peut préserver et naviguer dans l'ordre des nœuds d'une manière que cette conversion en valeur simple ne peut pas. Choisissez cet outil lorsque les fonctionnalités du document font partie du travail plutôt que d’être un emballage accessoire.
À retenir : XML est un format de document qui a appris à transporter des données – et comment le panneau des convertisseurs de syntaxe montre ce qui survit à sa traduction en JSON Le modèle de données observables de
XML inclut des distinctions absentes de JSON. ToolAcre marque les attributs, CDATA et le texte structuré, conserve les préfixes d'espace de noms, supprime les nœuds non-données et refuse les DOCTYPE. Chaque choix est visible et testé.
Utilisez le panneau pour découvrir ce qui survit à une projection, et non en tant qu'autorité historique ou processeur XML complet. Lors de la commande, les schémas ou la sémantique des espaces de noms sont importants, conservez l'arborescence d'origine et utilisez les outils XML spécialement conçus.
La sécurité et la fidélité se croisent également à la limite du DOCTYPE. Refuser la déclaration empêche le traitement de l'entité, mais la supprimer d'un document hérité arbitraire peut modifier les références d'entité ou les hypothèses de validation. Si vous possédez la source, remplacez les entités requises par du texte sécurisé explicite et validez le document résultant. Si vous n'en êtes pas propriétaire, utilisez un workflow XML approuvé plutôt que d'affaiblir le refus ou de présenter une conversion partielle comme contenu original.