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.
Par ailleurs, chaque fois que je cherche de la doc quand je veux faire
un truc un peu moins basique que d'habitude, je tombe sur le wiki
d'Ubuntu qui m'a bien aidé plus d'une fois. Je le trouve en fait assez
remarquable.
--
Olivier -- "On est comme tous les artistes, on croit à notre produit."
-+-groupe Début de Soirée-+-
Comme tu n'as pas compris comment fonctionnait une détection par maximum de vraisemblance.
Si ça peut te faire plaisir de le penser.
les cinq lignes plus haut.
Au hasard le bien connu parser XML (un vrai XML pas un XML light bricolé dans un coin). Je t'aide, celui que j'ai présentement sur ma machine fait juste 4,7 Mo de sources et
Et il faut autrement plus que juste détecter l'encodage.
JKB , dans le message <slrnibr5pv.gq8.jkb@rayleigh.systella.fr>, a
écrit :
Comme tu n'as
pas compris comment fonctionnait une détection par maximum de
vraisemblance.
Si ça peut te faire plaisir de le penser.
les cinq lignes plus haut.
Au hasard le bien connu parser XML (un
vrai XML pas un XML light bricolé dans un coin). Je t'aide, celui
que j'ai présentement sur ma machine fait juste 4,7 Mo de sources et
Et il faut autrement plus que juste détecter l'encodage.
Comme tu n'as pas compris comment fonctionnait une détection par maximum de vraisemblance.
Si ça peut te faire plaisir de le penser.
les cinq lignes plus haut.
Au hasard le bien connu parser XML (un vrai XML pas un XML light bricolé dans un coin). Je t'aide, celui que j'ai présentement sur ma machine fait juste 4,7 Mo de sources et
Et il faut autrement plus que juste détecter l'encodage.
Yliur
La déclaration de l'encodage n'apporte donc rien non plus, parce que dans ce cas tu fais l'hypothèse que si tu es capable de lire le champ attendu "encoding" du fichier, c'est que tu as bien décodé ton fichier (et à la limite, tu le connaissais déjà, c'est celui que tu as utilisé et tu peux jetter la déclaration à la poubelle). Et tu en reviens à faire la même hypothèse que moi sur l'ensemble du fichier. Ce n'est pas parce que tu auras lu UTF-16 dans le fichier qu'il s'agit de l'encodage, il peut simplement s'agit des 3 caractères 0x"UT" 0x"F-" 0x"16" en UTF-32.
En XML tu est censé lire la première ligne pour en déduire l'encodage, puis relire l'ensemble du fichier avec cet encodage. Et donc je crois que dans la première ligne il ne doit y avoir que des caractères ASCII (donc compatibles UTF-8). Mais là je ne suis pas sûr, parce que si UTF-16 est un encodage autorisé ton fichier doit être encodé dans deux encodages différents, ce qui devient assez compliqué...
La déclaration de l'encodage n'apporte donc rien non plus, parce que
dans ce cas tu fais l'hypothèse que si tu es capable de lire le champ
attendu "encoding" du fichier, c'est que tu as bien décodé ton fichier
(et à la limite, tu le connaissais déjà, c'est celui que tu as utilisé
et tu peux jetter la déclaration à la poubelle). Et tu en reviens à
faire la même hypothèse que moi sur l'ensemble du fichier. Ce n'est
pas parce que tu auras lu UTF-16 dans le fichier qu'il s'agit de
l'encodage, il peut simplement s'agit des 3 caractères 0x"UT" 0x"F-"
0x"16" en UTF-32.
En XML tu est censé lire la première ligne pour en déduire l'encodage,
puis relire l'ensemble du fichier avec cet encodage. Et donc je crois
que dans la première ligne il ne doit y avoir que des caractères ASCII
(donc compatibles UTF-8). Mais là je ne suis pas sûr, parce que si
UTF-16 est un encodage autorisé ton fichier doit être encodé dans deux
encodages différents, ce qui devient assez compliqué...
La déclaration de l'encodage n'apporte donc rien non plus, parce que dans ce cas tu fais l'hypothèse que si tu es capable de lire le champ attendu "encoding" du fichier, c'est que tu as bien décodé ton fichier (et à la limite, tu le connaissais déjà, c'est celui que tu as utilisé et tu peux jetter la déclaration à la poubelle). Et tu en reviens à faire la même hypothèse que moi sur l'ensemble du fichier. Ce n'est pas parce que tu auras lu UTF-16 dans le fichier qu'il s'agit de l'encodage, il peut simplement s'agit des 3 caractères 0x"UT" 0x"F-" 0x"16" en UTF-32.
En XML tu est censé lire la première ligne pour en déduire l'encodage, puis relire l'ensemble du fichier avec cet encodage. Et donc je crois que dans la première ligne il ne doit y avoir que des caractères ASCII (donc compatibles UTF-8). Mais là je ne suis pas sûr, parce que si UTF-16 est un encodage autorisé ton fichier doit être encodé dans deux encodages différents, ce qui devient assez compliqué...
Toxico Nimbus
Michel Talon a écrit :
JKB wrote:
Maintenant, je n'arrive pas à comprendre pourquoi il faut toujours faire compliqué. Un bon vieux fichier texte est ce qui se fait de mieux pour des fichiers de configuration.
C'est surtout ce qui a été fait pendant des décennies et qui marchait parfaitement bien, jusqu'à ce que des rigolos découvrent les machins "structurés" dont le seul avantage est qu'il faut avoir fait une maîtrise d'info pour comprendre comment ça marche.
Les machins structurés existaient bien avant, regarde le format IFF par exemple. L'imposture XML, c'est surtout de vouloir faire croire que ce format est modifiable par l'humain. Soit on encapsule vraiment en fournissant les softs pour éditer la config et à ce moment le problème du codage ne se pose pas puisqu'on fait du binaire, soit on fait de l'humain et là, le fichier conf plat et les répertoires suffit au bonheur de tout le monde.
-- Toxico Nimbus
Michel Talon a écrit :
JKB <jkb@koenigsberg.invalid> wrote:
Maintenant, je n'arrive pas à comprendre pourquoi il faut
toujours faire compliqué. Un bon vieux fichier texte est ce qui
se fait de mieux pour des fichiers de configuration.
C'est surtout ce qui a été fait pendant des décennies et qui marchait
parfaitement bien, jusqu'à ce que des rigolos découvrent les machins
"structurés" dont le seul avantage est qu'il faut avoir fait une
maîtrise d'info pour comprendre comment ça marche.
Les machins structurés existaient bien avant, regarde le format IFF par
exemple. L'imposture XML, c'est surtout de vouloir faire croire que ce
format est modifiable par l'humain. Soit on encapsule vraiment en
fournissant les softs pour éditer la config et à ce moment le problème du
codage ne se pose pas puisqu'on fait du binaire, soit on fait de l'humain
et là, le fichier conf plat et les répertoires suffit au bonheur de tout
le monde.
Maintenant, je n'arrive pas à comprendre pourquoi il faut toujours faire compliqué. Un bon vieux fichier texte est ce qui se fait de mieux pour des fichiers de configuration.
C'est surtout ce qui a été fait pendant des décennies et qui marchait parfaitement bien, jusqu'à ce que des rigolos découvrent les machins "structurés" dont le seul avantage est qu'il faut avoir fait une maîtrise d'info pour comprendre comment ça marche.
Les machins structurés existaient bien avant, regarde le format IFF par exemple. L'imposture XML, c'est surtout de vouloir faire croire que ce format est modifiable par l'humain. Soit on encapsule vraiment en fournissant les softs pour éditer la config et à ce moment le problème du codage ne se pose pas puisqu'on fait du binaire, soit on fait de l'humain et là, le fichier conf plat et les répertoires suffit au bonheur de tout le monde.
-- Toxico Nimbus
Nicolas George
Toxico Nimbus , dans le message <4cbdb130$0$10654$, a écrit :
L'imposture XML, c'est surtout de vouloir faire croire que ce format est modifiable par l'humain.
Tu peux expliciter en quoi c'est une imposture ? Une syntaxe XML bien conçue (en particulier qui utilise les attributs à bon escient) et un fichier bien indenté, c'est parfaitement éditable directement.
Toxico Nimbus , dans le message
<4cbdb130$0$10654$426a74cc@news.free.fr>, a écrit :
L'imposture XML, c'est surtout de vouloir faire croire que ce
format est modifiable par l'humain.
Tu peux expliciter en quoi c'est une imposture ? Une syntaxe XML bien conçue
(en particulier qui utilise les attributs à bon escient) et un fichier bien
indenté, c'est parfaitement éditable directement.
Toxico Nimbus , dans le message <4cbdb130$0$10654$, a écrit :
L'imposture XML, c'est surtout de vouloir faire croire que ce format est modifiable par l'humain.
Tu peux expliciter en quoi c'est une imposture ? Une syntaxe XML bien conçue (en particulier qui utilise les attributs à bon escient) et un fichier bien indenté, c'est parfaitement éditable directement.
JKB
Le 19 Oct 2010 15:06:25 GMT, Nicolas George <nicolas$ écrivait :
Toxico Nimbus , dans le message <4cbdb130$0$10654$, a écrit :
L'imposture XML, c'est surtout de vouloir faire croire que ce format est modifiable par l'humain.
Tu peux expliciter en quoi c'est une imposture ? Une syntaxe XML bien conçue (en particulier qui utilise les attributs à bon escient) et un fichier bien indenté, c'est parfaitement éditable directement.
Eh bien, on n'a pas du voir passer les mêmes. J'ai bricolé un éditeur pour me remettre d'équerre et réindenter du XML qui transite sur du webservices, et je te mets au défi de modifier directement ces fichiers même bien indentés. Ce serait fichu avec des parenthèses à la LISP, ce serait déjà un moindre mal, mais trouver un truc malformé dans un fichier XML de plusieurs dizaines de Ko, c'est juste une gageure quand il s'agit d'autre chose que d'une erreur grossière de syntaxe !
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 19 Oct 2010 15:06:25 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
Toxico Nimbus , dans le message
<4cbdb130$0$10654$426a74cc@news.free.fr>, a écrit :
L'imposture XML, c'est surtout de vouloir faire croire que ce
format est modifiable par l'humain.
Tu peux expliciter en quoi c'est une imposture ? Une syntaxe XML bien conçue
(en particulier qui utilise les attributs à bon escient) et un fichier bien
indenté, c'est parfaitement éditable directement.
Eh bien, on n'a pas du voir passer les mêmes. J'ai bricolé un
éditeur pour me remettre d'équerre et réindenter du XML qui transite
sur du webservices, et je te mets au défi de modifier directement
ces fichiers même bien indentés. Ce serait fichu avec des
parenthèses à la LISP, ce serait déjà un moindre mal, mais trouver
un truc malformé dans un fichier XML de plusieurs dizaines de Ko,
c'est juste une gageure quand il s'agit d'autre chose que d'une
erreur grossière de syntaxe !
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 19 Oct 2010 15:06:25 GMT, Nicolas George <nicolas$ écrivait :
Toxico Nimbus , dans le message <4cbdb130$0$10654$, a écrit :
L'imposture XML, c'est surtout de vouloir faire croire que ce format est modifiable par l'humain.
Tu peux expliciter en quoi c'est une imposture ? Une syntaxe XML bien conçue (en particulier qui utilise les attributs à bon escient) et un fichier bien indenté, c'est parfaitement éditable directement.
Eh bien, on n'a pas du voir passer les mêmes. J'ai bricolé un éditeur pour me remettre d'équerre et réindenter du XML qui transite sur du webservices, et je te mets au défi de modifier directement ces fichiers même bien indentés. Ce serait fichu avec des parenthèses à la LISP, ce serait déjà un moindre mal, mais trouver un truc malformé dans un fichier XML de plusieurs dizaines de Ko, c'est juste une gageure quand il s'agit d'autre chose que d'une erreur grossière de syntaxe !
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
Nicolas George
JKB , dans le message , a écrit :
Eh bien, on n'a pas du voir passer les mêmes. J'ai bricolé un éditeur pour me remettre d'équerre et réindenter du XML qui transite sur du webservices,
Là, on parlait de fichiers de configuration, pas de paquets dans un protocole réseau. Les deux ne sont pas optimisés pour la même chose.
JKB , dans le message <slrnibrd76.gq8.jkb@rayleigh.systella.fr>, a
écrit :
Eh bien, on n'a pas du voir passer les mêmes. J'ai bricolé un
éditeur pour me remettre d'équerre et réindenter du XML qui transite
sur du webservices,
Là, on parlait de fichiers de configuration, pas de paquets dans un
protocole réseau. Les deux ne sont pas optimisés pour la même chose.
Eh bien, on n'a pas du voir passer les mêmes. J'ai bricolé un éditeur pour me remettre d'équerre et réindenter du XML qui transite sur du webservices,
Là, on parlait de fichiers de configuration, pas de paquets dans un protocole réseau. Les deux ne sont pas optimisés pour la même chose.
JKB
Le 19 Oct 2010 16:15:05 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Eh bien, on n'a pas du voir passer les mêmes. J'ai bricolé un éditeur pour me remettre d'équerre et réindenter du XML qui transite sur du webservices,
Là, on parlait de fichiers de configuration, pas de paquets dans un protocole réseau. Les deux ne sont pas optimisés pour la même chose.
La structure est rigoureusement la même. Et j'ai des fichiers de conf de plusieurs dizaines de Ko pour des équipements de mesures (des histoires de calibration). Je n'ose imaginer les même fichier de conf en XML. Il faudrait vraiment être tordu !
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 19 Oct 2010 16:15:05 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnibrd76.gq8.jkb@rayleigh.systella.fr>, a
écrit :
Eh bien, on n'a pas du voir passer les mêmes. J'ai bricolé un
éditeur pour me remettre d'équerre et réindenter du XML qui transite
sur du webservices,
Là, on parlait de fichiers de configuration, pas de paquets dans un
protocole réseau. Les deux ne sont pas optimisés pour la même chose.
La structure est rigoureusement la même. Et j'ai des fichiers de
conf de plusieurs dizaines de Ko pour des équipements de mesures
(des histoires de calibration). Je n'ose imaginer les même fichier
de conf en XML. Il faudrait vraiment être tordu !
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 19 Oct 2010 16:15:05 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Eh bien, on n'a pas du voir passer les mêmes. J'ai bricolé un éditeur pour me remettre d'équerre et réindenter du XML qui transite sur du webservices,
Là, on parlait de fichiers de configuration, pas de paquets dans un protocole réseau. Les deux ne sont pas optimisés pour la même chose.
La structure est rigoureusement la même. Et j'ai des fichiers de conf de plusieurs dizaines de Ko pour des équipements de mesures (des histoires de calibration). Je n'ose imaginer les même fichier de conf en XML. Il faudrait vraiment être tordu !
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
Nicolas George
JKB , dans le message , a écrit :
La structure est rigoureusement la même.
Non, il y a des choix dans la structure qui peuvent changer énormément les choses, en particulier le choix d'utiliser un attribut ou un élément pour telle ou telle donnée.
JKB , dans le message <slrnibrhhi.gq8.jkb@rayleigh.systella.fr>, a
écrit :
La structure est rigoureusement la même.
Non, il y a des choix dans la structure qui peuvent changer énormément les
choses, en particulier le choix d'utiliser un attribut ou un élément pour
telle ou telle donnée.
Non, il y a des choix dans la structure qui peuvent changer énormément les choses, en particulier le choix d'utiliser un attribut ou un élément pour telle ou telle donnée.
JKB
Le 19 Oct 2010 16:38:48 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
La structure est rigoureusement la même.
Non, il y a des choix dans la structure qui peuvent changer énormément les choses, en particulier le choix d'utiliser un attribut ou un élément pour telle ou telle donnée.
La structure XML, c'est la structure du XML. Je te parle de _structure_ et de _lisibilité_ par un humain. Que ton XML navigue sur un réseau ou soit écrit dans un fichier, ça reste du XML. Après, on peut le faire plus uo moins salement. C'est un autre problème.
<EOT>
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 19 Oct 2010 16:38:48 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnibrhhi.gq8.jkb@rayleigh.systella.fr>, a
écrit :
La structure est rigoureusement la même.
Non, il y a des choix dans la structure qui peuvent changer énormément les
choses, en particulier le choix d'utiliser un attribut ou un élément pour
telle ou telle donnée.
La structure XML, c'est la structure du XML. Je te parle de
_structure_ et de _lisibilité_ par un humain. Que ton XML navigue
sur un réseau ou soit écrit dans un fichier, ça reste du XML. Après,
on peut le faire plus uo moins salement. C'est un autre problème.
<EOT>
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 19 Oct 2010 16:38:48 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
La structure est rigoureusement la même.
Non, il y a des choix dans la structure qui peuvent changer énormément les choses, en particulier le choix d'utiliser un attribut ou un élément pour telle ou telle donnée.
La structure XML, c'est la structure du XML. Je te parle de _structure_ et de _lisibilité_ par un humain. Que ton XML navigue sur un réseau ou soit écrit dans un fichier, ça reste du XML. Après, on peut le faire plus uo moins salement. C'est un autre problème.
<EOT>
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
Aeris
JKB wrote:
La lecture se fait en plusieurs étapes : 1/ lecture du fichier en mode binaire, stockage dans une table et analyse de la table à grands coups de métriques pour savoir dans quel encodage est le fichier. 2/ récupération de l'encodage ayant le meilleur taux de vraisemblance. 3/ si le taux est de 1, le fichier est correct. S'il est différent de 1, il y a une erreur et on envoie un message d'insulte en refusant de continuer. 4/ on relit le fichier en mode caractère (octet ou non) en
fonction
de l'encodage trouvé en supprimant les commentaires et les retours
à
la ligne. 5/ on convertit le fichier lu dans un encodage fixe et connu (par exemple UTF-8) en vérifiant soit que tous les caractères sont convertibles, soit qu'on remplace les caractères non convertibles par le caractère le plus proche dans l'encodage cible. 6/ on analyse la structure pour voir si ce contenu est cohérent (ne pas avoir par exemple de lignes comme A=1=1... Ou des délimiteurs qui ne sont pas fermés... Ça dépend de la syntaxe
utilisée).
7/ on analyse le contenu.
Donc si je résume, on part d'un bête fichier de configuration. On fout un gros coup d'analyse de grammaire contextuelle là dedans, une des pires à analyser informatiquement. On balance des probas dignes d'un docteur de mathématiques avancées pour l'informatique, à grand coup de calcul de vraisemblances, de probabilités... On fait un programme en logique floue pour être capable de gérer le cas du "proba encodage < 1" ou même "plusieurs encodages à proba maximale identique". On fait bien sûr 4 ou 5 lectures du fichier, et on prend bien soin de stocker tout ça dans de superbes grosses structures de données (qui pèseront 100x le fichier à lui tout seul), histoire qu'on ne puisse pas faire de lecture en flux continu (qui a dit SAX?). Ensuite là on prend son pied à gros coup d'algos bien goulus qui vont tripatouiller les structures dans tous les coins, histoire de trouver ce que ce fichier veut bien dire (ou pas). Et voila, on a un joli fichier de conf de 10ko........ et un algo probabilistique contextuel de 140MO qui ne peut pas tourner sur une machine à moins de 3Go de RAM et 4Ghz de CPU. Et encore, il n'a même pas le luxe d'avoir 100% de probabilité d'avoir détecter le bon encodage!
Je ne parle même pas de la complexité à y intégrer un nouvel encodage, à être robuste aux changements (oups, j'ai changé le format de mon fichier, je rappelle le docteur es Math et le linguisticien?), à résister à l'analyse d'un fichier de 10Mo (oups, NotEnoughMemoryException...), à avoir un code portable (oups, j'ai compilé sur une machine UTF8 mais je l'exécute sur une machine ISO88591).
Alors que tout ça se ramène exclusivement au point 5, ultra simpliste, performant, fiable, robuste, évolutif, maintenable: j'enregistre mon fichier en UTF8. Si je me plante à l'enregistrement, j'aurais de toute façon le droit à un gros message d'erreur insultant.
Ce qui est bien meilleur que de rendre les algos hyper-intelligent, au risque de prendre des décisions farfelues en voulant aller plus loin voire trop loin dans la détection d'erreur. Exemple à la con: ma proba n'était pas de 1 mais de .99, il y avait donc de bonnes raisons de le choisir, pas d'erreur à la lecture, pas d'erreur à l'interprétation... Pas de bol c'était le mauvais encodage (ISO-8859-1 et ISO-8859-15 ne diffèrent que de 8 caractères!) et ce truc m'a flingué mon PC pour avoir tenter par tous les moyens d'accepter un fichier qui aurait du être refusé depuis des lustres...
Merci bien, je vais garder mon XML/JSON en UTF-8 moi :)
JKB wrote:
La lecture se fait en plusieurs étapes :
1/ lecture du fichier en mode binaire, stockage dans une table et
analyse de la table à grands coups de métriques pour savoir dans
quel encodage est le fichier.
2/ récupération de l'encodage ayant le meilleur taux de
vraisemblance.
3/ si le taux est de 1, le fichier est correct. S'il est différent
de 1, il y a une erreur et on envoie un message d'insulte en
refusant de continuer.
4/ on relit le fichier en mode caractère (octet ou non) en
fonction
de l'encodage trouvé en supprimant les commentaires et les retours
à
la ligne.
5/ on convertit le fichier lu dans un encodage fixe et connu (par
exemple UTF-8) en vérifiant soit que tous les caractères sont
convertibles, soit qu'on remplace les caractères non convertibles
par le caractère le plus proche dans l'encodage cible.
6/ on analyse la structure pour voir si ce contenu est
cohérent (ne pas avoir par exemple de lignes comme A=1=1... Ou des
délimiteurs qui ne sont pas fermés... Ça dépend de la syntaxe
utilisée).
7/ on analyse le contenu.
Donc si je résume, on part d'un bête fichier de configuration.
On fout un gros coup d'analyse de grammaire contextuelle là dedans, une des
pires à analyser informatiquement.
On balance des probas dignes d'un docteur de mathématiques avancées pour
l'informatique, à grand coup de calcul de vraisemblances, de probabilités...
On fait un programme en logique floue pour être capable de gérer le cas du
"proba encodage < 1" ou même "plusieurs encodages à proba maximale
identique".
On fait bien sûr 4 ou 5 lectures du fichier, et on prend bien soin de
stocker tout ça dans de superbes grosses structures de données (qui pèseront
100x le fichier à lui tout seul), histoire qu'on ne puisse pas faire de
lecture en flux continu (qui a dit SAX?).
Ensuite là on prend son pied à gros coup d'algos bien goulus qui vont
tripatouiller les structures dans tous les coins, histoire de trouver ce que
ce fichier veut bien dire (ou pas).
Et voila, on a un joli fichier de conf de 10ko........ et un algo
probabilistique contextuel de 140MO qui ne peut pas tourner sur une machine
à moins de 3Go de RAM et 4Ghz de CPU. Et encore, il n'a même pas le luxe
d'avoir 100% de probabilité d'avoir détecter le bon encodage!
Je ne parle même pas de la complexité à y intégrer un nouvel encodage, à
être robuste aux changements (oups, j'ai changé le format de mon fichier, je
rappelle le docteur es Math et le linguisticien?), à résister à l'analyse
d'un fichier de 10Mo (oups, NotEnoughMemoryException...), à avoir un code
portable (oups, j'ai compilé sur une machine UTF8 mais je l'exécute sur une
machine ISO88591).
Alors que tout ça se ramène exclusivement au point 5, ultra simpliste,
performant, fiable, robuste, évolutif, maintenable: j'enregistre mon fichier
en UTF8.
Si je me plante à l'enregistrement, j'aurais de toute façon le droit à un
gros message d'erreur insultant.
Ce qui est bien meilleur que de rendre les algos hyper-intelligent, au
risque de prendre des décisions farfelues en voulant aller plus loin voire
trop loin dans la détection d'erreur.
Exemple à la con: ma proba n'était pas de 1 mais de .99, il y avait donc de
bonnes raisons de le choisir, pas d'erreur à la lecture, pas d'erreur à
l'interprétation... Pas de bol c'était le mauvais encodage (ISO-8859-1 et
ISO-8859-15 ne diffèrent que de 8 caractères!) et ce truc m'a flingué mon PC
pour avoir tenter par tous les moyens d'accepter un fichier qui aurait du
être refusé depuis des lustres...
Merci bien, je vais garder mon XML/JSON en UTF-8 moi :)
La lecture se fait en plusieurs étapes : 1/ lecture du fichier en mode binaire, stockage dans une table et analyse de la table à grands coups de métriques pour savoir dans quel encodage est le fichier. 2/ récupération de l'encodage ayant le meilleur taux de vraisemblance. 3/ si le taux est de 1, le fichier est correct. S'il est différent de 1, il y a une erreur et on envoie un message d'insulte en refusant de continuer. 4/ on relit le fichier en mode caractère (octet ou non) en
fonction
de l'encodage trouvé en supprimant les commentaires et les retours
à
la ligne. 5/ on convertit le fichier lu dans un encodage fixe et connu (par exemple UTF-8) en vérifiant soit que tous les caractères sont convertibles, soit qu'on remplace les caractères non convertibles par le caractère le plus proche dans l'encodage cible. 6/ on analyse la structure pour voir si ce contenu est cohérent (ne pas avoir par exemple de lignes comme A=1=1... Ou des délimiteurs qui ne sont pas fermés... Ça dépend de la syntaxe
utilisée).
7/ on analyse le contenu.
Donc si je résume, on part d'un bête fichier de configuration. On fout un gros coup d'analyse de grammaire contextuelle là dedans, une des pires à analyser informatiquement. On balance des probas dignes d'un docteur de mathématiques avancées pour l'informatique, à grand coup de calcul de vraisemblances, de probabilités... On fait un programme en logique floue pour être capable de gérer le cas du "proba encodage < 1" ou même "plusieurs encodages à proba maximale identique". On fait bien sûr 4 ou 5 lectures du fichier, et on prend bien soin de stocker tout ça dans de superbes grosses structures de données (qui pèseront 100x le fichier à lui tout seul), histoire qu'on ne puisse pas faire de lecture en flux continu (qui a dit SAX?). Ensuite là on prend son pied à gros coup d'algos bien goulus qui vont tripatouiller les structures dans tous les coins, histoire de trouver ce que ce fichier veut bien dire (ou pas). Et voila, on a un joli fichier de conf de 10ko........ et un algo probabilistique contextuel de 140MO qui ne peut pas tourner sur une machine à moins de 3Go de RAM et 4Ghz de CPU. Et encore, il n'a même pas le luxe d'avoir 100% de probabilité d'avoir détecter le bon encodage!
Je ne parle même pas de la complexité à y intégrer un nouvel encodage, à être robuste aux changements (oups, j'ai changé le format de mon fichier, je rappelle le docteur es Math et le linguisticien?), à résister à l'analyse d'un fichier de 10Mo (oups, NotEnoughMemoryException...), à avoir un code portable (oups, j'ai compilé sur une machine UTF8 mais je l'exécute sur une machine ISO88591).
Alors que tout ça se ramène exclusivement au point 5, ultra simpliste, performant, fiable, robuste, évolutif, maintenable: j'enregistre mon fichier en UTF8. Si je me plante à l'enregistrement, j'aurais de toute façon le droit à un gros message d'erreur insultant.
Ce qui est bien meilleur que de rendre les algos hyper-intelligent, au risque de prendre des décisions farfelues en voulant aller plus loin voire trop loin dans la détection d'erreur. Exemple à la con: ma proba n'était pas de 1 mais de .99, il y avait donc de bonnes raisons de le choisir, pas d'erreur à la lecture, pas d'erreur à l'interprétation... Pas de bol c'était le mauvais encodage (ISO-8859-1 et ISO-8859-15 ne diffèrent que de 8 caractères!) et ce truc m'a flingué mon PC pour avoir tenter par tous les moyens d'accepter un fichier qui aurait du être refusé depuis des lustres...
Merci bien, je vais garder mon XML/JSON en UTF-8 moi :)
