Les fichiers de conf en xml, quel intérêt ?

Tonton Th , dans le message <4cbcadc6$0$5859$426a74cc@news.free.fr>, a
écrit :

Euh, "Une chaîne de caractères est une suite de
zéro ou plus caractères Unicode," ?

Encore heureux !

Seulement, un fichier, c'est une suite d'octets, pas de caractères.
L'encodage, c'est justement la description de la correspondance entre les
octets et les caractères. S'il n'est pas déclaré, on revient aux
catastrophes historiques.

Nicolas George wrote:

Tonton Th , dans le message <4cbcadc6$0$5859$426a74cc@news.free.fr>, a
écrit :

Euh, "Une chaîne de caractères est une suite de
zéro ou plus caractères Unicode," ?

Encore heureux !

Seulement, un fichier, c'est une suite d'octets, pas de caractères.
L'encodage, c'est justement la description de la correspondance entre les
octets et les caractères. S'il n'est pas déclaré, on revient aux
catastrophes historiques.

D'où la réponse donnée: JSON est encodé en Unicode.

http://www.json.org/fatfree.html, vers le milieu de la page

The character encoding of JSON text is always Unicode. UTF-8 is the only

encoding that makes sense on the wire, but UTF-16 and UTF-32 are also
permitted.

Et puis je ne vois pas réellement où est le soucis de l'encodage.

C'est au développeur de prendre le soin d'encoder et de décoder dans le même
encodage et d'indiquer aux utilisateurs l'encodage à utiliser.
Et il est plus que risqué de fournir l'encodage dans le fichier lui-même
(duplication d'information, le fichier contenant de lui-même dans quel
encodage il est), l'encodage déclaré n'étant pas forcément l'encodage
utilisé pour enregistrer le fichier (je peut marquer ISO-8859-1 dans mon
fichier mais l'enregistrer en UTF-8).
La déclaration ne sert donc à rien, elle n'empèche pas une corruption du
fichier sauf à garantir que l'enregistrement du fichier a bien lieu dans
l'encodage déclaré (ce qui est bien plus difficile à obtenir que la simple
garantie que le fichier est bien enregistré dans le format demandé).

Et c'est justement pour ça qu'on a inventer l'Unicode, pour éviter à
l'avenir de s'arracher la tête sur ces problèmes (qui sont plus du domaine
de l'erreur de développement que de l'erreur de spécification).
l'UTF-8 DEVRAIT être la norme sur tout support de communication. C'est
d'ailleurs en ce sens que l'IETF impose dorénavant le support total natif
d'UTF-8 dans toutes ses RFC de protocoles de communication.

Aeris , dans le message <4cbcc297$0$12630$426a74cc@news.free.fr>, a
écrit :

D'où la réponse donnée: JSON est encodé en Unicode.

Ce qui ne veut rien dire : Unicode est un catalogue de caractères, pas un
encodage (rappel du message précédent : un encodage, c'est la correspondance
entre des octets et des caractères).

Unicode simplifie la gestion des encodages, en ce qu'il permet de décomposer
la relation « octets -> caractères » en « octets -> numéro » et « numéro ->
caractère », ce qui est plus facile à décrire de manière systématique.

Mais Unicode lui-même ne parle pas d'octets.

http://www.json.org/fatfree.html, vers le milieu de la page

The character encoding of JSON text is always Unicode. UTF-8 is the only

encoding that makes sense on the wire, but UTF-16 and UTF-32 are also
permitted.

Ce texte a manifestement été écrit par quelqu'un qui a les idées très
confuses sur ce qu'est Unicode et ce qu'est un encodage. Ça ne donne pas
confiance dans le sérieux de l'ensemble.

C'est au développeur de prendre le soin d'encoder et de décoder dans le même
encodage et d'indiquer aux utilisateurs l'encodage à utiliser.

Je croyais qu'on cherchait à avoir des bibliothèques toutes faites pour
éviter de réinventer la roue à chaque fois.

Et il est plus que risqué de fournir l'encodage dans le fichier lui-même

Plus risqué que quoi ?

(duplication d'information, le fichier contenant de lui-même dans quel
encodage il est), l'encodage déclaré n'étant pas forcément l'encodage
utilisé pour enregistrer le fichier (je peut marquer ISO-8859-1 dans mon
fichier mais l'enregistrer en UTF-8).

Déclarer l'encodage n'est pas une garantie qu'il n'y ait pas de problème,
mais ne pas le déclarer, c'est la garantie qu'il y aura des problèmes.

Nicolas George wrote:

Déclarer l'encodage n'est pas une garantie qu'il n'y ait pas de problème,
mais ne pas le déclarer, c'est la garantie qu'il y aura des problèmes.

Pour moi, déclarer un encodage ne fait qu'apporter de l'inconsistence en
plus. Au lieu d'avoir une simple possibilité d'avoir une différence entre
encodé / décodé, on a une incohérence entre déclaré / codé / décodé.

Prenons l'exemple d'un soft qui fonctionne en UTF8.
Le jour où quelqu'un m'envoit un fichier encodé en UTF16 mais déclaré en
UTF8 dedans, j'en fais quoi? Je n'arriverait même pas à lire son contenu
étant donnée que je vais décoder en UTF8!

Parce que pour pouvoir décoder ton encodage déclaré, il faudra que j'ai déjà
décodé ton fichier, donc que j'ai lu ton encodage déclaré! L'oeuf, la poule,
tout ça...
Dans l'exemple ci-dessus, au mieux, j'arriverait à voir "UTF-8",
et pour le comprendre............ ben faudra que je cause UTF16, parce qu'en
UTF8, c'est 10 caractères ça, pas 5!

Avec ou sans déclaration, je serais de toute façon dans l'incapacité de
décodé un fichier mal encodé. Alors ça sert à quoi au final?

Surtout que dans l'autre sens c'est encore pire.
Mon soft tourne en UTF8, mais par malheur je le déclare en UTF16.
Bilan, à l'autre bout du tuyau, j'ai un fichier que j'arrive parfaitement à
lire, encodé en UTF8 qui est bien l'encodage de mon décodage, mais dont la
déclaration est fausse! J'en fais quoi? Je le rejette alors que je l'ai
décodé sans erreur et qu'il est 100% consistant?

Sachant en plus que je n'ai pas le moyen de faire la différence entre un
fichier en UTF8 bien encodé et un fichier en UTF16 déclaré UTF8.
"UTF-16" (6 caractères) veut vraiment dire UTF16 en UTF8 mais Ox"UT" +
Ox"F-" + Ox"16" (3 caractères) en UTF16...

Aeris , dans le message <4cbcd22a$0$11799$426a74cc@news.free.fr>, a
écrit :

Pour moi, déclarer un encodage ne fait qu'apporter de l'inconsistence en
plus.

Et tu dis ça comme si c'était une mauvaise chose. La redondance de
l'information, c'est une occasion de détecter une erreur. Un avertissement
explicite vaut infiniment mieux qu'une erreur qui se propage silencieusement
et corrompt des données.

Le jour où quelqu'un m'envoit un fichier encodé en UTF16 mais déclaré en
UTF8 dedans, j'en fais quoi?

Tu le rejettes avec un message d'erreur clair, et éventuellement avec les
options offertes pour diverses tentatives de réparation partiellement
automatisées.

olive wrote:

Bonjour,

Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un
fichier de conf en xml. Je n'y connais pas grand chose, mais je me
demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête
fichier texte à éditer ? C'est une vraie question.

Bonjour,

Quelle version de prosody? Chez moi c'est un fichier texte à peu près plat,
la configuration. En fait c'est du LUA:

/etc/prosody/prosody.cfg.lua

Mis à part les commentaires qui commencent par "--" il n'a vraiment rien
d'effrayant, et encore moins de XML.

Rémi.

Le 18 Oct 2010 22:20:14 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :

Aeris , dans le message <4cbcc297$0$12630$426a74cc@news.free.fr>, a
écrit :

D'où la réponse donnée: JSON est encodé en Unicode.

Ce qui ne veut rien dire : Unicode est un catalogue de caractères, pas un
encodage (rappel du message précédent : un encodage, c'est la correspondance
entre des octets et des caractères).

Unicode simplifie la gestion des encodages, en ce qu'il permet de décomposer
la relation « octets -> caractères » en « octets -> numéro » et « numéro ->
caractère », ce qui est plus facile à décrire de manière systématique.

Mais Unicode lui-même ne parle pas d'octets.

Et alors ? La première chose que doit faire un parser (à moins de
vouloir se tirer immédiatement une balle dans le pied), c'est de
décoder par lui-même l'encodage et non de se fier à une ligne de
configuration. Il suffit d'avoir un éditeur moisi pour qu'il modifie
dans le dos de l'utilisateur l'encodage lors d'une écriture. Écrire
en dur l'encodage dans le fichier de conf ou partir du principe que
celui-ci doit être en UTF-8 ou en ECDBIC est la plus grande connerie
qu'on puisse faire.

Un parser _doit_ (mais tu peux faire autrement) commencer par
traiter le flux d'octets ou de caractères larges par un
préprocesseur qui te vire les commentaires et qui te convertit cette
suite de bits dans un format connu (et au passage t'insulter si le
flux ne correspond à rien de connu).

Si le fichier source a passé avec succès cette étape, tu peux
ensuite le traiter sereinement.

http://www.json.org/fatfree.html, vers le milieu de la page

The character encoding of JSON text is always Unicode. UTF-8 is the only

encoding that makes sense on the wire, but UTF-16 and UTF-32 are also
permitted.

Ce texte a manifestement été écrit par quelqu'un qui a les idées très
confuses sur ce qu'est Unicode et ce qu'est un encodage. Ça ne donne pas
confiance dans le sérieux de l'ensemble.

C'est au développeur de prendre le soin d'encoder et de décoder dans le même
encodage et d'indiquer aux utilisateurs l'encodage à utiliser.

Je croyais qu'on cherchait à avoir des bibliothèques toutes faites pour
éviter de réinventer la roue à chaque fois.

Et il est plus que risqué de fournir l'encodage dans le fichier lui-même

Plus risqué que quoi ?

(duplication d'information, le fichier contenant de lui-même dans quel
encodage il est), l'encodage déclaré n'étant pas forcément l'encodage
utilisé pour enregistrer le fichier (je peut marquer ISO-8859-1 dans mon
fichier mais l'enregistrer en UTF-8).

Déclarer l'encodage n'est pas une garantie qu'il n'y ait pas de problème,
mais ne pas le déclarer, c'est la garantie qu'il y aura des problèmes.

Non.

Si tu le déclares, c'est pour utiliser cette info. Sinon, c'est
juste idiot. Si tu le déclares et que tu pars du principe qu'il
pourra tout de même y avoir des problèmes, c'est aussi idiot puisque
tu sais a priori que ton information n'est pas fiable et que ça
pourra t'exploser à la figure.

Mes profs d'info m'ont toujours interdit d'avoir deux informations
redondantes dans un bout de code. Le fichier contient cette
information d'encodage par lui-même (sauf fichier pathologique, mais
pour un fichier texte, cela ne nous concerne pas). Il est donc
particulièrement con de rajouter cette information dans le même
fichier. Je t'ai déjà filé des URL de tels parsers, regarde un peu
comment ce code que tu as qualifié de débile est fait.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

On 19 oct, 01:21, Nicolas George <nicolas$geo...@salle-s.org> wrote:

Tu le rejettes avec un message d'erreur clair, et éventuellement avec l es
options offertes pour diverses tentatives de réparation partiellement
automatisées.

Y'a rien à réparer justement. Tout le fichier décodé est 100% corre ct,
lisible, exploitable, sans erreur ni corruption.
Juste que la personne qui a renseigné la déclaration s'est trompée. A u
contraire, il ne faut SURTOUT pas tenir compte de l'encodage déclaré,
sous peine de corrompre les données et de rendre le fichier illisible
et non exploitable.
La seule correction à faire serait de modifier l'encodage déclaré par
l'encodage réel du fichier, mais au final, on aurait complètement
shunté l'utilité de la déclaration et autant ne pas en tenir compte.

Sinon, tu n'as pas répondu à l'autre question:
Mon soft fonctionne en UTF8 et je reçoit un fichier encodé et déclar é
en UTF16. Je fais comment pour le décoder, vu qu'il faut que je l'ai
déjà décodé pour savoir ans quel encodage il est?

Le 18 Oct 2010 23:21:48 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :

Aeris , dans le message <4cbcd22a$0$11799$426a74cc@news.free.fr>, a
écrit :

Pour moi, déclarer un encodage ne fait qu'apporter de l'inconsistence en
plus.

Et tu dis ça comme si c'était une mauvaise chose. La redondance de
l'information, c'est une occasion de détecter une erreur. Un avertissement
explicite vaut infiniment mieux qu'une erreur qui se propage silencieusement
et corrompt des données.

Qu'est-ce qu'il ne faut pas lire... Je ne connais aucun éditeur de
texte qui utilise un encodage pour le début d'un fichier et un autre
pour la fin. Un fichier texte est toujours enregistré avec un
encodage cohérent. La connerie est de supposer qu'il est dans un
certain encodage (peut-être spécifié) et d'essayer de lire ce
fichier en ignorant les erreurs.

Je rajoute que si une mauvaise lecture d'un fichier de conf ne
génère par une erreur de lecture et corrompt des données, il faut
surtout changer de développeur !

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le Mon, 18 Oct 2010 19:54:36 +0200,
Aeris <aeris@imirhil.fr> écrivait :

JKB wrote:

Un fichier plat pose énormément de problèmes, parmis lesquels ceux citer
plus haut: gestion des échappements, délimiteurs de paramètres de
configuration, gestion des paramètres multilignes, caractères spéciaux...

Je ne vois pas pourquoi. J'ai écrit plusieurs 'parser' de fichiers
autrement plus complexes qu'un bête fichier plat avec des caractères
spéciaux. Il suffit de définir une syntaxe et de passer le truc dans
une moulinette écrite une fois pour toute. En fait, je ne vois pas
ce qui pose problème à un fichier texte et qui n'en poserait pas à
un fichier XML (sauf que les routines pour XML ont été écrites et
qu'il ne faut pas réinventer la roue et patati et patata !).

Comme tu le dis, ça réinvente la roue, et encore qu'en partie.
Ton parser maison aura toutes les chances d'être bien moins modulable et
clair qu'un fichier XML qui contient les mêmes données (surtout que cf
dernier point).

Mes fichiers de conf ressemblent à ça :

CANAL = { [ 1 0 2 ] [ 1 5 2 ] [ 1 4 2 ] }
PATH = "DISK$USERS:[PAESTUM.CONF]SIM.CFG;1"
...

Tu peux faire ça en XML, mais rien que pour les tables ou les
listes, ça devient rapidement illisible. Je suis d'une fainéantise
crasse et j'ai horreur de réinventer la roue, mais dans certains
cas, ça aide.

Rajouter un niveau d'imbrication dans le XML a toutes les chances d'être
rétrocompatible avec l'ancien fichier (les nouvelles balises seront
ignorées), déplacer un contenu au travers de l'arbre ne cassera pas le
fichier (les requètes xpath restent toujours valables). J'en doute beaucoup
plus sur ton parser maison.

Je ne dis pas que XML n'a pas des avantages. Je prétends seulement
qu'un gros fichier XML est illisible par un humain (ça n'a pas été
fait pour ça).

Un fichier XML, c'est une plaie dès qu'il devient complexe et qu'il
faut le modifier à la main !

Tout comme un parser maison devient extrèmement plus compliqué à maintenir
dès que la structure devient complexe, et encore pire la gueule du fichier
final (et les bugs qui vont avec)

Pourquoi ?

Surtout que sur le XML, il y a pléthores d'éditeurs XML qui valident en même
temps ton fichier et te guide dans la saisie, avec par exemple de
l'autocomplétion ou du WYSIWYG (comme l'excellent ExxEditor [1]).

Mes programmes, ils tournent sur des systèmes avec écran et
interface graphique et aussi sur des cartes de développement sur
lesquelles l'OS est minimal. Sur ces systèmes, tu as de la chance si
tu as un vi et certaines ne te permettent d'éditer une conf qu'à
grands coups de cat. Donc il _faut_ pourvoir écrire une conf du
premier coup sans erreur de syntaxe. C'est déjà assez difficile sans
rajouter XML.

Sans parler qu'il est difficile de structurer un fichier plat, qui n'est
rien de plus qu'une bouillie de lignes,

Mauvaise syntaxe, changer de syntaxe. Je peux te montrer des
fichiers plats parfaitement structurés (comme il en existe d'autres
qui sont illisibles).

Un fichier plat structuré, j'appelle ça du XML (ou en tout cas à un XSLT
près :)).

Non, ça peut, mais ça ne l'est pas forcément (ou au moins de façon
simple).

Et certes, faire du XML illisible, c'est possible, mais je pense qu'on a
largement moins de chance d'y parvenir qu'avec un langage maison.

Ah ?

Après si on veut du light, y'a d'autres langages que XML, JSON par exemple,
le tout étant de rester dans les langages structurés et non pas plat.

Mais partir de 0 et redéfinir son propre format, parser et syntaxe, c'est
non seulement inutile mais en plus fortement risqué (bug, évolutivité,
maintenance, compréhension...).

Là encore, ça dépend de ta façon de coder (et de ton niveau de
codage).

à l'inverse de XML ou des autres
langages structurés (JSON, YAML...) qui ordonnent et trient les
informations.

Mouais. Pas convaincu.

JKB

[1] http://dgp-public.gforge.inria.fr/fr/index.html

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr