Quand et pourquoi XML est-il préférable à CSV?
parfois, on a l'impression que XML a été utilisé simplement parce qu'il était à la mode.
Quelques points forts:
- Vous pouvez valider les données XML par rapport à XSD
- Vous pouvez facilement fournir contrats (comme XSD) à d'autres parties qui devraient soit créer/consommer des données XML, sans les décrire littéralement
- Vous pouvez avoir une à plusieurs relations à plusieurs niveaux dans la représentation des données XML
- XML est sans doute plus lisible que CSV
- XML est nativement pris en charge par le framework .net
Pour n'en nommer que quelques-uns du haut de ma tête.
Les fichiers .csv sont bons 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 à mieux fonctionner car les relations peuvent être rendues évidentes (même sans schémas) simplement par imbrication.
XML est devenu la valeur par défaut pour ses nombreux avantages que beaucoup d'autres personnes ont déjà mentionnés. Ainsi, la question devient vraiment "Quand et pourquoi le CSV est-il préférable au XML?".
Je pense que CSV est préférable à XML lorsque: - vous chargez des données tabulaires simples - vous contrôlez à la fois la génération et la consommation du fichier de données - l'ensemble de données est volumineux
Le CSV est parfaitement utilisable si les 2 premiers points sont vrais et a un avantage de performance qui devient plus significatif plus le jeu de données est grand.
J'ai fait un test rapide en chargeant ~ 8000 enregistrements chacun avec 6 champs de texte. Le chargement et l'analyse du XML ont pris environ 8 secondes. Le chargement du CSV a pris moins d'une seconde.
Les frais généraux de XML en valent la peine dans de nombreux cas, mais lorsque les étoiles s'alignent, CSV a plus de sens.
CSV est utile lorsque vous n'avez qu'une série de valeurs liées à une information et que vous savez que vous stockerez toujours des valeurs pour chaque champ.
XML a l'avantage d'avoir des données auto-descriptives (balises) et d'avoir une hiérarchie - ce qui vous donne beaucoup plus de flexibilité dans la façon dont vous stockez les données.
J'ai trouvé un test de performance intéressant sur le net. Dieu 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 une feuille de calcul Excel XP avec un numéro à un chiffre, je l'ai enregistrée à la fois en XML et dans un fichier texte délimité par des virgules (CSV). I puis compressé les deux avec WinZip, puis ouvert les deux avec Excel. Voici ce que j'ai trouvé:
Le fichier XML était de 840 Mo, le CSV 34 Mo - une différence de 2500% compressé, le fichier XML était de 2,5 Mo, le CSV 0,00015 Mo (150 Ko) - une différence de 1670%.
Tout aussi dramatique est le temps qu'il a fallu pour décompresser et rendre les fichiers sous forme de feuille de calcul Excel: cela a pris environ 20 minutes avec le fichier XML; le CSV a pris 1 minute - une différence de 2 000%. "
Vous pouvez avoir une hiérarchie beaucoup plus complexe, etc. et une structure avec XML vs CSV. Il offre beaucoup plus de flexibilité.
Bien sûr, il est à la mode et parfois à 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 vidages de base de données.
Ceci WTF quotidien: XML vs CSV Le choix est évident vous aidera à prendre votre décision;)
XML est préférable à CSV lorsque les données ne sont pas structurées (schéma inconnu) et seront lues par un humain.
Sans doute, à moins que les données ne contiennent principalement du texte, le CSV est également destiné à la consommation humaine.
Il est également pertinent de savoir si vos données sont en 2 ou 3 dimensions. CSV est le plus approprié pour le texte en 2 dimensions, et en raison de sa "verbosité", XML fonctionne bien avec les données en 3 dimensions.
Toute la "standardité" de XML est une hyperbole et ne doit pas être prise à la lettre. XML a d'énormes problèmes techniques et de nombreuses solutions ne sont pas particulièrement élégantes, ou dans de nombreux cas utiles:
- Il utilise du texte pour spécifier son propre encodage de texte (poulet 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 à l'aide de
<tags>n'est pas particulièrement utile en tant que norme. - XML essaie de déchausser rétroactivement des langages de balisage plus puissants tels que ceux basés sur SGML, créant ainsi un gâchis d'héritage incompatible.
- Il reste à déterminer si les séquences d'échappement de texte XML peuvent fonctionner pour tout sauf les cas les plus simples (c'est-à-dire les données conviviales).
Pour être clair, XML est probablement le mauvais choix pour 90% de l'échange de données pour lequel il est actuellement utilisé, car ces utilisations cassent tout ou partie des hypothèses ci-dessus.
En plus des autres réponses, XML vous permet de spécifier dans quel jeu de caractères se trouve le document.
J'ai trouvé que les plus grands avantages de XML sont la fonctionnalité d'analyse et la validation stricte qui sort de la boîte avec la plupart des bibliothèques XML. L'insistance sur une bonne forme et un message d'erreur facile à comprendre (xyz non fermé dans la ligne x, colonne y) est une réelle aide par rapport à la recherche de valeurs cassées ou d'un comportement inconnu, en raison d'une erreur dans le fichier CSV.
Je dirais utiliser XML (et ou JSON) parce qu'un jour, vous ou quelqu'un (avec un tempérament court et une grande collection d'armes à feu) devrez peut-être rechercher 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.
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 en parité de taille avec les formats csv. Bien que cela soit vrai, la compression XML peut parfois revenir pour vous mordre. Si vous transférez des données XML d'un point à un autre et que cela échoue, c'est bien de pouvoir lire le XML et comprendre ce qui n'a pas fonctionné. Si le XML est compressé et que le transfert échoue, il n'est parfois pas possible de le décompresser et d'examiner le contenu. En d'autres termes, la compression de XML annule l'avantage de lisibilité humaine dont il dispose.
CSV est plus léger si vous voulez faire bouger les choses car il est normalement 2 fois plus petit que XML
XML est standard et ne sera pas touché par les différentes versions d'OS de CSV
XML fournit un moyen de baliser vos données avec des métadonnées (fournies par les noms de balise et les noms d'attribut), contrairement à CSV. Ajoutez à cela la possibilité de définir des hiérarchies structurées et cela rend XML plus facile à comprendre lorsqu'il est fourni uniquement avec les données, tandis que CSV nécessiterait un outil ou un document d'accompagnement pour décrire la façon dont chaque valeur est interprétée.
Vous pouvez facilement parcourir les données XML même lorsque vous avez des données complexes.
Vérifiez ces liens:
Structuré, lisible par l'homme, plus facile à éditer, validation, parsabilité, transformabilité, typage, espaces de noms, de puissantes bibliothèques derrière lui, sont toutes parmi les nombreuses raisons.
Mais surtout, c'est standard.
- Il existe des analyseurs et des émetteurs existants dans chaque langue et base de données
- Ils s'occupent de l'encodage pour moi
- Ils s'occupent de m'échapper
C'est tout ce qui m'importe.
Bien sûr, il existe un moyen semi-standard de s'échapper en CSV (c'est-à-dire "comme Excel le fait"), et ce n'est pas exactement difficile de vous écrire, mais cela prend du temps. Et puis vous devez implicitement vous mettre d'accord sur un codage de caractères hors bande. Mais ensuite, parce que c'est si simple, les gens essaient de l'écrire eux-mêmes, et invariablement bousillent # 2 ou # 3.
JSON rencontre également les # 2 et # 3 et se rapproche de la satisfaction # 1. C'est aussi sans doute plus simple, du moins pour les fichiers non documentaires. Sans surprise, je me retrouve à l'utiliser de plus en plus, en interne et en externe.
Et encore une fois pour XML: X en 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 joindre les deux langages XML de votre choix et les combiner dans le même document. Étant donné qu'il n'y a 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 cependant l'avantage de CSV: si vous avez vraiment des données tabulaires, la syntaxe XML est le plus souvent excessive.
J'ai également constaté que certains générateurs/analyseurs de cv ont beaucoup de difficulté avec les données de texte générales. Les longues chaînes de texte avec beaucoup de retours chariot et de virgules et de citations, etc., rendent la vie vraiment difficile quand il s'agit de manipuler un cv.
SSMS aime tronquer csv pour le plaisir.