OK, j'ai lu quelques livres sur XML et écrit des programmes pour la cracher et ce qui n'est pas. Mais voici la question. À la fois un fichier délimité par des virgules et un fichier XML sont "lisibles humains". Mais en général, le fichier délimité des virgules est beaucoup plus facile à mes yeux qu'un fichier XML; Les étiquettes prennent généralement autant plus d'espace que les données. Cela semble juste obscurcir ce que je lis et que le format peut prendre une page pour contenir les mêmes informations que vous pouvez contenir sur une seule ligne de texte dans un fichier délimité par des virgules. Et un fichier délimité par des virgules est nettement moins complexe pour analyser. La vraie question est donc pourquoi xml? Juste parce que tous les enfants cool le font?
12 Réponses :
Tout dépend de ce que vous devez faire. Si vous avez besoin de plus de complexité dans vos structures de données qu'une simple structure de rangée «plate» peut donner. Par exemple, des données hiérarchiques, alors XML est un excellent choix.
XML prend en charge une représentation complexe, structurée et hiérarchique des choses. C'est loin de ce que CSV peut stocker de manière triviale.
Pensez à un graphique d'objet complexe dans un environnement orienté objet. Il peut être sérialisé comme un document XML assez facilement mais CSV ne peut pas gérer une telle chose.
OK, je vais donner hierchical vs csv. Mais si je pense à un environnement complexe d'objet orienté objet, une syntaxe C ++ ou Java pour la représentation des données est beaucoup plus léger. J'ai vraiment pensé à écrire un analyseur de données de style «C-Structure» car la syntaxe est tellement plus propre.
CSV n'a jamais été vraiment une norme. Juste la même méthode rapide et sale d'un groupe de personnes proposées de manière indépendante. Bien sûr, certaines de ces personnes étaient plus intelligentes que d'autres et se sont rendues nécessaires pour échapper aux personnages, mais d'autres non. Même MSSQL exporte des CSV de manière incorrecte. Il y a une bonne façon de faire du XML de manière documentée, donc si vous le faites bien et que la demande de quelqu'un ou tout ce qui ne l'accepte pas, vous avez un peu de poids lorsque vous dites "ce n'est pas de ma faute."
Bon exemple: Comment gérez-vous des données contenant une virgule dans un CSV? XML a une bonne façon documentée de traiter des cas comme celui-ci.
Ce n'est pas vraiment une raison d'utiliser XML, cependant.
XML peut être validé contre un contrat (schéma ou DTD).
XML a également des technologies complémentaires entourant: XMLDOM, XPATH, XSLT, XSD, XML Schemas
Avantages
Un nombre d'avantages XML a sur CSV:
Cela dépend complètement du domaine du problème et de ce que vous essayez de résoudre.
Le dernier élément est quelque chose que beaucoup de gens manquent lors de la rédaction de pages Web. Considérez la situation où vous avez un grand magasin de données de chansons. Les chansons ont des artistes, des albums, des battements par minute, etc. Vous pouvez exporter les données sur XML, écrire une feuille de style simple pour rendre XML comme xhtml, puis pointez le navigateur à la page XML. Le navigateur rendra le XML comme une page Web.
Vous ne pouvez pas faire cela avec CSV.
Joel Spolsky a Un excellent article sur pourquoi XML est un mauvais choix en tant que Store de données complexe: il est lent. (Contrairement à une base de données, qui peut récupérer des enregistrements précédents ou suivants avec une seule instruction CPU, les enregistrements de traversée dans un document XML sont beaucoup plus lents.) Sans aucun doute, cela pourrait être considéré comme un problème d'optimisation, résolu par Attente 18 mois . Ainsi:
Voir aussi: Pourquoi devrais-je utiliser un fichier lisible humain Format .
+1 Exactement, il y a tout un écosystème d'outils et de spécifications autour de XML. Un autre: XML Digital Signatures vous donne un moyen standard d'authentifier les données. w3.org/signature
Ce ne sont pas les deux seules options, vous pouvez également utiliser JSON ou YAML qui sont beaucoup plus légers que XML.
En général, si vous avez des données tabulaires simples avec de nombreux caractères spéciaux, CSV n'est pas un mauvais choix. Pour les données structurées, envisagez d'utiliser l'un des 3 autres.
+1: Beaucoup de gens oublient qu'il existe des formats en plus de XML qui font presque exactement la même chose. Je n'ai jamais vraiment travaillé avec Yaml mais Json est une excellente alternative "légère" à XML (sans oublier qu'il est plus facile d'analyser dans la plupart des langages de programmation).
Oh, Geeze, c'est bien que je regardais des yeux de Yaml et Json. Et cela me donne vraiment ma réponse. Il existe définitivement de meilleurs formats de non-proprementie que XML.
Pour de nombreux cas, Json est certainement préférable de travailler avec XML. Lorsque XML gagne la traction ici est lorsque vous travaillez avec des schémas standardisés et lors de l'intégration des schémas ensemble (les espaces de noms sont une bonne idée de klaxon!). Si vous n'avez pas besoin de cela, et surtout si vous créez un format ad-hoc pour vos propres besoins, accédez à JSON ou YAML.
Eh bien XML est lisible humain et éditable humain. Vous pouvez regarder un fichier XML et savoir exactement ce que c'est. Un fichier CSV est lisible par l'homme, mais vous ne savez pas vraiment ce que chaque valeur signifie du tout.
Par exemple, si nous stockons des comptes d'utilisateurs, que préférez-vous? P>
<user>
<username>ryeguy</username>
<password>abc123</password>
<regdate>3-4-08</regdate>
<email>my@email.com</email>
<posts>
<post>
<id>34</id>
....
</post>
</posts>
</user>
Je ne sais pas, le format de fichier prend en réalité plus d'espace que les données réelles. Data, c'est-à-dire les choses que vous avez besoin de savoir! Si je fais à partir d'un programme au lieu de la main, alors "
Vous voulez probablement une ligne d'en-tête comme, «Nom d'utilisateur, mot de passe, regdate, email» comme première ligne, puis vous ne vous souvenez vraiment pas de vos champs.
Le fait que XML soit lisible par l'homme ne signifie pas que cela a été fait avec l'idée de le faire lire (ou même édité) directement par des humains.
XML a un bon ensemble de propriétés qui en font un bon choix pour de nombreux cas, en particulier lorsque vous avez les ressources humaines pour faire face au fardeau supplémentaire que ces propriétés apportent inévitablement: validation, standard bien défini, beaucoup de Outils, une architecture très flexible, il mesure bien un modèle d'arbre, ce qui est ce que de nombreux programmes utilisent. Sa lisibilité humaine est une valeur ajoutée qui simplifie le débogage (essayer de déboguer d'un fichier binaire ...), d'une inspection et de petits changements pour les cas triviaux.
CSV d'autre part est facile, rapide et linéaire, bien que de nombreux dialectes existent et que cela analyse bien est En général, toutefois, il existe des cas de représentation de données que vous pouvez résoudre avec XML, mais vous ne pouvez pas résoudre avec CSV (par exemple, un arbre). D'autre part, toutes les données pouvant être représentées dans CSV peuvent également être représentées en XML, bien qu'elle ne soit pas garantie (et est également vérifiée) qu'elle sera plus efficace (en termes d'espace, de facilité d'analyse, etc.). C'est une question de "degrés de liberté" de votre format. XML a une valeur plus élevée de degré de liberté. CSV est plus bas. Le battage médiatique derrière XML est également relatif à ce fait.
Ne pas tomber victime du syndrome de marteau: lorsque vous avez un marteau (XML), tout ressemble à un clou (quelque chose que vous devez résoudre avec XML). La réalité est très différente et nuancée. XML est cool, mais ce n'est pas la réponse à aucun problème.
J'aime le commentaire du marteau.
Parmi les raisons pour lesquelles vous pouvez préférer XML sur CSV (dépend de la tâche à la main): * Presque toutes les plates-formes et les langues ont des bibliothèques existantes pour la lecture, l'écriture, l'analyse et la manipulation de XML. * XML a des règles bien définies pour coder tous les caractères. CSV a des ambiguïtés telles que comment encoder des virgules faisant partie des données. * XML prend en charge une variété de formes de données (comme hiérarchique) où, comme CSV étant le plus utile lorsque les données ressemblent à une table (rangées et colonnes).
XML décrira le contenu et a également une tonne de bibliothèques de support dans une variété de langues ... mais cela peut être gonflé. Si l'extrémité réceptrice de la CSV est au courant de la mise en page et qu'il est tabulaire, je ne vois rien de mal avec elle.
J'aime penser à la distinction primaire dans ce cas car XML est basé sur l'arborescence, tandis que le CSV est basé sur la table.
C'est-à-dire que vous pouvez nier et repousser et omettre et émettre généralement une structure d'arborescence complexe en XML, alors que vous ne pouvez faire que des tables 2D simples en CSV.
La notion qu'il y a des outils disponibles, est basée sur l'idée qu'elle a été largement adoptée pour commencer. Mais d'une perspective de syntaxe, pourquoi? Les mêmes informations pourraient être représentées dans un format beaucoup plus concis. C'est comme lire certaines des spécifications que je reçois au travail, 10 pages de plaque de chaudière, pour 3 pages d'informations. Cela ne me donne pas une bonne raison pour laquelle cela a été utilisé en premier lieu.