Du Excel-engineering dans tout sa splendeur:
Excel: Why using Microsoft's tool caused Covid-19 results to be lost
Mais je suis aussi à blâmer: j'ai souvent utilisé Excel ou CSV pour échanger des données alors que je sais pertinemment que c'est mal.
Je ne compte pas les soucis que j'ai eu à cause d'un mauvais formatage de fichiers CSV (texte non quoté, retour à la ligne dans les valeurs, texte avec guillemets, etc.). Ou encore Excel qui persiste à interpréter "00123" comme "123".
Je me suis donc enfin décider à chercher une alternative.
Après avoir jeté oeil sur DIF et SYLK, je suis tombé sur ASCII Delimited Text:
Text File formats – ASCII Delimited Text – Not CSV or TAB delimited text
Le gros soucis c'est que ce format n'est supporté par personne. Même vim ou emacs l'affiche bizarrement. Celui qui s'en sort le mieux out-of-the-box est Notepad++.
Mais bon dans l'idée on n'édite pas un tel fichier à la main, donc ce n'est pas grave.
Je me suis donc inspiré d'un bout de code pour proposer un convertisseur de "ASCII Delimited Text" en Excel.
C'est très moche je trouve mais je n'ai pas réussi à faire plus simple (si quelqu'un arrive à faire plus simple, défi TapTempo !).
from openpyxl import Workbook
import csv, argparse
def readlines(f, newline='\n'):
while True:
line = []
while True:
ch = f.read(1)
if ch == '': # end of file?
return
elif ch == newline: # end of line?
line.append('\n')
break
line.append(ch)
yield ''.join(line)
def process(input, output):
wb = Workbook(write_only=True)
ws = wb.create_sheet()
with open(input, 'r', encoding='utf-8') as f:
reader = csv.reader(readlines(f, newline=chr(30)), delimiter=chr(31))
[ws.append(row) for i,row in enumerate(reader)]
wb.save(output)
if __name__ == '__main__':
parser = argparse.ArgumentParser(description='convert to xlsx')
parser.add_argument('input', help='csv file')
parser.add_argument('output', help='xlsx file')
args = parser.parse_args()
process(args.input, args.output)Et vous de votre côté ? Vous utilisez quoi pour échanger des données ? SQLite ?
Note: impossible de mettre un exemple de "ASCII Delimited Text", même linuxfr n'est pas compatible :-(
# JSON? YAML?
Posté par Gawan . Évalué à 4.
Si cela doit être lu ou modifié par un humain YAML.
Sinon JSON est aussi un candidat valable.
[^] # Re: JSON? YAML?’
Posté par groumly . Évalué à 10.
JSON/xml/autres languages a balises sont plutôt mauvais pour le transfert de données brutes à large échelle.
CSV, c’est une ligne une donnée, donc trivial a streamer, le parseur est très simple à écrire, ça se parallélise très bien, tu sais combien de données t’es censé avoir d’entree de jeu, trivial de se rappeler ou tu t’es arrêté. Tout ça est très avantageux quand il s’agit de faire un dump d’une db et le réimporter dans une autre.
xml et json ont généralement des parseurs en stream, mais plus durs à utiliser, et ils ont aussi beaucoup plus d’overhead (noms des champs répétés à chaque entrée).
Le gros intérêt de json c’est qu’il mappe directement a des objets (le o de json), et est super flexible niveau schéma. Ces 2 points n’ont que peu d’intérêt si tu veux charger 10 000 lignes dans une base de données (ou dans Excel).
Bref, pour faire de l’échange de données dans le cas cité, csv reste le plus simple et pratique.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: JSON? YAML?’
Posté par stopspam . Évalué à 4.
C'est bien résumé et j'en ai le même retour.
Pour petit volume, simple ou complexe je privilégie json (typiquement des fichiers de conf, ou de l'échange simple).
Quand je dois interfacer 2 logiciels via des imports/exports et des donnees en masses, il n'y a pas mieux que CSV
[^] # Re: JSON? YAML?’
Posté par groumly . Évalué à 7.
pour la conf, json a le gros désavantage que l'ordre des clés n'est pas spécifié par le standard. Ca depend de la librairie que tu utilises, qui va très probablement être l'ordre des hash du dictionnaire.
Si ta conf est uniquement écrite par un humain, c'est pas un problème.
Si ta conf peut être générée/modifiée par une machine, ca va te créer des diffs très durs a lire.
XML n'a pas ce problème, l'ordre des elements doit être conservé entre une lecture et une écriture.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Exactement, par exemple quand j’ai vu certains répondre que conserver l’ordre du dictionnaire est inutile “par principe” parce que forcément, par principe il n’y aurait aucun besoin pour cela… J’ai immédiatement pensé que ces personnes ne savaient pas vraiment ce que c’était de stocker des fichiers dans un dépôt (git ou autre chose).
Il est très important de pouvoir conserver l’ordre des données, ou de déterminer cet ordre, même si cet ordre n’a aucune sémantique pour les données elle-même. C’est important parce qu’il devient alors très aisé de versionner. Au delà de fichier de paramétrages dans git, va versionner un csv de millier de lignes si elles sont mélangées… alors que si l’ordre est conservé, un simple outil générique comme
diffte sortira les différences en un temps record. Idem avec json, xml et je sais pas quoi.La possibilité de conserver l’ordre est importante. J’ai remarqué que j’utilisais énormément
OrderedDictdans Python, et quand il s’agit de traiter des données extérieures (pas des dictionnaires intégrés au code), j’ai remarqué que j’utiliseOrderedDictde manière écrasante, par nécessité.C’est d’ailleurs pourquoi par exemple quand je traite du TOML en python, j’utilise pytoml au lieu de python-toml. Je ne sais pas où ça en est maintenant, mais quand j’ai commencé à travailler sur Urcheon (un outil pour construire des dépôts de données, en gros un CMake mais pour des images, du son et des modèles 3D), seul pytoml permettait de spécifier le type de dictionnaire et donc de sortir un fichier de configuration qui conservait l’ordre de l’entrée, ou encore… très important dans ce cas, de traiter les opérations dans l’ordre de l’entrée… Je lis maintenant que pytoml est déprécié et recommand python-toml, il faudra que je réévalue python-toml et voir s’ils ont enfin implémenté la possibilité de forcer le constructeur de dictionnaire…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par groumly . Évalué à 9.
Pour etre tout a fait honnête, ca depend beaucoup du context. Je crois surtout que nombreux sont ceux qui ignore/oublient ce que les initiales de JSON veulent dire. JavaScript Object Notation. C'est dur d'être plus clair.
Tant que tu gardes ca a l'esprit, et que tu connais un peu javascript, ca explique beaucoup de choses:
{"a":2, "b":3}est égal a l'objet représenté par{"b":3, "a": 2}. On peut ergoter des jours sur la sémantique, mais si tu replaces ca dans le contexte, le comportement actuel se tientLinuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Une chose est de ne pas prendre en compte une fonctionnalité dont on a pas besoin lorsqu’on conçoit un outil pour un besoin très spécifique, une autre chose est d’empêcher que cet outil puisse servir à wat mille autres besoins en refusant que soit implémenté un comportement optionnel qui n’a aucun impact sur le design et le fonctionnement initial et le besoin très spécifique de départ.
Si
{"a":2, "b":3}est égal à{"b":3, "a": 2}dans le besoin initial, ça ne casse rien de permettre de produire{"b":3, "a": 2}dès le départ pour ceux qui ont ce besoin indépendamment des besoins pour lequel JSON a été conçu. L’outil qui testera l’égalité n’a pas besoin d’être modifié, à aucun moment. Ça ouvre des perspectives, mais ça ne casse rien, ça ne modifie pas le format, la compatibilité est totale…La question n’est pas que le comportement se tienne dans son contexte de départ, mais qu’une opportunité qui n’a aucun impact sur le contexte de départ ne soit pas permise, quand la demande est simple, bien expliquée, et facilement justifiable, et que le coût est mineur (et totalement absent pour le contexte de départ).
Par exemple avec pytoml, tu peux décider du constructeur de dictionnaire:
{}ouOrderedDict(). Ça n’a aucun impact sur le format. Aucun outil tiers pytoml n’a à être modifié.Puisque justement JSON est conçu pour fonctionner indépendamment de l’ordre, ordonner des données JSON n’a aucun impact sur son fonctionnement. On peut dire que JSON est précisément conçu pour ne pas être affecté par le fait que les données soient ordonnées. Donc quelqu’un qui produit des données ordonnées et veut parser ces données peut choisir JSON : JSON lui garantit déjà que les données sont correctement parsées bien qu’elles soient ordonnées. Alors, vraiment, rien ne justifie de s’opposer à la reproductibilité optionnelle de l’ordre des données dans la production de fichier JSON.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par groumly . Évalué à 5.
Je comprends pas ton commentaire.
La spec json n’interdît pas de trier les clés de façon déterministe, ni de conserver l’ordre des clés entre une lecture et une écriture. J’utilise des outils qui font précisément ça.
C’est juste que la spec ne l’impose pas, c’est inutile dans beaucoup de cas d’utilisation, c’est du boulot et des problèmes de perfs de le faire, donc beaucoup de librairies ne le font pas.
Jackson le supporte. C’est une config opt-in, mais il offre la possibilité de trier les clés comme tu veux.
Soit dit en passant, je doute que le coût soit mineur pour un serveur d’appli qui passe sont temps à serializer du json.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel) . Évalué à 8. Dernière modification le 08 octobre 2020 à 21:37.
Ce qui doit te manquer pour comprendre mon commentaire est qu’il y a eu toute une polémique sur le fait que sur la base de ce que la spécification JSON définit un objet comme “an unordered set of name/value pairs”, certains développeurs significatifs de bibliothèque JSON qui faisait référence refusaient catégoriquement et ce pendant de très longues années de considérer l’implémentation optionnelle de la conservation de l’ordre, et c’était une forme d’obstruction puisque c’était une opposition par principe au concept même, et pas simplement un argument du genre « faites-le vous-même, moi je ne perdrai pas de temps là-dessus ». Ça a été un sérieux obstacle au choix d’utiliser le format JSON ou au choix d’utiliser telle bibliothèque qui fait référence. Personnellement j’ai fait face au problème quand j’ai eu besoin de stocker dans des dépôts versionnés des données générées par des outils que j’écrivais. C’est pour ça qu’historiquement mes outils ne génèrent pas du JSON. Je ne sais pas où ça en est, je pourrai reconsidérer la chose. Tout ça est loin dans mes souvenirs je ne sais pas comment retrouver de lien sur le sujet, mais toujours est-il que mes outils en gardent la trace et que ça a donc marqué durablement mes projets et que tant que ces projets vivront, ils témoigneront de ces temps troublés par une cicatrice toujours visible.
Un tel argumentaire suppose que le JSON généré par un logiciel est immédiatement lu par un autre logiciel, et que puisque le second logiciel ne doit pas supposer d’ordre pour fonctionner, le besoin d’implémenter un ordre à la génération du json serait en fait le témoin d’un problème de conception dans le logiciel qui parse.
Mais ça c’est un cas typique de courte-vue et d’assomption fausse sur le fait que les gens n’auront que ce besoin et strictement que ce besoin. Dans la vraie vie les gens développent des tas de besoins dont certains sont tout à fait honorables, comme le fait de stocker des données sérialisées dans un dépôt versionné.
Ce qui est amusant c’est qu’avec la spécification Vulkan est fournit un fichier JSON qui est utilisé pour faire de la validation. Comme toute spécification versionnée, c’est typiquement le genre de fichier qu’on peut vouloir stocker dans un dépôt versionné, et bien que la spécification JSON permette le désordre, conserver l’ordre simplifie vraiment les choses pour les gens, par pour l’outil de validation qui n’en a rien à faire de l’ordre, mais pour les gens, typiquement pour comparer deux commits tu n’aurais pas besoin d’outil dédié. N’en déplaise à ceux qui se cachent derrière la spécification de JSON elle-même pour supposer que ce besoin n’existe pas.
Exactement, c’est pour cela que faire de l’obstruction sur un besoin qui ne contredit pas la spécification est… surprenant.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par barmic 🦦 . Évalué à 4.
Pas du tout. Il te permet d'utiliser que tu souhaite, même si ce n'est pas un ordre alphabétique tout en te garantissant que ça n'en change pas la sémantique.
Si l'outil de diff utilisé par ton gestionnaire de version te pose problème c'est un autre débat qui peut avoir diverse solution. Le besoin de versionné du json n'est qu'une part très faible de l'usage de json parce que son usage dans l'exécution javascript et en rest le dépasse amplement.
Il faut savoir que maintenir un ordre dans les clefs est réellement quelque chose de couteux et ne répond qu'en partie à la problématique du diff. Faire un formattage précommit ou avoir un outil de diff qui comprend json sera une solution plus complète (ça permet entre autre de gérer les divers indentation non signifiantes).
C'est le même genre d'argument qui pousse à autoriser les virgules trailling pour faire des documents de la forme :
Parce que tu comprend si ajouter un troisième champ fait un diff d'une ligne en plus c'est pas bien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: JSON? YAML?’
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 09 octobre 2020 à 10:37.
J'ai pas compris votre délire avec l'ordre et les diff. C'est pas parce que JSON est lisible par des êtres humains qu'il est fait pour être comparé d'une version à l'autre de façon brute. Si tu veux de l'ordre, tu fais comme mongodb, des documents qui sont des objets json mais qui ont une numéro d'index. Je ne vois pas comment, et pourquoi JSON devrait gérer l'ordre des objets qu'il contient, ce n'est pas vraiment le rôle d'un format de s'assurer qu'un ordre est respecté, c'est du domaine de l'appli puisque n'importe quelle application peut toujours décider de foutre la graille là-dedans.
[^] # Re: JSON? YAML?’
Posté par groumly . Évalué à 3.
Utilise un autre librairie?
Je comprends que ca soit ennuyant, mais comme dit dans ce thread, c'est loin d'être simple a implementer. Et meme en mode optionnel, ca a un impact certain sur la maintenance du code en question.
J'ai honnêtement aucune idée de quelle librairie du parle, mais s'ils se focalisaient sur l'usage primaire du json, a savoir l'échange d'objet entre machines, c'est me parait pas délirant de refuser ce genre de choses.
D'ou mon commentaire original, disant que JSON est mal adapté a ce scenario.
Et c'est pas juste ajouter le tri des clés, si tu veux que ca soit utile pour un format de stockage, il faut implementer un truc a la xml, ou l'ordre initial est conservé (peut importe l'ordre original), et qui maintient aussi les whitespaces.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: JSON? YAML?’
Posté par flan (site web personnel) . Évalué à 5.
(Maintenant, OrderedDict n'a plus d'intérêt vu que l'ordre est préservé par l'implémentation actuelle de dict).
[^] # Re: JSON? YAML?’
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 10.
Et justement, c'est faux: faire soi-même un parseur CSV est une très mauvaise idée et c'est compliqué.
Tu viens de tomber exactement dans un des pièges que Seb cite sur son wiki.
[^] # Re: JSON? YAML?’
Posté par desktop.ready . Évalué à 10.
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/
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Ah oui, ça aussi… Tu connais Marcus Tullius ? Il est plus connu sous le nom de… « Cicéron ».
En fait, « Cicéron » est un surnom. Les romains avaient en gros un prénom, un nom de famille, et un surnom, le surnom pouvant être hérité, c’est un surnom de famille… « César » et « Auguste » font partie de ces surnoms célèbres, que l’on peut associer pour plus de swag : César Auguste, ça en jette !!!
Ah, et il y a aussi les cultures qui forment le nom de famille par le prénom du père. En gros, si tu as Martin qui a un fils qui s’appelle Jean qui a un fils qui s’appelle Michel, Jean s’appelle Jean Martinfils, et Michel s’appelle Michel Jeanfils (les personnes d’origine nordique avec des patronymes françisés en machin-son, c’est ça). Quelqu’un de cette culture pourrait typiquement penser que demander le prénom de la personne et le prénom de son père serait suffisant, sans demander de nom de famille du tout puisque ça n’existe pas, non ?
Ah au fait, pour revenir au surnom, Cicéron c’est pour « pois chiche ». Oui, le grand Cicéron était surnommé « pois chiche », je crois que c’était hérité en fait.
Bref, quand on appelle le roi « Louis le gros », son surnom fait véritablement partie de son identité…
Et quand on écrit en 2020 : Thomas “illwieckz” Debesse, on n’est pas très original en fait…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par Obsidian . Évalué à 6. Dernière modification le 07 octobre 2020 à 02:09.
En gros, Cicéron, c'est pas carré, quoi.
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel) . Évalué à 8.
Cicéron c’est Poincarré, ou pas…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par damaki . Évalué à 6.
+1
Le CSV n'est pas un standard mais un ensemble de vagues conventions. C'est un cauchemar de gérer du CSV provenant de plusieurs sources différentes dans la même appli, et pire si ces sources sont des humains.
[^] # Re: JSON? YAML?’
Posté par freem . Évalué à 4.
Bah… je vois pas le problème. J'utilise un DSL qui sert à écrire des parseurs, genre flex+bison ou coco ou peu importe, j'écrit mon parseur dans un language qui lui est fait pour ça, et ça route, ma poule :)
Ah, oui, le problème, c'est qu'il faut souvent apprendre (si ne n'est pas tout le temps) la notation BNF et ses dérivées, mais d'un autre côté, quand on veux spécifier un format ou un langage de manière carrée, je pense que c'est juste difficile de faire autrement. Sauf si, bien sûr, on se contrefout de faire un code propre.
Le cadeau bonus, c'est qu'il est simple d'écrire une spec à partir des DSL en question: il suffit, en gros, de virer la partie génération de code associée aux grammaires et jetons, parce qu'en vrai, une fois qu'on vire ça, on a une spec dans un des langages qui sont d'ailleurs utilisés dans pas mal de RFC, et d'ajouter quelques phrases dans la langue humaine de son choix.
Bon en vrai, je suis entièrement d'accord avec toi, mais personnellement, j'élargirais juste à "écrire un parseur, c'est compliqué, plus que ça en a l'air si on veut faire un truc correct".
[^] # Re: JSON? YAML?’
Posté par barmic 🦦 . Évalué à 3.
Tu entends quoi par données brutes ?
C'est quoi ce que tu appel large échelle ?
Non ? Une ligne n'est pas forcément une donnée complète. Le parseur est très simple à écrire effectivement (tu lis caractère par caractère et tu maintiens une pile d'état pour gérer les niveaux de protection), mais ça ne se parallélise pas vraiment. Tu es obligé d'avoir déterminé la fin de la donnée précédente pour savoir commence la suivante.
Je sais pas ce que tu as voulu dire ?
Ça c'est vrai, tu prends l'offset du début de la dernière donnée que tu as lu.
Bof beaucoup évitent je pense que csv est un format trop simple :
Je pense que c'est pour ça par exemple qu'on voit des exports sous forme de requêtes SQL, c'est vachement plus simple puisque c'est un format qu'ils connaissent déjà, qui a donc tout ce dont ils ont besoin, qui va permettre de gérer des trucs impossibles avec csv (la création d’index, le commit de la transaction,…). J'ai l'impression que les bidouilles csv est plutôt fais par des outils tiers.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: JSON? YAML?’
Posté par woffer 🐧 . Évalué à 3.
Pour streamer du JSON like, tu peux utiliser du JSONL, c'est très pratique pour échanger des données entre back-end car facilement streamable. Si la performance est vraiment problématique pour les échanges entre back-end, tu peux te tourner vers des formats binaires avec schéma (protobuf, … ) ou sans schéma (msgpack, …).
# Il est où le problème dans le CSV ?
Posté par MrBidon . Évalué à 10. Dernière modification le 06 octobre 2020 à 17:44.
Si les données sont en colonnes, je ne vois vraiment pas où est le soucis : c'est ouvert, simple et très light (pas besoin de répéter le nom du champ). Après si la personne qui le manipule ne maitrise pas son outil c'est pas le soucis du format.
[^] # Re: Il est où le problème dans le CSV ?
Posté par Eh_Dis_Mwan . Évalué à 2.
C'est surtout , dans le cas présent, un problème d'importance de données:
j'ai toujours eu des soucis pour ouvrir des fichiers csv (ou texte, c'est kla même chose pour le coup) de plus de 1 GiO.
Après oui , le format csv est très plaisant, et on peu vraiment tout faire s'il est bien formaté : l'importer dans une base est un jeu d'enfant avec dbeaver par exemple (je crois aussi que mysql peux le faire directement).
[^] # Re: Il est où le problème dans le CSV ?
Posté par freem . Évalué à 5.
Peut-être une question d'outil? Ton outil, il ouvre le fichier et lit caractère par caractère, avec un
fread(ou du même genre) à chaque fois? Ou il utilisemmap, ce qui permets de jouer avec les données comme si elles étaient en mémoire et donc réduit le nombre de syscalls nécessaire pour accéder à une donnée, en laissant le noyal fair boulot de gestion des accès aux ressources?S'il utilise mmap, dans ce cas c'est probablement la même merde pout n'importe quel format texte: il faut toujours parser, on peut pas pas paralléliser pépère. Sauf si le format indique la taille en octets ou en caractères des champs, à la rigueur, mais ni xml ni json ne font ça. C'est plutôt les formats binaires qui font ça, mais je crois que c'est passé de mode… (enfin perso, si je dois bricoler un truc réseau, je préfère utiliser un format binaire, je trouve ça bien plus simple a implémenter)
[^] # Re: Il est où le problème dans le CSV ?
Posté par AlexTérieur . Évalué à 2.
Je suis confronté régulièrement au CSV, et effectivement, c'est simple à gérer, mais suivant deux conditions :
- l'opérateur sait ce qu'il fait
- le logiciel gère correctement tous les cas possibles du CSV
N'ayant pas l'expérience de tous les logiciels connus gérant le CSV, je me réfère donc… à une variable non maîtrisée.
[^] # Re: Il est où le problème dans le CSV ?
Posté par feth . Évalué à 4.
La plupart d'entre nous a tout de suite aimé CSV pour sa simplicité et sa flexibilité.
Et pourtant, la première partie des caractères est composée de caractères de contrôle dont plusieurs servent précisément à structurer des données : séparateur de champ, séparateur d'enregistrement… pourquoi ne pas s'en servir ? Parce que c'est vieux ?
[^] # Re: Il est où le problème dans le CSV ?
Posté par chimrod (site web personnel) . Évalué à 7.
Le problème du CSV, est qu'il donne l'impression de pouvoir être parsé simplement comme une chaîne de texte. Pourtant, si l'on tient compte :
on se retrouve vite avec qqch de trop complexe pour être traité avec juste
cut. Je pense que mêmeawkne doit pas permettre de traiter un csv de façon fiable.Désormais, je le traite comme un fichier binaire, en utilisant une librairie dédiée dans un langage lourd, et ça se passe beaucoup mieux comme ça :)
[^] # Re: Il est où le problème dans le CSV ?
Posté par desktop.ready . Évalué à 7.
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.
[^] # Re: Il est où le problème dans le CSV ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 10.
"Si les données sont en colonnes, je ne vois vraiment pas où est le soucis"
Quand tu auras eu un traitement qui part en carafe un vendredi soir parce que "le métier" aura envoyé un "CSV" qui, au choix :
- Viendra de la filiale de Singapour
- Contiendra des "caractères interdits" dans le système cible
- Aura été édité sur un système très très vieux au nom bizarre (e.g. Chauvounix IV)
- Aura été exporté en UTF-16 sans BOM par un apprenti DBA de Bengalore pour dépanner
- Aura été copié collé depuis le corps d'un mail par un DAF
- Insérer ici une expérience rigolote
Tu viendras mettre un commentaire ici précisant : "Ca y est, je vois où est le souci !"
[^] # Re: Il est où le problème dans le CSV ?
Posté par MrBidon . Évalué à 1. Dernière modification le 07 octobre 2020 à 11:08.
J'en ai souvent et ça ne pose pas de soucis : car ça ne plante que le traitement du csv pas le reste.
[^] # Re: Il est où le problème dans le CSV ?
Posté par Buf (Mastodon) . Évalué à 4.
Il y a un très gros risque d'insérer des données pourries sans s'en rendre compte immédiatement, et c'est ensuite la misère à corriger.
Le CSV, c'est la fausse bonne idée par excellence, le truc qui a l'air simple mais qui ne l'est pas du tout dès qu'on tombe sur un cas non prévu initialement.
[^] # Re: Il est où le problème dans le CSV ?
Posté par MrBidon . Évalué à 3. Dernière modification le 08 octobre 2020 à 23:25.
Comme d'hab tout dépend du cas d'utilisation du traitement du fichier…
[^] # Re: Il est où le problème dans le CSV ?
Posté par fearan . Évalué à 5. Dernière modification le 07 octobre 2020 à 11:08.
Bof tu as le même genre de soucis quel que soit le format d'échange utilisé
Sur du bête XML, envoyé sur du VMS par on s'est retrouvé avec un fichier invalide, car les fichiers textes n'ont pas plus de n caractère par lignes, donc le système en rajoutait tout seul comme un grand.
T'as déjà un un gros malin qui a voulu mettre des caractère & dans un xml sans faire gaffe ?
Et le xml copié collé comme un goret qui fait que son encodage n'est pas conforme à la déclaration ?
Tu auras des soucis quel que soit le format d'échange de fichier; si tu ne normalise pas les données et la façon de les générer tôt ou tard un gland va produire une forêt d'emmerdes. Parfois tu va avoir une erreur à la lecture qui va t'éviter de chercher très loin la source, d'autre fois non, comme l'extension multimple d'un & qui devient & oui le amp; deux fois n'est pas une faute de frappe,
La seul façon d'éviter des soucis c'est que ton format d'échange ne soit pas éditable par un humain, avec une signature du fichier pour être certain que ça a bien été produit informatiquement (et encore).
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Use the standards Luke !
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 6.
Ça dépend du type d'échange dont j'ai besoin (M2M/U2U, B2B/A2A, etc) et du client chez qui j'interviens (aéro, auto, pétrole). Si j'ai le choix, j'utilises ebXML (ou XML) pour emmerder les dinos qui veulent du CSV et les hipsters qui veulent du JSON.
# excel c'est mal
Posté par Anonyme . Évalué à 4.
J'avais vu un connecteur excel qui permet de taquiner directement la base de données Ce qui coupe la poire en deux, mais personne ne veut se former dessus par chez moi. Il faut donner des droits a plus de monde aussi.
mais pour les échange inter-entreprise, ca dépend du niveau de celui qui est en face, si il a WSL d'installer tu peux le faire en sqlite ou nosql. J'en ai parlé qq fois mais j'ai pas eu le succés :) escomté.
mais comme toujours cela dépends du volume des données à échanger.
[^] # Re: excel c'est mal
Posté par Papey . Évalué à 1.
SQLite peut s'utiliser sans problème sous Windaube avec des outils comme SQLiteStudio ou DB Brower for SQLite.
Sans parler de python qui embarque la bibliothèque SQLite en natif.
[^] # Re: excel c'est mal
Posté par freem . Évalué à -1. Dernière modification le 07 octobre 2020 à 20:41.
Est-tu sûr qu'un fichier sqlite généré sous Windaube sera lisible sur n'importe quel Lisux peu importe le hardware en dessous? Pas de risque de confondre un Sioux avec un Cherokee?
(je sens que je vais me marrer)
[^] # Re: excel c'est mal
Posté par Papey . Évalué à 9.
Tu vas certainement te marrer tout seul parce que je n'ai pas compris ce que tu voulais dire.
Dans le doute, je réponds au point que j'ai à peu près compris même si on sentait une bonne dose d'ironie : un fichier SQLite est compatible toutes architectures, quelle que soit l'endianness, quels que soient l'encodage par défaut, le caractère de fin de ligne du système etc… Après ça ne veut pas dire qu'il ne faut pas définir le format de ses données dans tous les cas, et ça n'empêche pas de devoir faire un minimum de tests de qualité à la réception du fichier, mais ça élimine un certain nombre de problèmes posés par les fichiers texte en tout cas.
[^] # Re: excel c'est mal
Posté par freem . Évalué à 4.
Ce qui,du coup, casse mon point de rire, méheu… Bah, au moins, quelqu'un aura explicité le truc donc même si moi j'y perds par fierté (lol) ceux qui liront ta réponse apprendront.
En vrai, j'ai appris peu après que sqlite est endian-agnostique, donc que je me suis planté sur toute la ligne! J'assume, j'ai,une fois de plus, écris de la merde.
[^] # Re: excel c'est mal
Posté par freem . Évalué à 6.
Parce que le problème, il vient clairement pas des gens qui utilisent excel ou un tableur pour stocker des millions d'enregistrements? Qui utilisent des outils sans en comprendre le rôle et les limitations?
[^] # Re: excel c'est mal
Posté par barmic 🦦 . Évalué à 8.
Tout le monde ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: excel c'est mal
Posté par freem . Évalué à 3.
Pour un outil critique a son activité?
Je suis débile de chercher a maîtriser ce que je fais et comment je le fais?
Et de toute façon, si on utilise le mauvais outil pour une tâche, est-ce normal d'accuser l'outil de ne pas être fait pour, ou d'avoir des limitations dans un usage non prévu?
[^] # Re: excel c'est mal
Posté par groumly . Évalué à 1.
Je pense que tu sous estime très largement la robustesse et la puissance d'excel, ainsi que le nombre informaticiens disponibles dans énormément d'entreprise.
Tu suggères quoi au juste? Que les gens qui utilisent excel pour gérer des tableaux a plusieurs millions de lignes déploient un RDMS, avec une appli développée spécifiquement pour leur besoin?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: excel c'est mal
Posté par freem . Évalué à 3.
Ou, simplement, que les gens aient conscience des limitations de leurs outils… tu utiliserais une tapette (comme on dit chez moi, ça désigne le marteau pour enfoncer les petits clous de moins de 2 cm de longeur avec une tête de moins de 2 mm de diamètre) pour enfoncer une vis?
Ptain mais ouai, un outil qui enfonce (ou visse, c'est pareil) est adapté à tout… et puis, l'info, c'est facile… ah, pardon, me suis trompé de site on dirait..
[^] # Re: excel c'est mal
Posté par barmic 🦦 . Évalué à 4.
C'est pas parce que beaucoup de monde fais quelque chose que faire autrement est débile.
Il faut être conscient qu'une chose est critique, il faut savoir qu'il peut exister des limites. Aujourd'hui il est tout à fait possible que ton activité repose sur du logiciel sans que tu ne soit connaisseur en la matière.
Je ne sais pas, ça dépend probablement des cas et du reproche. On peut trouver ça débile mais je ne compte le nombre de mousqueton qui ont l'inscription "not for climbing" :
Quand tu tiens un truc comme celui là en main, tu te doute qu'il ne va pas supporter ton poids.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: excel c'est mal
Posté par Anonyme . Évalué à 7.
ouais mais dans excel ils previennent pas :
not for use with data > 20k word
fin si dans la license mais qui la lit ?
[^] # Re: excel c'est mal
Posté par freem . Évalué à 2.
Citation nécessaire la, parce que j'ai assuré au moins 2 fois mon poids sur la même forme! Et je suis un parano sur la sécu, pas envie de me retrouver avec un handicapé sur le dos, ni même dans le club!
Ceci dis, moi, je préfère avoir une visse, et quand je suis responsable, je titille le doigt de tout le monde, vis ou auto, je m'en fout, c'est automatique. Et quand je suis pas responsable, je check quand meme avant chaque grimpe mon assurreur.
J'ai pas eu le "plaisir" de voir ma méfiance être utile, mais une fois que j'étais pas la, justement, un accident s'est produit. Par des "pros".
[^] # Re: excel c'est mal
Posté par barmic 🦦 . Évalué à 3.
Ce truc c'est quelques d'aluminium. Même une corde en 7mm va galérer à passer dedans. C'est un porte clef bon moi mon porte clef est un mousqueton d'assurage, mais c'est un autre délire :p
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# CSV schema
Posté par Thomasv . Évalué à 9. Dernière modification le 06 octobre 2020 à 19:15.
Il existe un schema pour csv avec des validateurs en ligne de commande et une gui simple. Une bibliothèque scala / java est aussi disponible.
[^] # Re: CSV schema
Posté par BAud (site web personnel) . Évalué à 3.
ah tiens, encore un pansement sur une jambe de bois :/
[^] # Re: CSV schema
Posté par Thomasv . Évalué à 5. Dernière modification le 08 octobre 2020 à 06:04.
Si on a déjà une jambe de bois, on est content de pouvoir bien marcher avec…
[^] # Re: CSV schema
Posté par scls19fr (site web personnel) . Évalué à 3.
Il existe aussi CSV Dialect Description Format (CSV-DDF)
https://specs.frictionlessdata.io/csv-dialect/
# dans le même genre, et pas dans le bon sens...
Posté par littlebreizhman . Évalué à 10.
Quand Excel fait plier la nomenclature du génome :
https://www.lemondeinformatique.fr/actualites/lire-quand-excel-fait-plier-la-nomenclature-du-genome-79965.html
(https://www.theverge.com/2020/8/6/21355674/human-genes-rename-microsoft-excel-misreading-dates)
# Excel ? Non, xls
Posté par Jean-Baptiste Faure . Évalué à 3.
Le gros bug c'est surtout d'avoir utilisé un format de fichier obsolète. Après on pourrait reprocher à Microsoft que les versions récentes d'Excel acceptent encore d'écrire des fichiers aux format xls. Mais même ça ne peut rien contre l'utilisation d'un Excel 2003 jamais mis à jour.
[^] # Re: Excel ? Non, xls
Posté par GG (site web personnel) . Évalué à 10.
Je pense que le plus gros problème, c'est d'accepter que le logiciel, dans le cas présent : Excel, passe à la trappe silencieusement des données.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Excel ? Non, xls
Posté par Jean-Baptiste Faure . Évalué à 6.
Quand on importe à la main un csv trop long avec un excel trop vieux, il n'y a pas de message d'avertissement ? C'est une vraie question, je n'utilise plus excel depuis le millénaire précédent.
Si j'ai bien compris dans le cas de l'article l'import du csv dans excel est fait par un script. Peut-on supposer que l'auteur du script a négligé de traiter les retours d'erreur d'excel ?
[^] # Re: Excel ? Non, xls
Posté par desktop.ready . Évalué à 7.
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.
[^] # Re: Excel ? Non, xls
Posté par GG (site web personnel) . Évalué à 2.
Ça arrive aussi avec d'autres logiciels, qui, par défaut vont considérer que le format des cellules est numérique.
Pour éviter ce genre de désagrément, à l'importation d'un CVS ou de données tabulées dans Calc, tu as un premier aperçu. Dans cet aperçu tu vas pouvoir préciser le format des colonnes : Texte, numérique, date (et l'ordre entre le jour, le mois et l'année)…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# SQLlite
Posté par ckiller . Évalué à 10.
Une base SQLlite pour le transport de données tabulaire, il n'y a rien de mieux.
Facile a travailler, libre, standard, universel, rétrocompatible jusqu'en 2050, pas de soucis de codage de caractère, pas de soucis de format de date.
Dommage que SQLite Encryption Extension ne soit pas par défaut.
Sérieux, vous utilisez vraiment encore du csv ?
[^] # Re: SQLlite
Posté par desktop.ready . Évalué à 1.
Oui ce serait l'idéal.
En pratique on tombe toujours sur le plus petit dénominateur commun: CSV.
[^] # Re: SQLlite
Posté par Guillaume D. . Évalué à 5.
A que oui !
SQLITE comme format de fichier applicatif:
Si vous ne l'avez jamais lu : https://www.sqlite.org/appfileformat.html
Si vous êtes pressé : https://sqlite.org/aff_short.html
[^] # Re: SQLlite
Posté par Papey . Évalué à 1.
Je suis hyper fan de SQLite mais je suis un peu tout seul dans ce cas au bureau, tout le monde étant drogué à Excel (un tableur reste plus pratique que SQLite dans un certain nombre de cas, il est vrai, mais l'inverse est vrai aussi !). Tu as des exemples concrets d'utilisation de fichiers SQLite pour l'échange récurrent de données entre personnes ou entre applications métiers développées en interne ?
[^] # Re: SQLlite
Posté par ckiller . Évalué à 3.
On a aussi des fichiers de synchro (plusieurs giga) qui utilisent des fichier SQLIte entre une app .net et Android.
C'est bien simple, quand quelqu'un commence a parler d'un format de fichier spécifique, j'impulse SQLLite.
Je suis embêter quand on commence a parler sécurité et chiffrement.
[^] # Re: SQLlite
Posté par Papey . Évalué à 2.
Merci pour ces précisions !
Tu as déjà pu tester sqlar ?
https://sqlite.org/sqlar.html
[^] # Re: SQLlite
Posté par Vroum . Évalué à 6.
SQLite est également la solution que je privilégie!
Il est souvent impossible d'imposer le format en amont mais même si je suis le seul en bout de chaîne à l'utiliser, cela me permet de facilement valider les types de données et le formatage qui ne manque jamais d'être modifié…
Piste: beaucoup de partenaires/entreprises envoient les fichiers par mail (!). Pour respecter le RGPD, vous pouvez leur imposer de proposer une page de téléchargement qui vous permettra alors de faire la validation initiale dès la transmission (schéma SQL, nombre de colonnes, etc…).
En convertissant les données vers une base SQLite, vous pouvez enrichir avec des tables d'exploitation (version ou date/auteur du transfert, etc…). Accessoirement, vous pouvez aussi ajouter des tables statistiques basées sur certains triggers qui facilitent ensuite l'extraction.
Gros avantage aussi lors de simulation à grande échelle ou d'études exploratoires de données. Le chargement étant largement accéléré (le temps du "parsing" est maintenant nul), vos opérations de maintenance, de tests ou de relance seront grandement améliorées!
Il est urgent de reconsidérer SQLite pour ce genre de travaux et abandonner le CSV. Je ne vais pas revenir sur tous les défauts du format et des erreurs potentielles. Selon moi, le problème vient surtout de la génération en tant que tel et non du format. Quand vous arrivez à devoir faire du support sur Excel chez votre client pour configurer la langue et leur expliquer de manière incessante les options d'export, vous vous rendez compte à quel point cette procédure ne sera jamais viable sur le long terme…
[^] # Re: SQLlite
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Quand l’outil livré requiert que Windows soit configuré avec un format numérique étranger pour que ça marche. C’est du vécu. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: SQLlite
Posté par GG (site web personnel) . Évalué à 3.
J'ai fait un tableau avec Calc, et je suis face à cette problématique de langue.
- Les données, qui sont recopiées dans le tableau sont en anglais, donc le séparateur décimal est un point.
- Mon tableur est configuré en français, par défaut, et j'ai continué ainsi dans l'élaboration du tableau.
- Logiquement, l'utilisateur saisie par endroit des valeurs, et utilise la virgule comme séparateur des décimales (Calc est pénible sur ce sujet, j'aurai bien aimé qui accepte à la fois la virgule et le point).
Du coup, par endroits, je converti des données sous forme numérique, et je suis obligé de précisé que le séparateur est un point ou une virgule, selon la langue de la donnée. Jusque là, tout va bien
Or, si je dois partager mon tableau, je crains qu'il y ait un soucis à un moment, rien qu'à l'utilisation.
Est ce qu'il y aurait une bonne pratique?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: SQLlite
Posté par Anonyme . Évalué à 4.
ne pas utiliser excel mais SQLite ?
[^] # Re: SQLlite
Posté par Jean-Baptiste Faure . Évalué à 3.
Si ton LibreOffice est configuré en français et que tu importes depuis un fichier CSV des données numériques identifiées comme anglaises, tu les obtiendras avec la virgule comme séparateur décimal. Si les données gardent le point, c'est que pour Calc ce ne sont pas des données numériques mais textuelles et elles apparaissent calées à gauche dans leurs cellules comme du texte, alors que les données numériques sont calées à droite par défaut.
Au final tu ne peux avoir des données numériques avec des séparateurs décimaux différents que si tu formates les nombres avec des langues différentes dans l'onglet Nombres du dialogue Formatage des cellules. Quand on fait ça après avoir saisi un nombre, il apparaît une apostrophe devant le nombre (visible seulement dans la barre de formule) pour en faire une chaîne de texte (puisque c'est ce qu'elle était avant le changement de format), il faut enlever cette apostrophe pour en faire un nombre.
Si tu ouvres avec ton LibreOffice un tableur fait sur un LibreOffice configuré en anglais, tu verras les nombres avec une virgule et non avec un point, pour peu que l'utilisateur n'ait pas imposé une langue particulière pour la mise en forme des nombres (il a laissé langue par défaut).
# valeurs imbriqués ou hiérarchiques
Posté par desktop.ready . Évalué à 2.
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…
[^] # Re: valeurs imbriqués ou hiérarchiques
Posté par pasBill pasGates . Évalué à 3.
RS = fin de ligne
US = entre chaque valeur
[^] # Re: valeurs imbriqués ou hiérarchiques
Posté par desktop.ready . Évalué à 2.
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.
[^] # Re: valeurs imbriqués ou hiérarchiques
Posté par pasBill pasGates . Évalué à 1.
Le format CSV definit un champs clairement. Ensuite, si l'utilisateur veut definir de manière plus fine, c'est son problème je dirais. Tu auras du mal a représenter cette séparation plus fine dans les softs qui traitent du CSV vu que l'unité la plus petite est ce champs pour eux.
[^] # Re: valeurs imbriqués ou hiérarchiques
Posté par desktop.ready . Évalué à 1.
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.
[^] # Re: valeurs imbriqués ou hiérarchiques
Posté par steph1978 . Évalué à 5.
Il y a une hiérarchie dans les séparateurs :
28 ␜ INFORMATION SEPARATOR FOUR file separator
29 ␝ INFORMATION SEPARATOR THREE group separator
30 ␞ INFORMATION SEPARATOR TWO record separator
31 ␟ INFORMATION SEPARATOR ONE unit separator
le groupe separator vient avant le record et le unit (=field = value).
donc il ne sert pas à avoir des valeurs imbriquées.
Le sens exact d'un "group" d'information est à définir par l'application.
À lire dans le pdf pointé par la référence 1, page 4.7.
# Mal
Posté par barmic 🦦 . Évalué à 5.
Peut être, peut être pas. Les choses ne sont pas mauvaises ou bonnes en soit. On parle d'échange, le médium n'est qu'un détail. Si possible on retarde son choix. L'important c'est de mettre d'accord l'expéditeur et le destinataire. C'est ça qui fait que ça marche ou pas. Le format ne va pas sauver miraculeusement un projet qui ne fait pas de tests.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mal
Posté par desktop.ready . Évalué à 2. Dernière modification le 06 octobre 2020 à 22:49.
Typiquement:
[^] # Re: Mal
Posté par barmic 🦦 . Évalué à 5.
Et donc ? Utiliser le format superformat3000 va mécaniquement changer quelque chose à ça ?
Si personne dans la boucle ne s'intéresse à la spécification du format tu n'aura pas mieux. Les DTD peuvent donner des données aussi impossibles à reconstruire qu'un csv.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mal
Posté par desktop.ready . Évalué à 4. Dernière modification le 06 octobre 2020 à 23:34.
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.
[^] # Re: Mal
Posté par barmic 🦦 . Évalué à 3.
Quelle est la longueur maximale de tes lignes ?
Quels données sont nécessaires ou pas ?
Ton format de dates, c'est quoi (avec la précision, la nécessité ou non d'une timezone) ?
Les unités de tes chiffres ? Leur précision ?
L'ordre des colonnes est-il portant ?
Tu as des numéros de téléphone quel formats ?
Tu as des données géographiques ?
Tu as des données binaires ?
Tu as un nombre variable d'adresse par ligne ? Tu les mes dans des colonnes séparées, tu fusionne tout dans une colonne ? Avec quoi comme séparateur ?
…
Encore une fois l'important c'est de se mettre d'accord (ou d'accepter le fait de ne pas se mettre d'accord), le format derrière c'est un détail.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mal
Posté par desktop.ready . Évalué à 7.
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.
[^] # Re: Mal
Posté par barmic 🦦 . Évalué à 4.
Le problème de ton article n'est pas un problème de format, c'est un problème d'échange de données.
Choisir son format avant de savoir ce qu'on va mettre dedans et les propriétés attendues n'a pas de sens.
Sinon c'est du plaisir intellectuel sans chercher de mise en pratique, mais alors il y a des formats plus stimulants qu'utiliser les délimiteurs ascii je trouve.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mal
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Je crois que tu confonds format de la table pour extraire convenablement les champs, et le format du champ pour interpréter convenablement les données.
Par exemple il me semble que wordpress met du json dans des cellules mysql (ou un autre format sérialisé). Quelqu’un a montré ici un exemple de CSV embarquant du CSV dans des champs. Le format des numéros de téléphones, des données géographiques, les unités et précision de tes
chiffresnombres, c’est un format de champ.Tu peux très bien imaginer stocker un document odt dans une cellule, tu peux spécifier que ton format est CSV ou Json ou ASCII delimited machin, et spécifier que pour les documents odt ils doivent être encodés en base64 sans saut de ligne.
Et pour l’ordre des colonne et autre choses comme ça, c’est une information supplémentaire qui n’est pas vraiment propre au format de la table.
En gros tu dois documenter :
Faut pas tout mélanger !!! Au final, tu auras une description de format qui fera appel à plusieurs standards. Mais, ce format final, ce ne sera pas CSV, JSON ou ASCII delimited machin.
De la même manière que l’ODT est un format qui fait appel à plusieurs formats : PKZIP, XML et d’autres pour chaque besoin. On peut décider d’un format d’échange qui utilise XML pour distinguer les champs quel que soit le contenu, et décider que le champ date sera sous la forme normalisée YYYY-mm-ddTHH:MM:SS (il faudra donc deux parseurs, mais ce n’est pas un problème). Tu peux pas demander à XML de prendre en charge n’importe quoi. Ce ne serait pas XML ton format, XML serait alors un des formats utilisés dans ton format final.
Pour revenir au journal, quand par exemple Excel essaie d’interpéter des valeurs dans une table alors que l’utilisateur avait simplement l’intention d’afficher proprement des lignes et des colonnes, Excel il prend le risque de détruire des données. Parce que le format de la structure et le format du champ sont deux choses différentes.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Mal
Posté par barmic 🦦 . Évalué à 1.
Bien sûr que c'est lié. Tu as des formats qui peuvent exprimer directement tout cela ça montre bien que ça va avec. Faire l'un sans l'autre c'est ce qui peut mener au problème présenté.
Ne pas systématiquement prendre l'ensemble ça peut mener pas mal de problème et générer de la complexité là où il n'y en a pas besoin.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mal
Posté par Thomas Debesse (site web personnel) . Évalué à 4. Dernière modification le 08 octobre 2020 à 22:04.
On dirait que tu dis ça comme si ça contredisait mon commentaire.
Comparer une twingo avec une 206 ce n’est pas problématique. Comparer la voiture, la caisse et le siège c’est problématique.
Pour celui qui fabrique la caisse ou le siège, la spécifications pour la caisse ou le siège couvrent l’ensemble du besoin. À son niveau, une caisse ou un siège c’est un ensemble cohérent. Pour celui qui assemble la voiture, sa spécification contient la caisse en question et le siège en question.
Bien sûr que le siège est lié à la caisse.
À aucun moment tu ne me contredis. Je rappelle simplement qu’il est possible de concevoir une spécification qui repose sur une autre spécification pour décrire le format des champs, et d’autres spécifications pour décrire tel ou tel type de donnée. On ne compare pas un format comme SQLite à CSV ou ASCII Delimited Text. Là si quelqu’un compare SQLite à CSV ou ASCII Delimited Text, il va avoir des problèmes. CSV ou ASCII Delimited Text c’est le format pour les champs, pas l’ensemble.
À ce que je sache, ni JSON, ni YAML, ni XML ne redéfinissent les standards pour formater les caractères, ils reposent sur des standards établi. Quand XML réutilise base64 pour stockent les blob, la spécification XML repose précisément sur une autre spécification. Idem pour les autres formats qui reposeraient sur
uuencodepour les blobs. J’avais cité les dates au format ISO 8601, c’est normal pour une spécification de se reposer dessus.Tu peux très bien faire face à une spécification qui repose sur UTF-8, ASCII Delimited Text, base64 et ISO 8601 et d’autres trucs de ce genre. La comparaison avec une spécification riche ne se portera pas sur ASCII Delimited Text uniquement, ce ne serait pas juste. Bon, même si on sera sûrement d’accord sur le fait qu’il est peut-être dommage de réinventer la roue alors que d’autres ont travaillé dur sur tous les cas particuliers auxquels on ne pense pas.
Ce fil de discussion tourne autour d’un problème de partie et de tout. Qu’au moins les comparaisons soient faites avec ce qui est comparable !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Mal
Posté par barmic 🦦 . Évalué à 3.
Mais ce que je dis c'est que la dépendance est forte. Vraiment très forte. Prendre SGML et se demander si c'est bien ou mal n'a pas de sens. C'est un format qui a des propriétés (dont certaines ne sont pas intrinsèques). Il faut voir si ça convient ou non à ton usage.
Croire que pointer le format de base suffit est un leurre, croire qu'un format est intrinsèquement bon ou mauvais aussi.
Les formats ne sont pas vraiment comparables en soit ou alors il s'agit de paraphraser wikipedia. Parce que sinon tu ne peux pas jauger l'expressivité des formats hors c'est le principal intérêt de tout ce qui sort des csv-like.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mal
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Cela me rappelle le format FACE décrit 4 ou 5 niveaux de descriptions pour une seule donné (altitude -> en référentiel géodésique WGS84 -> en m -> en int32 big endian), le but est d'avoir l'info complète histoire de faire un convertisseur au besoin (m -> feet, int32 -> float64).
"La première sécurité est la liberté"
[^] # Re: Mal
Posté par ckyl . Évalué à 8. Dernière modification le 07 octobre 2020 à 08:09.
J'ai rien contre ces codes ascii. Par contre les utiliser comme séparateurs en supposant qu'ils n'apparaissent pas dans les données c'est une connerie. Si tu fais du CSV tu dois gérer correctement échappement et protection. Il est possible que les séparateurs apparaissent dans les données c'est non négociable et non discutable.
Laisser entendre qu'il y aurait des séparateurs qui évitent les problèmes 95% du temps c'est empirer le problème alors que la solution est simple et connue depuis 40+ ans.
J'ai tellement d anecdotes sur "nan mais ça apparaîtra pas dans les données" que ça en ait déprimant sur la médiocrité ambiante.
[^] # Re: Mal
Posté par desktop.ready . Évalué à 2.
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.
[^] # Re: Mal
Posté par ckyl . Évalué à 10.
Ça ne pose aucun problème a spécifier et a implémenter. Il faut juste faire son travail correctement.
Le coût de la rentabilité est une grosse blague. En 7 ans ou j'ai bossé sur des data pipeline je peux compter en années ETP le temps passer sur des incidents CSV. On a littéralement claquer des centaines de milliers d'euros là dessus.
Spécifier systématiquement et correctement le format de donnée ça prend 1H par cas (3mn a écrire et le reste en overhead). Écrire de zéro un parser correct c'est une demi journée (on parle d'une bête machine a état hein) et bien sûr ça existe sur étagère, il suffit de configurer correctement les libs. Faire le boulot d'explication ça prend plus de temps mais ça paie toujours rapidement.
En faisant simplement ce travail, mon équipe est arrivée à 0 incidents en manipulant des fichiers venant de dizaines de sources quand les incidents étaient business a usual dans d'autres.
Après dans la vraie vie les séparateurs c'est qu'une petite partie. Encoding, BOM, charset supportés font partie du jeu mais ce n'est pas plus compliqué.
Faire le boulot de spec et savoir écrire des lecteurs stricts ou tolérant selon les cas, c'est juste faire son travail correctement. Si on considère que c'est trop difficile c'est absolument terrifiant sur notre industrie.
[^] # Re: Mal
Posté par desktop.ready . Évalué à 0.
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.
[^] # Re: Mal
Posté par barmic 🦦 . Évalué à 2.
Tu n'a pas compris son commentaire. Il ne dis rien de particulier sur csv. Mais il ne parle surtout de spécifier son format et pas d'écrire une RFC sur csv. Donc le boulot ce n'est pas d'écrire tous les cas de l'univers, mais de décrire tes cas. Ça n'a pas de sens de décrire les cas de cette page, on ne pars pas d'un résultat pour renverse une spec, mais on pars d'un besoin. Si tu galère à spécifier ton besoin avec un format donné, ça peut être intéressant de se demander si l'expressivité de format n'est pas un problème pour toi.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mal
Posté par desktop.ready . Évalué à 1.
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é".
[^] # Re: Mal
Posté par barmic 🦦 . Évalué à 2.
Donc tu liste le nom des colonnes ("prix" ce n'est pas "Prix" ou "priX"), que leur ordre est fixé ou non, que vous utilisé une virgule comme séparateur entre les unités et les dixièmes, que le prix est en euro, quel colonnes sont nécessaires ou pas, que tu accepte les commentaires et qu'il s'agit de ligne commençant par le caractère # s'il n'est pas protégé,…
C'est pourtant assez simple. Prend ta spec et écris le bout de code pour produire une structure utilisable dans ton code (→ qui ne nécessite plus de se protéger ou de nouvelle étape de parsing) et regarde la liste des hypothèses que tu aura formulée. Chaque hypothèse que tu aura formulée et qui n'est pas explicite dans la spec (soit en le décrivant directement soit en faisant référence à autre chose), c'est un cas d'erreur potentiel.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mal
Posté par chimrod (site web personnel) . Évalué à 3.
Bien sûr que c'est faisable. S'il faut sortir l'artillerie lourde (lex/yacc) on la sort. Ça prendra pas 3mn (pour moi en tout cas), mais je t'assure que tous les cas seront gérés, y compris les valeurs imbriquées.
Tu me donnes presque envie de le faire en OCaml tiens… :)
[^] # Re: Mal
Posté par freem . Évalué à 2.
Chiche? Mais faut d'abord spécifier une syntaxe, que les autres puissent jouer…
[^] # Re: Mal
Posté par chimrod (site web personnel) . Évalué à 6.
Un graphique valant un long discours, je te propose ça (représentation d'une ligne) :
source du schéma
Il ne reste plus qu'à définir les règles pour :
content= zero ou plusieurs fois (tout caractère sauf (field separator|CR|LF))escaped content= zero ou plusieurs fois ((tout caractère saufRIGHT_ESC) |RIGHT_ESC_ESCRIGHT_ESC)Tous les exemple de sebsauvage sont gérés, y compris les valeurs imbriquées.
[^] # Re: Mal
Posté par desktop.ready . Évalué à 2.
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 :
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.
[^] # Re: Mal
Posté par Fulgrim . Évalué à 3.
Par contre attention, unicode ça ne suffit pas dans ce genre de specs, tu veux plutôt dire UTF-8 (ou 16, ou 32 suivant ton cas, voir UTF-7 si tu travailles pour l'empire du mal… si si ça existe).
Pour être plus explicite, unicode défini des numéros pour chaque caractère (genre A=12, B=13,…) mais pas comment tu codes ces numéros "en binaire". UTF-8 propose une solution pour les représenter sur un ou plusieurs blocs de 8 bits, utf de 16 bits avec des variantes suivant l'endianness et ainsi de suite.
[^] # Re: Mal
Posté par freem . Évalué à 2.
Perso, quand je lis "unicode" je comprend "codepoint unicode". Mais tu as raison c'est un raccourcis mental que je me suis fait.
[^] # Re: Mal
Posté par freem . Évalué à 2.
Ajoutes juste "tout glyphe ASCII 30 ou 29 devant être utilisé dans un champ doit être encodé sous la forme \30 ou \29, et le glyphe \ doit être encodé sous la forme \134" et ça me paraît bon. Tu utilisais bien le décimal pour 29 et 30?
[^] # Re: Mal
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 5.
Il manque surtout un "contrat d'interchange" entre la société alpha et la société beta.
# Revue
Posté par barmic 🦦 . Évalué à 5.
C'est marrant parce que ton script a peut être les même limite que l'article → des limites du nombre de lignes.
readlinesl'API de csv peut consommer un générateur de ligne, ça éviterait de prendre tout le fichier en mémoire une première fois[ws.append(row) for i,row in enumerate(reader)]les list comprehension c'est fait pour construire des listes plus que pour itérer, ici tu construit une liste du nombre de lignes pour rienTu parle de ASCII Delimited Text, mais dans ton script tu ne fais référence qu'à csv.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Revue
Posté par desktop.ready . Évalué à 3.
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.
[^] # Re: Revue
Posté par barmic 🦦 . Évalué à 3.
J'ai bien compris mais ta documentation argpars parle de csv, c'est trompeur, non ?
Mais tu créé une liste potentiellement grande. C'est de l'optimisation prématurée je trouve
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Revue
Posté par barmic 🦦 . Évalué à 3.
D'ailleurs ce que tu gagne sur cette boucle tu la perds largement dans les 3 boucles de la lecture du fichier
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Revue
Posté par desktop.ready . Évalué à 1.
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.
# Je suis trop naïf ?
Posté par Philippe M (site web personnel) . Évalué à 2.
Je travail tout les jours avec des échanges de fichiers par EDI, entre DB, entre appli.
Les choses évoluent entre appli car de plus en plus sont capables d'exposer/communiquer avec une API.
Reste qu'entre DB ou par EDI le format bien implanté est le csv pour tout le bien et le mal qu'on peut lui trouver.
Mais à la réflexion et pour simplifier le boulot de tout le monde il nous faudrait un fichier qui contient à la fois les données mais aussi la description de celle-ci. Voir même une en-tête qui caractérise la structure du fichier, un peu comme un xml mais en plus léger.
Par exemple :
De cette manière dans un fichier on a la description de sa structure, la description des données et les données. L'avantage est qu'une personne arrivant sur un projet n'ayant pas eu/lu le cahier des charges peut déjà comprendre de quoi il retourne.
Mon exemple est loin d'être parfait car fait en 3mn en attendant que la machine à café soit accessible.
Born to Kill EndUser !
# Et le format HDF5 ?
Posté par binoyte . Évalué à 3.
Les logiciels de calcul numérique, comme Scilab, propose le format HDF5. Je ne connais pas plus que ça, j'ai toujours exporté et importé en CVS…
Mais c'est peut-être une piste.
[^] # Re: Et le format HDF5 ?
Posté par desktop.ready . Évalué à 3.
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.
[^] # Re: Et le format HDF5 ?
Posté par diorcety . Évalué à 1.
Au final tu as le même problème qu'avec un système de fichier classique (en plus contraint), non?
[^] # Re: Et le format HDF5 ?
Posté par freem . Évalué à 2.
J'en doute, une système de fichier, ça bosse avec des blocks me semble, qui ont uen taille minimale, je dirais d'environ 4Kio pour ceux que je «connais». Imagines le gâchis sur disque et en mémoire quand tu as un peu trop d'enregistrements…
[^] # Re: Et le format HDF5 ?
Posté par Psychofox (Mastodon) . Évalué à 2.
Le problème de sqlite, et ce que des tableurs comme excel résolvent, c'est que la gui est intégrée. T'as pas besoin de créer d'appli pour ta db (et un client de db universel ou non), c'est quand même austère et peu intuitif, même comparé à un truc pas excitant comme excel.
[^] # Re: Et le format HDF5 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
libreoffice ne sait pas lire de fichier sqllite ?
"La première sécurité est la liberté"
[^] # Re: Et le format HDF5 ?
Posté par Psychofox (Mastodon) . Évalué à 3.
Après vérification si mais je n'avais même pas connaissance de l'existence de libreoffice base vu que je n'utilise quasi jamais de suite bureautique.
[^] # Re: Et le format HDF5 ?
Posté par freem . Évalué à 4.
Y'a une GUI a sqlite? Un truc officiel je veux dire… non parce que pour moi, l'intérêt de sqlite, c'est d'être un SGBDR sur un seul fichier, donc léger et relativement «simple» à bouger, point barre.
Tu aurais parlé d'access, j'aurais compris… mais ça reste un outil de prototypage a mes yeux.
[^] # Re: Et le format HDF5 ?
Posté par Papey . Évalué à 1.
SQLite Studio ou DB Browser pour SQLite. J'ai une préférence pour le premier, même s'il n'intègre pas encore la dernière version de la bibliothèque SQLite avec les "window functions".
[^] # Re: Et le format HDF5 ?
Posté par barmic 🦦 . Évalué à 3.
Des 2 en regardant rapidement, seul le second cherche des usages sur les platebandes d'excel (tracer des courbes1, formater l'affichage,…) par contre c'est entregistré dans un fichier projet qui doit pointer sur une base, c'est casse-gueule (d'autant qu'ils ont l'air d'utiliser des chemins depuis la racine).
il semble ne s'agir que de tracer et pas de calcul (genre calculer une courbe à partir d'un ensemble de points) ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et le format HDF5 ?
Posté par Anonyme . Évalué à 7. Dernière modification le 09 octobre 2020 à 12:51.
pour cela tu as gnuplot ou R, tu peux l'inclure avec latex pour faire un jolie pdf, :D mais bon si les commerciaux savait utiliser SQL ils ne seraient plus commerciaux ;)
Excel à permis de noyer le poisson, les données et leurs rendu de manière transparente, inséré des photos etc … Du coup avec nos outils Libre, ne faire qu'une chose mais la faire bien, c'est plus dure à intégrer en entreprise. il faut connaitre chaque outils et les lier ensemble. Très puissant mais la courbe d'apprentissage est un peu raide, ca coute en formation car à par sur linuxfr qui essayerait de lire la doc de gnuplot, sqlite et LaTeX pour dessiner un camembert en pdf, pour la reunion que je n'ai pas préparé dans 10 minutes ?
exemple trouvé sur internet pour gnuplot et sqlite, moi j'aime bien :
SqliteField(f) = '< sqlite3 myfile.db3 "SELECT '.f.' from myTable;"'
fields = 'temp1 temp2 pressure humidity'
plot for [f in fields] SqliteField(f) using 0:1 title f
[^] # Re: Et le format HDF5 ?
Posté par Olivier Abad . Évalué à 1. Dernière modification le 09 octobre 2020 à 14:10.
s/commerciaux/développeurs/
Ce commentaire est basé sur mon expérience, et n'a aucune valeur générale, mais bon c'est vendredi.
[^] # Re: Et le format HDF5 ?
Posté par barmic 🦦 . Évalué à 1.
Tu crois sincèrement ce que tu dis ?
Je suis entrain de faire traiter quelques millions de document avec elasticsearch et kibana ce qui donne des résultats que tu ne peux même pas envisager avec ce que tu viens de décrire, mais faut être conscient que les gens peuvent avoir des points de vu et des connaissances différentes des tiennes. En principe on acquière cette capacité vers 3 ou 4 ans. Dans les tech, c'est plus vers 35~40 ans en moyenne.
Et si un technos s'intéressait au point de vu des utilisateurs il serait pas techos, mais testeur qualité.
Il n'y a aucune raison technique que quelque chose de simple avec excel demande de maîtriser 3 à 4 langages turing complet pour le faire en plus moche. Vraiment aucune.
Et le "nos outils Libre" (avec un grand L majuscule monsieur) LibO, gnumeric et consor ça n'est pas libre ? Qu'est-ce qu'il ne faut pas lire même pour un vendredi…
Reste à cheval sur tes principes sans chercher à comprendre les besoins, mais ne te plains pas que les autres ne se servent pas de tes outils. Restons éternels incompris (sans chercher à comprendre les besoins)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et le format HDF5 ?
Posté par Tit . Évalué à 1.
euh, je suppose que tu voulais dire le contraire : "Le problème de sqlite […] c'est que la gui n'est pas intégrée" et "Tu as besoin de créer"
[^] # Re: Et le format HDF5 ?
Posté par Psychofox (Mastodon) . Évalué à 2.
oui j'ai oublié la négation, j'imagine parce que j'ai mentionné excel.
# fgetcsv
Posté par Christie Poutrelle (site web personnel) . Évalué à 2.
Je suis sûr qu'en utilisant n'importe quelle library qui parse du CSV on peut parser le ASCII Delimited Text aussi: la majeure partie d'entre elles permettent de configurer les délimiteurs et les séquences d'échappement, il suffirait alors de leur passer ceux du ASCIIDT.
[^] # Re: fgetcsv
Posté par desktop.ready . Évalué à 2. Dernière modification le 07 octobre 2020 à 13:16.
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).
[^] # Re: fgetcsv
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
En effet, j'avais omis ce détail.
[^] # Re: fgetcsv
Posté par freem . Évalué à 2.
Es-tu certain, ou persuadé?
[^] # Re: fgetcsv
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
Non, mais ça y ressemble tout de même beaucoup, j'ai vu en première lecture une différence de délimiteurs mais finalement pas de différence fondamentale dans la manière de lire les données: stockage en lignes, avec des colonnes ordonnées, pouvant être lue en flux continu sans besoin de rewind/seek.
# DataPackage
Posté par scls19fr (site web personnel) . Évalué à 1. Dernière modification le 07 octobre 2020 à 21:00.
Le format Tabular DataPackage peut aussi être envisagé… en clair c'est un (ou plusieurs) fichiers CSV mais "documenté".
https://frictionlessdata.io/data-package/
ça ne résout probablement pas tous les problèmes évoqués mais c'est simple.
# non, en finir µ$ et autres irrespects
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Pourquoi blâmer le format quand on l'utilise mal ? (sciemment ou avec un outil qui foire dans l'utilisation/exploitation du format…)
Dans le principe des échanges/transferts de données tabulaires, les formats à délimiteurs conviennent (il est important de noter qu'il y a des conventions/normes à respecter pour que ça marche bien)
Bien, ayant ceci à l'esprit, on voit que l'appellation CSV a été abusée pour tout et n'importe quoi… Beaucoup d'ajouts (dont l'usage de double-guillemets-droits) ont cependant fini par être standardisé dans la RFC 4180 Malgré cela, beaucoup d'outils :
Faire n'importe quoi est une façon de torpiller/saboter l'échange. Bien que la firme de Redmond ne soit pas seule fautive, je la fustige car elle est (et se veut) la plus utilisée (et donc un standard de fait pour certains) et donc il est criminel de sa part de répandre massivement ce qu'il ne faut pas faire.
Il y a d'autres formats d'échange qui suivent d'autres modèles que DSV. Deux d'entre eux, adaptés aux tableurs (pour préserver les formules —et donc avoir des cellules calculées dynamiquement— et le formatage —au moins distinguer les nombres avec leur affichage et du texte standard avec leur justification— dans ce cas) ont été évoqué. Mais il faut malheureusement constater que
C'est bizarre, mais chaque fois que Bill et ses acolytes sont dans la danse ça part en vrille… Le salut est donc dans le fait de virer ces trucs là pour commencer, et de respecter les formats d'échange.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# ASN.1
Posté par BAud (site web personnel) . Évalué à 4. Dernière modification le 10 octobre 2020 à 13:10.
bizarre que personne n'ait évoqué ASN.1 :
https://fr.wikipedia.org/wiki/ASN.1
[^] # Re: ASN.1 voire NetCDF
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 24 octobre 2020 à 23:03.
ah et sinon il y a NetCDF qui a des bindings dans pas mal de langages (et est auto-documenté de manière un peu plus robuste que le CSV…)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.