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-+-
Tu dis absolument n'importe quoi. Si le fichier est décodé comme de l 'UTF-8 alors qu'il s'était en fait retrouvé encodé en ISO-8859-1, il est i nvalide quasiment au premier caractère accentué. Dans l'autre sens, c'est inf iniment plus insidieux : si le fichier est décodé comme de l'ISO-8859-1 alo rs qu'il s'était retrouvé encodé en UTF-8, alors aucune erreur ne sera dét ectée, mais tous les caractères accentués seront transformés en charabia.
C'est toi qui lit n'importe quoi. Je n'ai pas demandé comment tu gères un fichier qui devrait être en UTF8 mais se retrouve en UTF16 par un miracle quelconque, mais comment tu gères le cas d'un fichier encodé UTF8 et décodé UTF8 tout à fait correctement mais qui déclare un encodage utilisé en UTF16 une fois le décodage fait. Ma lecture et mon écriture se passe sans aucune erreur, j'ai mes données 100% exploitables car décodées correctement, c'est juste le gus qui a rédigé le fichier qui s'est planté dans sa déclaration. Je fais quoi? Je redécode le fichier en UTF16? En corrompant tout au passage? Ou j'accepte l'encodage UTF8 utilisé par le fichier?
Cas d'une appli UTF8 Déclaration UTF8 OK UTF8, Encodage UTF8 OK => Décodage UTF8, donc décodage = encodage Déclaration UTF8 OK, Encodage UTF16 merdique => Décodage impossible, pour décoder l'encodage déclaré il faudrait déjà le connaître p our pouvoir décoder le fichier Déclaration UTF16 merdique, Encodage UTF8 OK => Décodage UTF8 tout à fait correct, donc décodage = encodage Déclaration UTF16 merdique, Encodage UTF16 merdique => Décodage impossible, on n'a aucun moyen de connaître l'encodage du fichier sauf à essayer tous les encodages possibles et immaginables, et encore c'est pas parce que ça aura été décodé sans erreur que ça sera décodé correctement (un décodage UTF32 passera sans aucune erreur, mais avec des données complètement corrompues)
Au final, si tu regardes bien les 4 cas possibles, les 2 seuls qui conduisent à une situation viable sont ceux ou encodage du codage = encodage du décodage, indépendamment de l'encodage déclaré, qui ne sert donc strictement à rien.
On 19 oct, 11:04, Nicolas George <nicolas$geo...@salle-s.org> wrote:
Tu dis absolument n'importe quoi. Si le fichier est décodé comme de l 'UTF-8
alors qu'il s'était en fait retrouvé encodé en ISO-8859-1, il est i nvalide
quasiment au premier caractère accentué. Dans l'autre sens, c'est inf iniment
plus insidieux : si le fichier est décodé comme de l'ISO-8859-1 alo rs qu'il
s'était retrouvé encodé en UTF-8, alors aucune erreur ne sera dét ectée, mais
tous les caractères accentués seront transformés en charabia.
C'est toi qui lit n'importe quoi. Je n'ai pas demandé comment tu gères
un fichier qui devrait être en UTF8 mais se retrouve en UTF16 par un
miracle quelconque, mais comment tu gères le cas d'un fichier encodé
UTF8 et décodé UTF8 tout à fait correctement mais qui déclare un
encodage utilisé en UTF16 une fois le décodage fait.
Ma lecture et mon écriture se passe sans aucune erreur, j'ai mes
données 100% exploitables car décodées correctement, c'est juste le
gus qui a rédigé le fichier qui s'est planté dans sa déclaration.
Je fais quoi? Je redécode le fichier en UTF16? En corrompant tout au
passage? Ou j'accepte l'encodage UTF8 utilisé par le fichier?
Cas d'une appli UTF8
Déclaration UTF8 OK UTF8, Encodage UTF8 OK => Décodage UTF8, donc
décodage = encodage
Déclaration UTF8 OK, Encodage UTF16 merdique => Décodage impossible,
pour décoder l'encodage déclaré il faudrait déjà le connaître p our
pouvoir décoder le fichier
Déclaration UTF16 merdique, Encodage UTF8 OK => Décodage UTF8 tout à
fait correct, donc décodage = encodage
Déclaration UTF16 merdique, Encodage UTF16 merdique => Décodage
impossible, on n'a aucun moyen de connaître l'encodage du fichier sauf
à essayer tous les encodages possibles et immaginables, et encore
c'est pas parce que ça aura été décodé sans erreur que ça sera décodé
correctement (un décodage UTF32 passera sans aucune erreur, mais avec
des données complètement corrompues)
Au final, si tu regardes bien les 4 cas possibles, les 2 seuls qui
conduisent à une situation viable sont ceux ou encodage du codage =
encodage du décodage, indépendamment de l'encodage déclaré, qui ne
sert donc strictement à rien.
Tu dis absolument n'importe quoi. Si le fichier est décodé comme de l 'UTF-8 alors qu'il s'était en fait retrouvé encodé en ISO-8859-1, il est i nvalide quasiment au premier caractère accentué. Dans l'autre sens, c'est inf iniment plus insidieux : si le fichier est décodé comme de l'ISO-8859-1 alo rs qu'il s'était retrouvé encodé en UTF-8, alors aucune erreur ne sera dét ectée, mais tous les caractères accentués seront transformés en charabia.
C'est toi qui lit n'importe quoi. Je n'ai pas demandé comment tu gères un fichier qui devrait être en UTF8 mais se retrouve en UTF16 par un miracle quelconque, mais comment tu gères le cas d'un fichier encodé UTF8 et décodé UTF8 tout à fait correctement mais qui déclare un encodage utilisé en UTF16 une fois le décodage fait. Ma lecture et mon écriture se passe sans aucune erreur, j'ai mes données 100% exploitables car décodées correctement, c'est juste le gus qui a rédigé le fichier qui s'est planté dans sa déclaration. Je fais quoi? Je redécode le fichier en UTF16? En corrompant tout au passage? Ou j'accepte l'encodage UTF8 utilisé par le fichier?
Cas d'une appli UTF8 Déclaration UTF8 OK UTF8, Encodage UTF8 OK => Décodage UTF8, donc décodage = encodage Déclaration UTF8 OK, Encodage UTF16 merdique => Décodage impossible, pour décoder l'encodage déclaré il faudrait déjà le connaître p our pouvoir décoder le fichier Déclaration UTF16 merdique, Encodage UTF8 OK => Décodage UTF8 tout à fait correct, donc décodage = encodage Déclaration UTF16 merdique, Encodage UTF16 merdique => Décodage impossible, on n'a aucun moyen de connaître l'encodage du fichier sauf à essayer tous les encodages possibles et immaginables, et encore c'est pas parce que ça aura été décodé sans erreur que ça sera décodé correctement (un décodage UTF32 passera sans aucune erreur, mais avec des données complètement corrompues)
Au final, si tu regardes bien les 4 cas possibles, les 2 seuls qui conduisent à une situation viable sont ceux ou encodage du codage = encodage du décodage, indépendamment de l'encodage déclaré, qui ne sert donc strictement à rien.
talon
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.
--
Michel TALON
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.
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.
--
Michel TALON
JKB
Le 19 Oct 2010 12:22:50 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Pour ton information, l'outil de détection fait 450 Ko de sources,
... Mais à part ça, Madame la Marquise...
Tu n'as rien de plus intelligent à dire ?
-- 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 12:22:50 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnibr2uu.gq8.jkb@rayleigh.systella.fr>, a
écrit :
Pour ton information, l'outil de détection fait 450 Ko de sources,
... Mais à part ça, Madame la Marquise...
Tu n'as rien de plus intelligent à dire ?
--
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 12:22:50 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Pour ton information, l'outil de détection fait 450 Ko de sources,
... Mais à part ça, Madame la Marquise...
Tu n'as rien de plus intelligent à dire ?
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
talon
Vivien MOREAU <vpm+ wrote:
On 2010-10-19, Michel Talon wrote:
> Ca serait trop demander qu'un fichier de *configuration* soit en ASCII 7 > bits pur et dur? Les diptères de votre salle de sciences doivent avoir > particulièrement mal au fondement.
En plus d'interdire plus de dix connexions simultanées sur Internet, tu souhaiterais supprimer les accents et autres caractères non-ASCII dans toutes les langues ?
Programme formidable. :-)
On parle de fichiers de configuration, pas de texte en général. J'ai du mal à voir ce que les caractères accentués viennent faire là dedans. On a mentionné les commentaires, si ceux ci commencent par un marqueur, tel que # // etc. il suffit de virer tout jusqu'au bout de ligne, là encore il n'y a pas de gros problèmes métaphysiques sur l'encodage. Nicolas qui est plus futé a besoin de personnaliser son prompt avec des caractères accentués, ça me laisse sans argument.
--
Michel TALON
Vivien MOREAU <vpm+news@serengetty.fr> wrote:
On 2010-10-19, Michel Talon wrote:
> Ca serait trop demander qu'un fichier de *configuration* soit en ASCII 7
> bits pur et dur? Les diptères de votre salle de sciences doivent avoir
> particulièrement mal au fondement.
En plus d'interdire plus de dix connexions simultanées sur Internet, tu
souhaiterais supprimer les accents et autres caractères non-ASCII dans
toutes les langues ?
Programme formidable. :-)
On parle de fichiers de configuration, pas de texte en général. J'ai du
mal à voir ce que les caractères accentués viennent faire là dedans. On
a mentionné les commentaires, si ceux ci commencent par un marqueur, tel
que # // etc. il suffit de virer tout jusqu'au bout de ligne, là encore
il n'y a pas de gros problèmes métaphysiques sur l'encodage. Nicolas
qui est plus futé a besoin de personnaliser son prompt avec des
caractères accentués, ça me laisse sans argument.
> Ca serait trop demander qu'un fichier de *configuration* soit en ASCII 7 > bits pur et dur? Les diptères de votre salle de sciences doivent avoir > particulièrement mal au fondement.
En plus d'interdire plus de dix connexions simultanées sur Internet, tu souhaiterais supprimer les accents et autres caractères non-ASCII dans toutes les langues ?
Programme formidable. :-)
On parle de fichiers de configuration, pas de texte en général. J'ai du mal à voir ce que les caractères accentués viennent faire là dedans. On a mentionné les commentaires, si ceux ci commencent par un marqueur, tel que # // etc. il suffit de virer tout jusqu'au bout de ligne, là encore il n'y a pas de gros problèmes métaphysiques sur l'encodage. Nicolas qui est plus futé a besoin de personnaliser son prompt avec des caractères accentués, ça me laisse sans argument.
--
Michel TALON
Nicolas George
Aeris , dans le message , a écrit :
Je n'ai pas demandé comment tu gères un fichier qui devrait être en UTF8 mais se retrouve en UTF16 par un miracle quelconque, mais comment tu gères le cas d'un fichier encodé UTF8 et décodé UTF8 tout à fait correctement mais qui déclare un encodage utilisé en UTF16 une fois le décodage fait.
Je t'ai répondu : tu signales une erreur et tu attends que l'utilisateur corrige.
Ma lecture et mon écriture se passe sans aucune erreur, j'ai mes données 100% exploitables car décodées correctement, c'est juste le gus qui a rédigé le fichier qui s'est planté dans sa déclaration.
C'est juste... Tu n'en sais rien. Les données ont l'air exploitables, mais tu n'as aucune idée de l'enchaînement d'erreurs qui ont pu conduire à cette incohérence d'encodage. Dans ces conditions, continuer à traiter le fichier comme si de rien n'était est une négligence criminelle. Il _faut_ une intervention de l'utilisateur pour vérifier la nature exacte du problème.
De fait, neuf fois sur dix il s'agira « juste » de remettre la déclaration d'encodage correcte. Mais c'est la dixième fois qui te permettra de passer pour un con avec un symbole euro mal encodé sur un prospectus tiré à un million d'exemplaires.
Aeris , dans le message
<34fb7975-c7df-4eb9-bd07-3609a614edd1@j2g2000yqf.googlegroups.com>, a
écrit :
Je n'ai pas demandé comment tu gères
un fichier qui devrait être en UTF8 mais se retrouve en UTF16 par un
miracle quelconque, mais comment tu gères le cas d'un fichier encodé
UTF8 et décodé UTF8 tout à fait correctement mais qui déclare un
encodage utilisé en UTF16 une fois le décodage fait.
Je t'ai répondu : tu signales une erreur et tu attends que l'utilisateur
corrige.
Ma lecture et mon écriture se passe sans aucune erreur, j'ai mes
données 100% exploitables car décodées correctement, c'est juste le
gus qui a rédigé le fichier qui s'est planté dans sa déclaration.
C'est juste... Tu n'en sais rien. Les données ont l'air exploitables, mais
tu n'as aucune idée de l'enchaînement d'erreurs qui ont pu conduire à cette
incohérence d'encodage. Dans ces conditions, continuer à traiter le fichier
comme si de rien n'était est une négligence criminelle. Il _faut_ une
intervention de l'utilisateur pour vérifier la nature exacte du problème.
De fait, neuf fois sur dix il s'agira « juste » de remettre la déclaration
d'encodage correcte. Mais c'est la dixième fois qui te permettra de passer
pour un con avec un symbole euro mal encodé sur un prospectus tiré à un
million d'exemplaires.
Je n'ai pas demandé comment tu gères un fichier qui devrait être en UTF8 mais se retrouve en UTF16 par un miracle quelconque, mais comment tu gères le cas d'un fichier encodé UTF8 et décodé UTF8 tout à fait correctement mais qui déclare un encodage utilisé en UTF16 une fois le décodage fait.
Je t'ai répondu : tu signales une erreur et tu attends que l'utilisateur corrige.
Ma lecture et mon écriture se passe sans aucune erreur, j'ai mes données 100% exploitables car décodées correctement, c'est juste le gus qui a rédigé le fichier qui s'est planté dans sa déclaration.
C'est juste... Tu n'en sais rien. Les données ont l'air exploitables, mais tu n'as aucune idée de l'enchaînement d'erreurs qui ont pu conduire à cette incohérence d'encodage. Dans ces conditions, continuer à traiter le fichier comme si de rien n'était est une négligence criminelle. Il _faut_ une intervention de l'utilisateur pour vérifier la nature exacte du problème.
De fait, neuf fois sur dix il s'agira « juste » de remettre la déclaration d'encodage correcte. Mais c'est la dixième fois qui te permettra de passer pour un con avec un symbole euro mal encodé sur un prospectus tiré à un million d'exemplaires.
Nicolas George
JKB , dans le message , a écrit :
Tu n'as rien de plus intelligent à dire ?
Non, quand tu proposes un demi méga-octet de code (pour ceux qui n'ont pas les ordres de grandeur en tête, la totalité de l'interpréteur lua fait environ deux fois moins) pour faire une détection qui risque quand même de se tromper, je n'ai rien de plus intelligent à faire que laisser l'absurdité de ton propos parler d'elle-même.
JKB , dans le message <slrnibr44q.gq8.jkb@rayleigh.systella.fr>, a
écrit :
Tu n'as rien de plus intelligent à dire ?
Non, quand tu proposes un demi méga-octet de code (pour ceux qui n'ont pas
les ordres de grandeur en tête, la totalité de l'interpréteur lua fait
environ deux fois moins) pour faire une détection qui risque quand même de
se tromper, je n'ai rien de plus intelligent à faire que laisser l'absurdité
de ton propos parler d'elle-même.
Non, quand tu proposes un demi méga-octet de code (pour ceux qui n'ont pas les ordres de grandeur en tête, la totalité de l'interpréteur lua fait environ deux fois moins) pour faire une détection qui risque quand même de se tromper, je n'ai rien de plus intelligent à faire que laisser l'absurdité de ton propos parler d'elle-même.
Aeris
On 19 oct, 14:48, Nicolas George <nicolas$ wrote:
C'est juste... Tu n'en sais rien. Les données ont l'air exploitables, m ais tu n'as aucune idée de l'enchaînement d'erreurs qui ont pu conduire à cette incohérence d'encodage. Dans ces conditions, continuer à traiter le f ichier comme si de rien n'était est une négligence criminelle. Il _faut_ une intervention de l'utilisateur pour vérifier la nature exacte du probl ème.
De fait, neuf fois sur dix il s'agira « juste » de remettre la d éclaration d'encodage correcte. Mais c'est la dixième fois qui te permettra de pas ser pour un con avec un symbole euro mal encodé sur un prospectus tiré à un million d'exemplaires.
On est donc bien d'accord qu'on a aucun moyen de dire qu'une lecture sans erreur du fichier ne veut pas dire une lecture correcte (décodage en UTF16 d'un texte UTF8 par exemple).
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.
Autant se limiter à "je décode mon fichier en UTF8, si j'ai pas d'erreur, je tente de l'utiliser en accédant à ses données, si j'ai pas d'erreur avant la fin de l'analyse, alors j'ai bien fait mon travail. Si j'ai la moindre erreur au décodage ou à l'accès, alors je préviens que le fichier n'est pas correct et j'affiche mon message d'erreur à l'utilisateur". Je n'ai absolument pas besoin de déclarer mon encodage.
On 19 oct, 14:48, Nicolas George <nicolas$geo...@salle-s.org> wrote:
C'est juste... Tu n'en sais rien. Les données ont l'air exploitables, m ais
tu n'as aucune idée de l'enchaînement d'erreurs qui ont pu conduire à cette
incohérence d'encodage. Dans ces conditions, continuer à traiter le f ichier
comme si de rien n'était est une négligence criminelle. Il _faut_ une
intervention de l'utilisateur pour vérifier la nature exacte du probl ème.
De fait, neuf fois sur dix il s'agira « juste » de remettre la d éclaration
d'encodage correcte. Mais c'est la dixième fois qui te permettra de pas ser
pour un con avec un symbole euro mal encodé sur un prospectus tiré à un
million d'exemplaires.
On est donc bien d'accord qu'on a aucun moyen de dire qu'une lecture
sans erreur du fichier ne veut pas dire une lecture correcte (décodage
en UTF16 d'un texte UTF8 par exemple).
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.
Autant se limiter à "je décode mon fichier en UTF8, si j'ai pas
d'erreur, je tente de l'utiliser en accédant à ses données, si j'ai
pas d'erreur avant la fin de l'analyse, alors j'ai bien fait mon
travail. Si j'ai la moindre erreur au décodage ou à l'accès, alors je
préviens que le fichier n'est pas correct et j'affiche mon message
d'erreur à l'utilisateur". Je n'ai absolument pas besoin de déclarer
mon encodage.
C'est juste... Tu n'en sais rien. Les données ont l'air exploitables, m ais tu n'as aucune idée de l'enchaînement d'erreurs qui ont pu conduire à cette incohérence d'encodage. Dans ces conditions, continuer à traiter le f ichier comme si de rien n'était est une négligence criminelle. Il _faut_ une intervention de l'utilisateur pour vérifier la nature exacte du probl ème.
De fait, neuf fois sur dix il s'agira « juste » de remettre la d éclaration d'encodage correcte. Mais c'est la dixième fois qui te permettra de pas ser pour un con avec un symbole euro mal encodé sur un prospectus tiré à un million d'exemplaires.
On est donc bien d'accord qu'on a aucun moyen de dire qu'une lecture sans erreur du fichier ne veut pas dire une lecture correcte (décodage en UTF16 d'un texte UTF8 par exemple).
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.
Autant se limiter à "je décode mon fichier en UTF8, si j'ai pas d'erreur, je tente de l'utiliser en accédant à ses données, si j'ai pas d'erreur avant la fin de l'analyse, alors j'ai bien fait mon travail. Si j'ai la moindre erreur au décodage ou à l'accès, alors je préviens que le fichier n'est pas correct et j'affiche mon message d'erreur à l'utilisateur". Je n'ai absolument pas besoin de déclarer mon encodage.
Nicolas George
Michel Talon, dans le message <i9k3ef$1qsv$, a écrit :
On parle de fichiers de configuration, pas de texte en général. J'ai du mal à voir ce que les caractères accentués viennent faire là dedans. On a mentionné les commentaires, si ceux ci commencent par un marqueur, tel que # // etc. il suffit de virer tout jusqu'au bout de ligne, là encore il n'y a pas de gros problèmes métaphysiques sur l'encodage. Nicolas qui est plus futé a besoin de personnaliser son prompt avec des caractères accentués, ça me laisse sans argument.
Tu veux d'autres exemples, tu n'es pas assez « futé » pour les trouver tout seul ?
- Le nom d'un utilisateur pour n'importe quel logiciel qui l'affiche, le stocke ou l'envoie (typiquement, un mailer dans le champ from).
- L'adresse postale de l'expéditeur pour un logiciel de publipostage.
- Le bref descriptif de la liste et le message de bienvenue pour la configuration d'une mailing-list.
...
Michel Talon, dans le message <i9k3ef$1qsv$2@asmodee.lpthe.jussieu.fr>,
a écrit :
On parle de fichiers de configuration, pas de texte en général. J'ai du
mal à voir ce que les caractères accentués viennent faire là dedans. On
a mentionné les commentaires, si ceux ci commencent par un marqueur, tel
que # // etc. il suffit de virer tout jusqu'au bout de ligne, là encore
il n'y a pas de gros problèmes métaphysiques sur l'encodage. Nicolas
qui est plus futé a besoin de personnaliser son prompt avec des
caractères accentués, ça me laisse sans argument.
Tu veux d'autres exemples, tu n'es pas assez « futé » pour les trouver tout
seul ?
- Le nom d'un utilisateur pour n'importe quel logiciel qui l'affiche, le
stocke ou l'envoie (typiquement, un mailer dans le champ from).
- L'adresse postale de l'expéditeur pour un logiciel de publipostage.
- Le bref descriptif de la liste et le message de bienvenue pour la
configuration d'une mailing-list.
Michel Talon, dans le message <i9k3ef$1qsv$, a écrit :
On parle de fichiers de configuration, pas de texte en général. J'ai du mal à voir ce que les caractères accentués viennent faire là dedans. On a mentionné les commentaires, si ceux ci commencent par un marqueur, tel que # // etc. il suffit de virer tout jusqu'au bout de ligne, là encore il n'y a pas de gros problèmes métaphysiques sur l'encodage. Nicolas qui est plus futé a besoin de personnaliser son prompt avec des caractères accentués, ça me laisse sans argument.
Tu veux d'autres exemples, tu n'es pas assez « futé » pour les trouver tout seul ?
- Le nom d'un utilisateur pour n'importe quel logiciel qui l'affiche, le stocke ou l'envoie (typiquement, un mailer dans le champ from).
- L'adresse postale de l'expéditeur pour un logiciel de publipostage.
- Le bref descriptif de la liste et le message de bienvenue pour la configuration d'une mailing-list.
...
JKB
Le 19 Oct 2010 12:53:01 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Tu n'as rien de plus intelligent à dire ?
Non, quand tu proposes un demi méga-octet de code (pour ceux qui n'ont pas les ordres de grandeur en tête, la totalité de l'interpréteur lua fait environ deux fois moins) pour faire une détection qui risque quand même de se tromper, je n'ai rien de plus intelligent à faire que laisser l'absurdité de ton propos parler d'elle-même.
Relis _attentivement_ pour une fois ce que j'ai écrit avant de foncer tête baissée dans le panneau. Tu viens juste de prouver que tu n'as pas lu (ou pas compris) ce que j'avais écrit. Comme tu n'as pas compris comment fonctionnait une détection par maximum de vraisemblance. Ça t'éviterait juste de dire deux grosses conneries dans les cinq lignes plus haut.
Rappelle-moi aussi la longueur du code d'un parser classique histoire de rigoler un peu. 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 c'est celui qui est distribué par debian. Donc permet-moi de rigoler.
Au passage, j'aimerais bien savoir ce que fiche Lua ici. Le parser Lua n'est certainement pas générique.
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 12:53:01 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnibr44q.gq8.jkb@rayleigh.systella.fr>, a
écrit :
Tu n'as rien de plus intelligent à dire ?
Non, quand tu proposes un demi méga-octet de code (pour ceux qui n'ont pas
les ordres de grandeur en tête, la totalité de l'interpréteur lua fait
environ deux fois moins) pour faire une détection qui risque quand même de
se tromper, je n'ai rien de plus intelligent à faire que laisser l'absurdité
de ton propos parler d'elle-même.
Relis _attentivement_ pour une fois ce que j'ai écrit avant de
foncer tête baissée dans le panneau. Tu viens juste de prouver que
tu n'as pas lu (ou pas compris) ce que j'avais écrit. Comme tu n'as
pas compris comment fonctionnait une détection par maximum de
vraisemblance. Ça t'éviterait juste de dire deux grosses conneries dans
les cinq lignes plus haut.
Rappelle-moi aussi la longueur du code d'un parser classique
histoire de rigoler un peu. 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
c'est celui qui est distribué par debian. Donc permet-moi de rigoler.
Au passage, j'aimerais bien savoir ce que fiche Lua ici. Le parser
Lua n'est certainement pas générique.
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 12:53:01 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Tu n'as rien de plus intelligent à dire ?
Non, quand tu proposes un demi méga-octet de code (pour ceux qui n'ont pas les ordres de grandeur en tête, la totalité de l'interpréteur lua fait environ deux fois moins) pour faire une détection qui risque quand même de se tromper, je n'ai rien de plus intelligent à faire que laisser l'absurdité de ton propos parler d'elle-même.
Relis _attentivement_ pour une fois ce que j'ai écrit avant de foncer tête baissée dans le panneau. Tu viens juste de prouver que tu n'as pas lu (ou pas compris) ce que j'avais écrit. Comme tu n'as pas compris comment fonctionnait une détection par maximum de vraisemblance. Ça t'éviterait juste de dire deux grosses conneries dans les cinq lignes plus haut.
Rappelle-moi aussi la longueur du code d'un parser classique histoire de rigoler un peu. 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 c'est celui qui est distribué par debian. Donc permet-moi de rigoler.
Au passage, j'aimerais bien savoir ce que fiche Lua ici. Le parser Lua n'est certainement pas générique.
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
Aeris , dans le message , a écrit :
On est donc bien d'accord qu'on a aucun moyen de dire qu'une lecture sans erreur du fichier ne veut pas dire une lecture correcte (décodage en UTF16 d'un texte UTF8 par exemple).
Oui.
La déclaration de l'encodage n'apporte donc rien non plus, parce que
Si : elle apporte une occasion supplémentaire de détecter une erreur.
Autant se limiter à "je décode mon fichier en UTF8
Ce qui revient à dire que le seul encodage accepté est UTF-8. Comme je l'ai dit dans un autre message, que tu n'as peut-être pas vu, je trouve ça tout à fait acceptable, _à condition_ que ce soit énoncé explicitement.
Aeris , dans le message
<b32b265d-8b95-4a49-b8b3-dcfad7aa3085@k22g2000yqh.googlegroups.com>, a
écrit :
On est donc bien d'accord qu'on a aucun moyen de dire qu'une lecture
sans erreur du fichier ne veut pas dire une lecture correcte (décodage
en UTF16 d'un texte UTF8 par exemple).
Oui.
La déclaration de l'encodage n'apporte donc rien non plus, parce que
Si : elle apporte une occasion supplémentaire de détecter une erreur.
Autant se limiter à "je décode mon fichier en UTF8
Ce qui revient à dire que le seul encodage accepté est UTF-8. Comme je l'ai
dit dans un autre message, que tu n'as peut-être pas vu, je trouve ça tout à
fait acceptable, _à condition_ que ce soit énoncé explicitement.
On est donc bien d'accord qu'on a aucun moyen de dire qu'une lecture sans erreur du fichier ne veut pas dire une lecture correcte (décodage en UTF16 d'un texte UTF8 par exemple).
Oui.
La déclaration de l'encodage n'apporte donc rien non plus, parce que
Si : elle apporte une occasion supplémentaire de détecter une erreur.
Autant se limiter à "je décode mon fichier en UTF8
Ce qui revient à dire que le seul encodage accepté est UTF-8. Comme je l'ai dit dans un autre message, que tu n'as peut-être pas vu, je trouve ça tout à fait acceptable, _à condition_ que ce soit énoncé explicitement.
