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 (削除) chiffres (削除ここまで)nombres, 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 :
Le format du fichier (ce que j’ai appelé table), en gros, comment séparer et adresser les champs,
Le format des données dans les champs, ce qui peut être spécifique à chaque type de donnée,
Certains aspects comme l’ordre ou des choses comme ça.
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 Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. É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
(削除) chiffres (削除ここまで)nombres, 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