OK CSV a plein de défauts, mais certainement pas celui-la, sur ça c'est clair (voir la RFC) et classique (je peux mettre des codes HTML pour tous les caractères, ou pas, pareil)
"Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes"
Il y a une première ligne avec le nom des valeurs, ou pas...
Comme le charset, il faut effectivement le dire avant avec par exemple l'aide des en-têtes HTTP :
The "header" parameter indicates the presence or absence of the header line. Valid values are "present" or "absent".
Et c'est perdu lors du stockage sur disque.
Après, si on spécifie ces trois points ainsi que l'encodage utilisé on définit bien un format de manière formel.
4 points? Je vois que deux points qui sont les en-tête HTTP :
- "charset" : Encodage
- "header" : Header CSV ou pas
comme la RFC en fait ;-).
Et perso j'utilise UTF-8 avec en-tête.
[^] # Re: Mon avis
Posté par Zenitram (site web personnel) . En réponse au journal XML c'est de la daube!!!. Évalué à 1.
RFC 4180
OK CSV a plein de défauts, mais certainement pas celui-la, sur ça c'est clair (voir la RFC) et classique (je peux mettre des codes HTML pour tous les caractères, ou pas, pareil)
"Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes"
Comme le charset, il faut effectivement le dire avant avec par exemple l'aide des en-têtes HTTP :
The "header" parameter indicates the presence or absence of the header line. Valid values are "present" or "absent".
Et c'est perdu lors du stockage sur disque.
4 points? Je vois que deux points qui sont les en-tête HTTP :
- "charset" : Encodage
- "header" : Header CSV ou pas
comme la RFC en fait ;-).
Et perso j'utilise UTF-8 avec en-tête.