Discussion :

[Emmanuel Delahaye]

La solution binaire (TLV ou XDR: http://emmanuel-delahaye.developpez....m#enreg_struct ) est-elle de manière générale à préférer à un fichier texte (du type CSV ou autre)?

Ca dépend des contraintes. Si on est libre du choix, la solution texte (ASCII, par exemple) est recommandée, car elle est très simple. Seul défaut, elle prend plus de place pour les valeurs numériques, surtout si on veut de la précision (décimaux, quoique que la notation scientifique soit parfois plus compacte... à voir au cas par cas).

Les problèmes de portabilité (fin de lignes, ASCII vs EBCDIC) sont extrêmement limités, biens définis et facile à contourner. Ca peut être un peu plus chaud si on est en mode caractères multibytes (Unicode et autres). Mais je pense que le convention est la même partout : MSB en tête.

Mais parfois, le format est imposé. En SNMP, par exemple, c'est BER. Pas le choix, il faut se cogner ce format binaire...

[Jean-Marc.Bourguet]

La solution binaire (TLV ou XDR: http://emmanuel-delahaye.developpez....m#enreg_struct ) est-elle de manière générale à préférer à un fichier texte (du type CSV ou autre)?

Ça dépend du contexte.

Le problème de l'encodage (ASCII) est-il une limitation importante d'un point de vue de la portabilité?

L'important est que le format soit bien défini. Et donc il faut de toute manière fixer un encodage pour les caractères s'il y en a. Après... j'ai tendance à considérer qu'il faut préférer un format texte tant qu'on n'est pas certain qu'un format binaire apporte des avantages.

[Thierry Chappuis]

Ca dépend des contraintes. Si on est libre du choix, la solution texte (ASCII, par exemple) est recommandée, car elle est très simple. Seul défaut, elle prend plus de place pour les valeurs numériques, surtout si on veut de la précision (décimaux, quoique que la notation scientifique soit parfois plus compacte... à voir au cas par cas).

Les problèmes de portabilité (fin de lignes, ASCII vs EBCDIC) sont extrêmement limités, biens définis et facile à contourner. Ca peut être un peu plus chaud si on est en mode caractères multibytes (Unicode et autres). Mais je pense que le convention est la même partout : MSB en tête.

Mais parfois, le format est imposé. En SNMP, par exemple, c'est BER. Pas le choix, il faut se cogner ce format binaire...

Merci, Emmanuel et Jean-Marc

Thierry

[Médinoc]

Mais je pense que le convention est la même partout : MSB en tête.

Justement pas en unicode sous Windows: C'est tout en UTF-16 LE ou (UCS-2 LE avant).
D'ailleurs, la CRT 8.0, qui supporte nativement l'ouverture de fichiers en unicode, ne supporte hélas pas l'UTF-16 BE...

[Emmanuel Delahaye]

Justement pas en unicode sous Windows: C'est tout en UTF-16 LE ou (UCS-2 LE avant).
D'ailleurs, la CRT 8.0, qui supporte nativement l'ouverture de fichiers en unicode, ne supporte hélas pas l'UTF-16 BE...

Quels gros nuls. Même pas foutus de respecter les conventions... Ca m'énerve...

[JeitEmgie]

Justement pas en unicode sous Windows: C'est tout en UTF-16 LE ou (UCS-2 LE avant).
D'ailleurs, la CRT 8.0, qui supporte nativement l'ouverture de fichiers en unicode, ne supporte hélas pas l'UTF-16 BE...

si c'est le cas alors elle ne peut pas prétendre être compatible Unicode :

un fichier UTF-16 soit commence par le BOM (0XFEFF pour BE, 0xFFFE pour LE), soit est big endian…

selon les specs, UTF-16 sans BOM en LE, c'est pas … de l'Unicode …

[Jean-Marc.Bourguet]

si c'est le cas alors elle ne peut pas prétendre être compatible Unicode :

un fichier UTF-16 soit commence par le BOM (0XFEFF pour BE, 0xFFFE pour LE), soit est big endian…

selon les specs, UTF-16 sans BOM en LE, c'est pas … de l'Unicode …

Reference? A ma connaissance Unicode n'impose rien du tout et laisse a des conventions externes (ils parlent de protocole) le choix d'exiger, d'interdire ou de rendre facultatif le BOM dans des donnees. Une BDD peut parfaitement stocker les champs textes en UTF-16LE sans mettre un BOM au debut de chacun des champs.

(J'ai cru comprendre que pour Windows, MS avait decide qu'un BOM etait obligatoire pour les fichiers textes encode en unicode).

[Médinoc]

1. Il n'y a pas de "pas foutus de respecter les conventions" ici, puisque c'est déjà une extension. Et le choix doit être dû au fait que la plupart des plate-formes Windows tournent sur du intel, donc tout texte en UTF-16 est en LE en mémoire...
2. Je n'ai jamais dit "sans BOM"... La BOM est présente et lue, elle peut même permettre de différencier entre UTF-8 et UTF-16 LE, mais l'extension de lecture ne supporte pas l'UTF-16 BE...

PS: Cela concerne uniquement la CRT de microsoft. Le framework .Net, lui, supporte tous les encodages Unicode, plus toutes les codepages Windows...
Extension d'encodage de la CRT 8.0
Encodages supportés par .Net

[Médinoc]

La BOM est sans doute obligatoirement mise par les programmes et API "fichier texte" de Microsoft.

Au passage, le problème du "bush hid the facts" dans Notepad vient du fait que pour les fichiers sans BOM, Notepad utilise une heuristique (la fonction IsTextUnicode()) pour savoir si le fichier ne serait pas quand même un fichier unicode dont la BOM aurait été oubliée. Heureusement, ce test est effectué quand on sélectionne le fichier dans la boîte de dialogue d'ouverture, ce qui permet de forcer manuellement le mode d'ouverture avant de cliquer sur OK...

[JeitEmgie]

Reference? A ma connaissance Unicode n'impose rien du tout et laisse a des conventions externes (ils parlent de protocole) le choix d'exiger, d'interdire ou de rendre facultatif le BOM dans des donnees. Une BDD peut parfaitement stocker les champs textes en UTF-16LE sans mettre un BOM au debut de chacun des champs.

évidemment ! et heureusement…

comme vous dites, ce que dit Unicode, c'est que sans BOM, le LE/BE doit être spécifié par le "protocole", donc de manière externe au stream de bytes…
(et dans ce cas il NE peut PAS avoir de BOM…)

dans le cas de l'exemple de la BDD, cela veut simplement dire que le fait que les champs sont en UTF-16LE est spécifié dans son mode d'emploi, dans un paramètre d'exploitation, …

mais quand ni l'un ni l'autre ne sont spécifiés : càd quand vous recevez un UTF-16 sans plus d'explication et qu'il n'y a pas de BOM alors il faudrait supposer le BE…
(fallait bien en choisir un des deux, et c'est le plus "lisible par un humain" qui a été pris…)

mais rien ne vous empêche d'essayer les 2 dans vos programmes…
le but étant toujours d'obtenir une solution qui satisfasse l'utilisateur final avant tout…