Pourquoi une virgule est-elle un séparateur / séparateur d’enregistrements incorrects dans les fichiers CSV?

32

Je lisais cet article et je suis curieux de savoir comment répondre à cette question.

La seule chose qui me vienne à l’esprit, c’est peut-être que dans certains pays, le séparateur décimal est une virgule et que le partage de données au format CSV peut poser problème , mais je ne suis pas vraiment sûr de ma réponse.

project-management

— David Gasquez
source

6

Presque tous les délimiteurs sont meilleurs qu'une virgule. La raison en est que, lorsque des fichiers délimités par des virgules sont lus dans certains outils d’analyse de données, les virgules peuvent être confondues avec la ponctuation, ce qui perturbe la "disposition" des champs ou des colonnes.

— Mike Hunter

33

Un cynique, en notant que cet article est un feuilleton SAS, pourrait suggérer que SAS rencontre peut-être des problèmes pour traiter les fichiers CSV avec des virgules :-).

— whuber

3

@whuber - SAS (selon mon expérience) peut avoir des difficultés avec les fichiers CSV, qu'ils aient ou non une virgule, nécessitant une énorme quantité de codage manuel pour chaque chose étrange que SAS n'aime pas.

— Jeremy Miles

8

Il y a un désespoir dans la recherche de délimiteurs toujours plus obscurs - pipes, pilcrows, épines - qui suggère et entendent sur suivant une norme est vraiment le seul moyen sûr pour les personnes pour échanger des données dans des fichiers texte délimités. Et une norme universelle doit permettre à toute chaîne de texte d'être représentée (comme le fait la RFC4180), plutôt que de supposer que certaines n'auront pas besoin d'être et peuvent être affectées à un autre travail.

— Scortchi - Réintégrer Monica

2

(a) J'ai souvent importé des fichiers .csv avec succès. (b) Je conseille aux personnes de ne pas utiliser .csv si elles contiennent des virgules dans leurs données. Ceux-ci ne se contredisent pas. Il est regrettable que (b) ait besoin d'une explication de certains côtés.

— Nick Cox

33

La spécification du format CSV est définie dans la RFC 4180 . Cette spécification a été publiée parce que

il n'existe aucune spécification formelle permettant une grande variété d'interprétations de fichiers CSV

Malheureusement, depuis 2005 (date de publication du RFC), rien n'a changé. Nous avons toujours une grande variété d'implémentations. L'approche générale définie dans la RFC 4180 consiste à inclure des champs contenant des caractères tels que des virgules entre guillemets. Cette recommandation n'est toutefois pas toujours respectée par un logiciel différent.

Le problème est que, dans divers environnements linguistiques européens, la virgule sert de point décimal, vous écrivez donc à la 0,005place de 0.005. Cependant, dans d’autres cas, des virgules sont utilisées au lieu d’espaces pour signaler des groupes de chiffres, par exemple 4,000,000.00(voir ici ). Dans les deux cas, l’utilisation de virgules pourrait entraîner des erreurs lors de la lecture des données à partir de fichiers csv, car votre logiciel ne sait pas vraiment s’il 0,005, 0,1s’agit de deux nombres ou de quatre nombres différents (voir exemple ici ).

Enfin et surtout, si vous stockez du texte dans votre fichier de données, les virgules sont beaucoup plus courantes dans le texte que, par exemple, les points-virgules. Par conséquent, si votre texte n'est pas placé entre guillemets, ces données peuvent également être lues facilement avec des erreurs. .

Rien ne rend les virgules meilleures, ni les séparateurs de champs pires dans la mesure où les fichiers CSV sont utilisés conformément aux recommandations de la RFC 4180 qui protègent des problèmes décrits ci-dessus. Toutefois, si le format CSV simplifié risque de ne pas contenir de champs entre guillemets, ou si la recommandation peut être utilisée de manière incohérente, les autres séparateurs (le point-virgule, par exemple) semblent plus sûrs.

— Tim
source

6

Eh bien, tout logiciel mettant en œuvre la norme CSV telle que définie par la RFC 4180 saurait certainement interpréter exactement une chaîne donnée. L'argument selon lequel l'utilisation ,d'un séparateur plus rare gonfle les données parce que vous devez y échapper tout le temps est vrai. Et évidemment, il y a toutes ces personnes qui pensent savoir comment fonctionne le CSV, mais qui ne le savent pas vraiment.

— Voo

2

@Voo Oui, mais comme les fichiers "csv" sont utilisés de manière aussi chaotique, il est préférable de ne pas utiliser de virgule et d'utiliser à la place d'autres séparateurs, par exemple des points-virgules. Ceci est la réponse à la question OP. Il n'y a rien de "meilleur" dans les points-virgules (ou autres non-virgules) par rapport aux virgules, ils sont tout simplement un choix plus sûr dans de nombreux cas.

— Tim

2

@Voo +1 à votre commentaire. Cependant, quiconque utilise le format CSV ne s'intéresse pas vraiment aux fichiers de données gonflés!

— whuber

17

Techniquement, la virgule est aussi efficace que tout autre caractère à utiliser comme séparateur. Le nom du format indique directement que les valeurs sont séparées par des virgules (valeurs séparées par des virgules).

La description du format CSV utilise une virgule comme séparateur.

Tout champ contenant une virgule doit être double. Cela ne pose donc pas de problème pour la lecture des données. Voir le point 6 de la description :

Les champs contenant des sauts de ligne (CRLF), des guillemets doubles et des virgules doivent être placés entre guillemets.

Par exemple, les fonctions read.csvet write.csvde R par défaut utilisent une virgule comme séparateur.

— Djhurio
source

4

C’est la meilleure réponse, car il s’agit d’une valuesséparation par virgule. D'autres évoquent formattingdes chiffres européens , ce n'est pas un problème pour le CSV standard, comme vous le mentionnez correctement au point 6 ci-dessus. Les divergences par rapport à "l'utilisation correcte" existent avec tous les formats de données. Le fait est que vous connaissez vos données. D'autres mentionnent tabou ;délimités, mais ils peuvent avoir les mêmes problèmes que les virgules lorsque vous traitez avec des données saisies par l'utilisateur (peut-être via un formulaire et capturé par une base de données - j'ai dû me débattre avec des champs de saisie de texte libres ont gros doigts dans tab... ça craint)

— Adrian Torrie

La réponse de Tim a été modifiée pour inclure les informations fournies par @djhurio.

— Adrian Torrie

11

En plus d'être un séparateur de chiffres, il fait également partie de l'adresse (telle que l'adresse du client, etc.) dans de nombreux pays. Alors que certains pays ont des adresses courtes et bien définies, de nombreux autres ont des adresses longues, y compris parfois deux virgules dans la même ligne. Les bons fichiers CSV incluent toutes ces données entre guillemets. Mais des analyseurs syntaxiques trop simplistes et mal écrits ne permettent pas de lire et de différencier de telles personnes. (Ensuite, il y a le problème de l'utilisation de guillemets doubles dans les données, comme les citations d'un poème).

— Whirl Mind
source

2

(+1) La norme prévoit l’utilisation des guillemets dans les données en insistant pour les doubler à nouveau: "Belloc", "Tarantella", "" "les puces qui taquinent dans les Hautes Pyrénées" "". En Angleterre, il n'est pas rare de trouver des champs d'adresse contenant le nom d'une maison entre guillemets, par exemple: "Chatsworth", Melton Road, Leamington. (On ne sait pas pourquoi: Fowler a grommelé "l’implication semble être: vivre dans la maison que des gens raisonnables appellent" 164 Melton Road ", mais un imbécile aime appeler" Chatsworth "".)

— Scortchi - Rétablir Monica

1

@Scortchi Il semble que nous ayons appris les mêmes poèmes à l'âge de 12 ans (erreur +/-). Je crains que ce que je lis comme un malheureux snobisme anglais du début du 20ème siècle de la classe moyenne supérieure pour les habitudes de la classe moyenne inférieure obscurcisse votre dernier exemple, qui ne sera pas transparent au-delà d'un petit groupe.

— Nick Cox

@ NickCox: Douze sons à peu près correct. Drôle que je ne me souviens pas si je l' ai lu des poèmes cette année, et encore moins rappeler toutes les lignes de leur part . Bien que le point de vue de Fowler concernait l’effet sur le lecteur de guillemets inutiles (voir inutilequotes.com ), je pense que vous avez raison de voir l’influence du snobisme dans son choix d’exemple. Quoi qu’il en soit, j’espère que le point un peu mineur qu’il faut surveiller si l’envoi d’un fichier CSV contenant des adresses en anglais est clair pour tous malgré mes divagations.

— Scortchi - Réintégrer Monica

1

en Inde, il est courant pour les personnes qui construisent leurs premières maisons (et non leurs appartements) de conserver un nom fleuri novateur, souvent dans une langue vernaculaire ou une phrase sanscrite, qui sont placées entre guillemets, comme "Guru Kripa". Des noms comme Genelia D'Souza et Derek O'Brien sont également courants. Ensuite, les adresses portant le libellé "Ancienne porte n ° nnn / Nouvelle porte n ° mm / c", en raison de la nouvelle numérotation plus complexe du stockage des adresses compliqué par le gouvernement, pour avoir des slashs et des guillemets simples dans des coins inattendus.

— Whirl Mind

@WhirlMind: C'est intéressant - j'ai remarqué beaucoup - bien plus que je ne le pensais - des noms de maisons en gaélique écossais et gallois en Angleterre, ce qui est peut-être l'équivalent le plus proche du choix d'une langue vernaculaire pour nommer votre maison.

— Scortchi - Réintégrer Monica

9

Bien que la réponse de @ Tim soit correcte - j’aimerais ajouter que "csv" dans son ensemble n’a pas de standard commun - en particulier, les règles d’échappement ne sont pas définies du tout, ce qui conduit à des "formats" lisibles dans un programme, mais pas dans un autre. . Ceci est excarber par le fait que chaque "programmeur" sous le soleil pense simplement "oooh csv - je construirai mon propre analyseur!" et puis manque tous les cas de bord.

De plus, csv n'a absolument pas la capacité de stocker des métadonnées ni même le type de données d'une colonne, ce qui conduit à plusieurs documents que vous devez lire pour déchiffrer les données.

— Christian Sauer
source

5

Oui, il existe des outils standard. Ietf.org/html/rfc4180 et de nombreux autres formats ne stockent aucune métadonnée, il n'est tout simplement pas conçu pour stocker des métadonnées - les fichiers .txt ne stockent pas non plus de métadonnées concernant des documents texte ...

— Tim

4

Tim, cette norme est ignorée le plus souvent, ce qui en fait une non-standard ,,,

— Christian Sauer

8

La grande chose à propos des normes, c'est qu'il y a tellement de choix. (Varié muté et attribué.)

— Nick Cox

4

Si vous pouvez supprimer le séparateur de virgule et utiliser un caractère de tabulation, votre réussite sera bien meilleure. Vous pouvez laisser le fichier .CSV et importer dans la plupart des programmes ne pose généralement pas de problème. Spécifiez simplement une tabulation délimitée plutôt qu'une virgule lorsque vous importez votre fichier. S'il y a des virgules dans vos données, vous rencontrerez un problème lorsque vous spécifiez délimité par des virgules, comme vous le savez bien.

— Gorille
source

5

S'il y a des onglets dans vos données, l'inverse s'applique. Au moins selon mon expérience, c'est moins probable.

— Nick Cox

@ Nick et Gorilla: J'ai obtenu de bons résultats en |tant que délimiteur dans les fichiers texte d'enregistrements de type csv brassés à la maison (avec des titres de livre et d'autres métadonnées de document). |Cela ne se produit jamais dans les données avec lesquelles je travaille, je peux donc simplement écrire des scripts Perl qui se scindent / se joignent sans avoir à rechercher des citations d'aucune sorte. Il s'agissait d'un projet ponctuel qui impliquait simplement le traitement de métadonnées enregistrées à partir d'une base de données MS Access. Pour tout projet plus important, ou si vous prévoyez de conserver les données dans ce format de fichier à long terme, choisissez quelque chose de plus robuste! Je pourrais toujours modifier quelque chose si le lot de ce mois était cassé.

— Peter Cordes

@PeterCordes Je vous crois, et tout ce qui fonctionne. Mais il est clair que le coût des séparateurs idiosyncratiques peut être la nécessité d’expliquer ceux-ci à d’autres et il est essentiel qu’ils puissent importer ces fichiers de données sans difficulté. Face à un format de fichier inhabituel, il est nécessaire d’avoir accès à une routine, une fonction ou une commande pouvant fractionner des chaînes sur des séparateurs arbitraires.

— Nick Cox

@PeterCordes Quand j'ai écrit un split commande pour Stata, j'ai notamment consulté l'équivalent de Perl pour voir ce qu'il faisait et ce qu'il n'a pas fait. Pas le code source, juste la fonctionnalité offerte.

— Nick Cox

1

@ NickCox: Beaucoup de fonctions de Perl sont assez bien conçues, IMO. Ils font le travail sans beaucoup de limitations spéciales comme celles que vous trouvez dans awk (ce qui est souvent bon), ou plus particulièrement. d' autres outils Unix cut, sortet uniq.

— Peter Cordes

4

ASCII nous fournit quatre caractères "séparateurs", comme indiqué ci-dessous dans un extrait de la page de manuel ascii (7) * nix:

   Oct   Dec   Hex   Char
   ----------------------
   034   28    1C    FS  (file separator)
   035   29    1D    GS  (group separator)
   036   30    1E    RS  (record separator)
   037   31    1F    US  (unit separator)

Cette réponse donne un bon aperçu de leur utilisation prévue.

Bien sûr, ces codes de contrôle manquent de la convivialité humaine (lisibilité et entrée) des délimiteurs plus populaires, mais constituent des choix acceptables pour l'échange interne et / ou éphémère de données entre programmes.

— Ronald Straight
source

2

Intéressant. Je ne pense pas avoir jamais vu ceux-ci utilisés dans la nature ...

— Matt Krause

4

Le problème n'est pas la virgule; le problème cite. Quels que soient les délimiteurs d'enregistrement et de champ que vous utilisez, vous devez être prêt à les respecter dans le contenu. Donc, vous avez besoin d'un mécanisme de citation. ET ALORS vous avez besoin d’un moyen pour que le ou les caractère (s) citant (s) apparaissent également.

Suivre la norme RFC 4180 simplifie les choses pour tout le monde.

J'ai personnellement dû écrire un script pour probablement corriger la sortie d'un programme qui a mal tourné, alors je suis un peu militant à ce sujet. "probablement réparer" signifie que cela a fonctionné pour mes données, mais je peux voir des situations où cela échouerait. (Dans la défense de ce programme, il a été écrit avant la norme.)

— Stig Hemmer
source