desktop.ready a écrit 130 commentaires

Sinon tu as aussi pleins de convertisseurs CSV -> SQLite (en python aussi si tu veux).
Un gros CSV à manipuler c'est souvent pénible, alors qu'avec SQLite tu as une vraie mini base de données.

Un exemple simple: filtrer sur une valeur est instantanée si le champs est indexé alors qu'avec CSV il faut parcourir tout le fichier…

Ah non flûte je n'ai pas les pins P12 et P13 sur mon port eSATAp:
https://superuser.com/questions/435738/how-to-check-if-my-esatap-port-provides-12v-power

Donc ce sera du 5V aussi.

Intéressant comme hypothèse, c'est peut-être ça.
Je crois que j'ai un boîtier externe avec connection eSATAp: est-ce que l'on peut tester ton hypothèse avec ça ? Je ne sais pas si eSATAp sur un boîtier externe c'est la même chose qu'un SATA interne ?

Non j'ai deux boîtiers de PC identiques et deux disques durs identiques et pleins de câbles :-)
J'ai tenté toutes les combinaisons possibles et j'ai le même soucis quel que soit la combinaison.

La seule hypothèse que j'aie est que le design de l'alimentation du boîtier de PC n'est pas correcte (raison pour laquelle j'ai le même soucis quel que soit le boîtier).

Mais pour être sûr il faudrait que j'achète (encore) un nouveau boîtier de PC.

P.S.: j'ai déjà eu d'autres soucis avec d'autres modèles de disque durs, raison pour laquelle je pense que le problème n'est pas avec ce modèle particulier de disque dur.

Non le boîtier USB est ultra-simple et il n'y a aucun amorti.

Je pense que c'est à cause d'un problème d'alimentation, mais je n'ai trouvé personne ayant eu ce genre de problème avec un disque dur.

Peut-être que si l'alimentation n'est pas stable ou pas suffisante, cela provoque ce genre de phénomène ?
Pourtant c'est un disque 2.5", donc ça consomme vraiment pas beaucoup.

Sympa comme spécification du CSV !

Je me suis de nouveau penché sur la RFC 4180 qui traite du CSV et je me rends compte qu'il est indiqué que certains caractères sont interdit :

TEXTDATA = %x20-21 / %x23-2B / %x2D-7E
(also COMMA / CR / LF / 2DQUOTE if the field is quoted)

Donc en fait on ne peut même pas se reposer sur la RFC 4180 pour définir proprement le format CSV qui reste donc une sorte de convention floue.

Bon d'après cet article:
https://github.com/winestock/DNU

Il n'est pas possible de représenter des valeurs imbriquées en ASCII Delimited Text.

C'est vraiment bizarre du coup car je pensais que ce serait facilement possible avec le Group Separator.

Le CSV officiel ne permet pas de redéfinir la fin d'une ligne (pour utiliser ASCII 30 par exemple).

Par exemple la bibliothèque CSV de python ne permet donc pas de lire l'ASCII Delimited Text sauf à utiliser un gros hack affreux (voir le code que j'ai posté qui n'est pas de moi).

Franchement j'ai du mal à comprendre tes commentaires qui sont très théoriques et ou abstraits.

Pourquoi ne pas parler concrètement au lieu de rester sur des abstractions ?

Le besoin est clair, échanger un tableau de données comme indiqué ici (le dernier):
https://sebsauvage.net/wiki/doku.php?id=csv

Pour cela, je propose un format de données (cf. commentaire précédent) que je spécifie.
Oui je sais c'est beaucoup trop concis et je pourrais en écrire des tartines (attention à bien mettre une ligne d'en-têtes, utiliser du décimal et pas du binaire, le texte ne doit pas être converti en slovaque, etc.).

Est-ce que vous avez d'autres alternatives ?

Mais sinon on peut continuer à danser autour de la question et "prendre du recul pour évaluer le besoin dans sa globalité".

Ben écoute si tu veux bien y passer 3 minutes, je veux bien exemple de spec CSV qui tienne la route pour échanger un simple tableau comme celui-là:
https://sebsauvage.net/wiki/doku.php?id=csv
(hormis le coup des commentaires dans le fichier, là c'est un peu trop tarabiscoté)

Et spécial bonus si cela peut gérer les valeurs imbriquées :

123,"aa,bb,cc",456
456,"dd,ee,ff",789


Si la spécification est trop simple, les cas particuliers ne seront pas bien traités.
Si la spécification est trop compliquée, elle ne sera pas comprise et le fichier ne sera pas conforme.

Ma proposition est: le fichier doit être au format CSV avec encodage Unicode et utiliser ASCII 31 comme délimiteur et ASCII 30 comme "fin de ligne" (bon ça gère pas les valeurs imbriquées, peut-être que je peux utiliser ASCII 29 pour ça).
Donc si tu as mieux, je suis preneur.

Note: je suis conscient que à la fin ce n'est pas un format CSV au sens RFC 4180 à cause des fins de ligne, mais bon je n'ai pas trouvé comment spécifier de manière plus clair en aussi concis.

C'est comme SQLite: en théorie c'est très bien mais en pratique si tu tombes sur des gens pas très compétents, tu vas créer plus de problèmes qu'autre chose.

Mais sinon oui le HDF5 je connais et c'est pratique.

Oui parler de CSV c'est un abus de language, mais c'est plus facile pour faire passer le message.
Autrement je me retrouve à recopier 80% du format CSV pour expliquer l'ASCII Delimited Text.
D'ailleurs si j'ai bien compris, le module csv de python pourrait éventuellement plus tard permettre de redéfinir la fin de ligne (ce qui ne serait pas conforme au format CSV).

Oui pour la list comprehension, je pourrais sans doute sortir la boucle. De toute façon je vais être obligé pour pouvoir gérer les cas de valeurs imbriquées.

C'est un bon point et c'est effectivement un risque.
Après c'est comme de la programmation : difficile d'atteindre la perfection et souvent ce n'est pas souhaitable car pas "rentable".

Si tu as des gens compétents, tu utilises SQLite (ou autre format de données plus robuste).

Autrement c'est super difficile de spécifier le format CSV de manière sûre et facilement compréhensible par quelqu'un de pas forcément très compétent.

Oui ça c'est suffisant si tu as un fichier "plat" mais j'ai l'impression que si tu as une valeur qui contient en fait d'autres valeurs, il faut utiliser le GS mais je n'ai pas réussi à confirmer.

L'ASCII Delimited Text c'est comme du CSV en changeant la notion de fin de ligne.
C'est pour cela que j'ai utilisé le module CSV en changeant… la notion de fin de ligne ! Surprenant non ?

Le module csv de Python ne permet pas de redéfinir les fins de ligne, c'est pour cela que l'on passe par le hack du readlines.

Pour la list comprehension, c'est une optimisation à deux sous j'en conviens. J'ai cru lire quelque part qu'une boucle dans une list comprehension est plus rapide qu'une boucle sans. Ce n'est peut-être plus valable avec les dernières versions de Python.

Ben la quasi totalité de tes questions n'a rien à voir avec le format du fichier.

Moi je parle d'une approche qui pourrait résoudre cet aspect en particulier et toi tu me parles de tout à fait autre chose.
C'est comme si je comparais Access à PosgreSQL et que tu me disais "oui mais tu n'as pas spécifié que l'heure était en UTC".
Ou comme si je présentais un nouveau langage de programmation et que tu me disais "oui mais ton algo est correct ?"
Euh… oui Captain Obvious ?

L'ASCII Delimited Text ça permet de résoudre une problématique, pas de résoudre magiquement la faim dans le monde.

Ben si justement, si tu spécifies le format CSV avec texte en Unicode, ASCII 31 comme délimiteur et ASCII 30 comme "fin de ligne" tu dois bien éviter 95% des problèmes (au doigt mouillé).

Alors que si tu commences à décrire comment formater proprement un CSV avec la virgule comme délimiteur, tu n'es pas couché.

Donc pour un investissement vraiment minimum, tu t'épargnes beaucoup de soucis.

Typiquement:

1. On doit exporter des données d'un système A pour l'importer dans un système B.
2. Une entreprise alpha est chargée d'exporter les données et une autre beta est chargée de l'importer.
3. Le Cahier des Charges pour l'export de données est développée à "la rache"™ et ne mentionne que CSV comme format de données
4. L'entreprise alpha livre son fichier CSV mal formaté (au point où il est impossible de reconstituer les données d'origine)
5. L'entreprise beta râle et on se retrouve en litige sur le Cahier des Charges

Je me rends compte que mon parseur naïf ne doit pas marcher dans tous les cas.

Par exemple j'ai déjà eu des fichiers CSV imbriqués, dans le sens où une valeur peut représenter plusieurs valeurs:

123,"aa,bb,cc",456
456,"dd,ee,ff",789


Ça c'était vraiment une plaie à gérer proprement.

Je n'ai pas bien compris comment formater tel fichier avec le "ASCII Delimited Text" avec ces 4 types de délimiteurs:
* FS: file separator
* GS: group separator
* RS: record separator
* US: unit separator

S'il y avait un expert qui pourrait m'éclairer…

Oui ce serait l'idéal.
En pratique on tombe toujours sur le plus petit dénominateur commun: CSV.

Excel c'est pareil que le CSV: c'est facile de faire des erreurs si on ne fait pas attention.

Exemple: tu souhaites importer un fichier CSV (bien formaté !) et cet imbécile d'Excel fait tout pour interpréter les valeurs "pour te simplifier la vie" et du coup ton magnifique user ID "00123" se transforme automatiquement en "123".

Convertir Excel dans un autre format de données, c'est la plaie. Ce qui rend le format Excel impropre à l'échange de données.

Oui exactement. Le problème avec le CSV c'est que cela paraît super simple à priori.
Mais en fait le format est tellement mal spécifié que tu as pleins de cas particuliers.
Combien on lu la RFC 4180 et l'on comprise ?

C'est un peu comme gérer les noms de personnes : la plupart des gens pensent que un champs nom et un champs prénom et c'est plié.
https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/

Le problème c'est surtout que c'est facile de croire que l'on maîtrise le CSV alors que c'est facile de se planter.
Du coup tu te retrouves avec des cahiers de charge écrit vite fait bien fait, avec genre "et la livraison devra être faite en CSV".
Si tu as de la chance, il sera peut-être précisé le caractère de délimitation et c'est tout.

programme-tv.net:
- 27 ad tracker
- 74 third party cookies
- This website could be monitoring your keystrokes and mouse clicks.
- When you visit this site, it tells Facebook.
- This site allows Google Analytics to follow you across the internet.
- 16 Partenaires (dont Criteo !)

Salut,

J'ai testé avec deux boîtiers différents et deux alimentations différentes.
De plus les boîtiers marchent très bien avec d'autres disques durs 2.5" (seagate, western digital…).

Je n'ai pas souhaité tester plus en avant et j'ai retourné les disques…