Quand et pourquoi XML est-il préférable à CSV? [fermé]
https://stackoverflow.com/questions/1820129
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Parfois, on a l'impression que XML a été utilisé simplement parce qu'il était à la mode.
La solution
Quelques points forts:
- Vous pouvez valider des données XML sur XSD
- Vous pouvez facilement fournir des contrats (en tant que XSD) à d'autres parties devant créer / utiliser des données XML sans les décrire littéralement
- Vous pouvez avoir une à plusieurs relations à plusieurs niveaux dans la représentation de données XML
- XML est sans doute plus lisible que CSV
- XML est supporté nativement par le framework .net
Pour en nommer quelques-uns du haut de ma tête.
Autres conseils
Les fichiers .csv sont utiles lorsque vos données sont strictement tabulaires et que vous connaissez leur structure. Dès que vous commencez à avoir des relations entre différents niveaux de vos données, XML a tendance à fonctionner mieux, car les relations peuvent devenir évidentes (même sans schémas) simplement en imbriquant.
XML est devenu la valeur par défaut pour ses nombreux avantages déjà mentionnés par de nombreuses autres personnes. La question devient donc vraiment & «Quand et pourquoi le format CSV est-il préférable à XML? &«;
Je pense que le format CSV est préférable au XML lorsque: - vous chargez des données tabulaires simples - vous maîtrisez à la fois la génération et la consommation du fichier de données - le jeu de données est volumineux
Le format CSV est parfaitement utilisable si les deux premiers points sont vrais et offre un avantage en termes de performances d'autant plus important que le jeu de données est volumineux.
J'ai fait un test rapide en chargeant environ 8 000 enregistrements contenant chacun 6 champs de texte. Le chargement et l'analyse du code XML ont pris environ 8 secondes. Le chargement du fichier CSV a pris moins d’une seconde.
La surcharge de XML vaut la peine dans de nombreux cas, mais lorsque les étoiles s'alignent, le format CSV a plus de sens.
Le format CSV est utile lorsque vous ne disposez que d'une série de valeurs liées à une information et que vous savez que vous stockerez toujours des valeurs pour chaque champ.
XML présente l’avantage d’avoir des données auto-descriptives (balises) et une hiérarchie, ce qui vous donne beaucoup plus de flexibilité dans la manière dont vous stockez les données.
Vous pouvez avoir une hiérarchie beaucoup plus complexe, etc. et une structure XML / CSV. Il offre beaucoup plus de flexibilité.
J'ai trouvé un test de performance intéressant sur le net. Bon exemple des inconvénients de XML lorsque les fonctionnalités de XML ne sont pas nécessaires.
& "J'ai essayé l'expérience de Steven sous un angle différent. J'ai rempli un Excel XP feuille de calcul avec un nombre à un chiffre, sauvegardé à la fois en XML et en format fichier texte délimité par des virgules (CSV). J'ai ensuite compressé les deux avec WinZip puis ouvert les deux avec Excel. Voici ce que j'ai trouvé:
Le fichier XML faisait 840 Mo, le fichier CSV 34 Mo - une différence de 2 500% Compressé, le fichier XML faisait 2,5 Mo, le fichier CSV 0,00015Mo (150 Ko) - une valeur de 1 670% différence.
Le temps nécessaire à la décompression et au rendu des fichiers est tout aussi spectaculaire. une feuille de calcul Excel: le fichier XML prenait environ 20 minutes; le CSV a pris 1 minute - une différence de 2000%. "
Bien sûr, il est parfois à la mode et à la mode. Tout dépend de votre application. Je préfère les fichiers de configuration en XML car ils sont faciles à analyser. Alors que j’utilise des fichiers CSV pour DataGridView ou des sauvegardes de bases de données.
Cette WTF quotidien: XML vs CSV Le choix est évident vous aidera à prendre votre décision ;)
XML est préférable au format CSV lorsque les données sont non structurées (schéma inconnu) et seront lues par un humain.
On peut dire que, sauf si les données contiennent principalement du texte, le format CSV est également destiné à la consommation humaine.
Également pertinent, c’est que vos données soient en 2 ou 3 dimensions. Le format CSV convient mieux à un texte en 2 dimensions et, en raison de sa verbosité, XML fonctionne bien avec des données en 3 dimensions.
L'ensemble " standardness " de XML est hyperbole, et ne doit pas être pris à la lettre. XML pose d’énormes problèmes techniques et de nombreuses solutions ne sont pas particulièrement élégantes ni utiles dans de nombreux cas:
- Il utilise un texte pour spécifier son propre codage (poule et œuf?)
- Aucun des langages de schéma les plus courants pour XML ne fonctionne particulièrement bien.
- La manière ancienne et courante de créer des langages de balisage avec
<tags>n’est pas particulièrement utile en tant que norme. - XML tente de relier rétroactivement des langages de balisage plus puissants, tels que ceux basés sur SGML, en créant un fouillis d'héritage incompatible.
- Il reste encore à déterminer si les séquences d'échappement de texte XML peuvent fonctionner sauf dans les cas les plus simples (données conviviales, par exemple).
Pour être clair, XML est probablement le choix incorrect pour 90% des échanges de données pour lesquels il est actuellement utilisé, car ces utilisations rompent tout ou partie des hypothèses ci-dessus.
En plus des autres réponses, XML vous permet de spécifier le jeu de caractères dans lequel se trouve le document.
J'ai trouvé que l'un des principaux avantages du XML était la fonctionnalité d'analyse syntaxique et la validation stricte livrée avec la plupart des bibliothèques XML. L’insistance sur le message d’erreur bien formé et facile à comprendre (xyz non fermé à la ligne x, colonne y) constitue une aide précieuse par rapport à la recherche de valeurs cassées ou à un comportement inconnu à cause d’une erreur dans le fichier CSV.
Le format CSV est plus léger si vous souhaitez déplacer des éléments, car il est normalement deux fois plus petit que XML
.XML est standard et ne sera pas touché par les versions de CSV de différents systèmes d’exploitation
Je n'ai pas assez de réputation pour commenter la réponse pertinente, mais quelqu'un a suggéré de compresser le XML pour gagner la parité de taille avec les formats CSV. Bien que cela soit vrai, la compression XML peut parfois revenir vous piquer. Si vous transférez des données XML d'un point à un autre et que cela échoue, il est agréable de pouvoir lire le code XML et de déterminer ce qui s'est mal passé. Si le fichier XML est compressé et que le transfert échoue, il est parfois impossible de le décompresser et d’en examiner le contenu. En d'autres termes, la compression de XML annule l'avantage de la lisibilité humaine.
Je dirais que vous devez utiliser XML (et / ou JSON) car vous ou quelqu'un (avec un tempérament court et une grande collection d'armes à feu) devra peut-être trouver une erreur dans les données CSV.
Alors oui, je dis lisibilité, n'oubliez pas de penser à l'autre gars! Il pense peut-être à vous.
XML fournit un moyen de baliser vos données avec des métadonnées (fournies par les noms de balises et les noms d'attributs), contrairement à CSV. Ajoutez à cela la possibilité de définir des hiérarchies structurées et facilite la compréhension de XML lorsque seules les données sont fournies, alors que CSV nécessiterait un outil ou un document d'accompagnement pour décrire la manière dont chaque valeur est interprétée.
Vous pouvez facilement parcourir des données XML, même lorsque vous avez des données complexes.
Vérifiez ces liens:
Encore une chose pour XML: le X dans XML signifie E xtensible (je sais, pas vraiment mnémonique :-P). Cela signifie que, à l'aide du mécanisme d'espace de noms XML, vous pouvez associer deux langages XML de votre choix et les combiner dans le même document même . Étant donné qu'il n'existe qu'un seul "langage" CSV (sans compter les myriades de styles de délimiteurs), XML peut gérer beaucoup de complexité, et cela de manière modulaire.
C’est toutefois l’avantage du format CSV: si vous disposez réellement de données tabulaires, la syntaxe XML est souvent excessive.
J'ai également constaté que certains générateurs / analyseurs syntaxiques de cvs rencontraient beaucoup de difficultés avec les données textuelles générales. Les longues chaînes de texte contenant beaucoup de retours à la chaine, des virgules, des citations, etc., rendent la vie vraiment difficile lorsqu'il s'agit de manipuler un cvs.
SSMS aime tronquer csv pour le plaisir.
Structurés, lisibles par l'homme, plus faciles à modifier, la validation, la parsabilité, la transformabilité, la frappe, les espaces de noms, les bibliothèques puissantes qui les sous-tendent, font partie des nombreuses raisons.
Par dessus tout, bien que ce soit standard.
- Il existe des analyseurs syntaxiques et des émetteurs existants dans toutes les langues et bases de données
- Ils traitent de l'encodage pour moi
- Ils traitent d'échapper pour moi
C'est tout ce qui compte pour moi.
Bien sûr, il existe un moyen semi-standard de s’évader en CSV (c.-à-d. & "comme Excel le fait &";), et il n’est pas difficile de s’écrire soi-même, mais cela prend un peu temps. Et puis, vous devez implicitement accepter un codage de caractères hors bande. Mais alors, parce que c'est si simple, les gens essaient de l'écrire eux-mêmes et bousillent invariablement le n ° 2 ou le n ° 3.
JSON rencontre également les positions n ° 2 et n ° 3 et est sur le point de satisfaire n ° 1. C'est sans doute aussi plus simple, du moins pour les fichiers non documentés. Sans surprise, je l’utilise de plus en plus, en interne et en externe.
Et je le préfère aussi parce que c'est beaucoup plus lisible.
