JKB , dans le message , a
écrit :La plupart du temps, les données
elles-mêmes sont ASCII
Et voilà, tu vois encore les choses par le petit bout de la lorgnette : tu
envisages uniquement le cas de tes logiciels de calcul intensif. Un fichier
de configuration, ça peut aussi contenir des valeurs qui sont du texte dans
une langue naturelle.
JKB , dans le message <slrnibqr4q.gq8.jkb@rayleigh.systella.fr>, a
écrit :
La plupart du temps, les données
elles-mêmes sont ASCII
Et voilà, tu vois encore les choses par le petit bout de la lorgnette : tu
envisages uniquement le cas de tes logiciels de calcul intensif. Un fichier
de configuration, ça peut aussi contenir des valeurs qui sont du texte dans
une langue naturelle.
JKB , dans le message , a
écrit :La plupart du temps, les données
elles-mêmes sont ASCII
Et voilà, tu vois encore les choses par le petit bout de la lorgnette : tu
envisages uniquement le cas de tes logiciels de calcul intensif. Un fichier
de configuration, ça peut aussi contenir des valeurs qui sont du texte dans
une langue naturelle.
Soit tu as des caractères qui te permettent de discriminer, soit le
problème ne se pose pas.
Et des cas ambigus, en pratique, il y en a très peu.
En fait, en quinze ans d'utilisation de mes propres parsers, je n'en
ai encore jamais vu.
Dans ce cas, je te déconseille fortement de te lancer dans
l'écriture d'un tel truc.
Ça y est, le revoilà. Je ne sais pas si tu arrives à imaginer
combien me faire traiter de médiocre par un type comme toi
m'indiffère.
Et dans ce cas, elle est inutile.
Et c'est bien notre cas. Si tu ne détectes pas l'encodage, tu
utilises l'information en tête du fichier. Si tu vas jusqu'à la
déclarer invalide, c'est que tu as détecté par une autre technique
cet encodage
Tu te retrouves avec un fichier
de conf d'un bon millier de lignes avec dedans une information
'encodage=UTF-8' et un encodage réel qui n'a _rien_ à voir avec
l'UTF-8. Avec ta technique, tu as juste réussi à faire exploser la
lecture alors que ton fichier est cohérent à un autre encodage que
tu as _déjà_ décodé au moins partiellement puisque tu sais que ce n'est
pas de l'UTF-8.
Réfléchis un peu pour voir combien ton exemple tarte à la crème est
idiot dans ce contexte.
On s'en fout. Soit en en connaît assez pour le lire, soit on a une
ambiguïté
Non, en pratique, il y a très peu d'ambiguité.
Soit tu as des caractères qui te permettent de discriminer, soit le
problème ne se pose pas.
Et des cas ambigus, en pratique, il y en a très peu.
En fait, en quinze ans d'utilisation de mes propres parsers, je n'en
ai encore jamais vu.
Dans ce cas, je te déconseille fortement de te lancer dans
l'écriture d'un tel truc.
Ça y est, le revoilà. Je ne sais pas si tu arrives à imaginer
combien me faire traiter de médiocre par un type comme toi
m'indiffère.
Et dans ce cas, elle est inutile.
Et c'est bien notre cas. Si tu ne détectes pas l'encodage, tu
utilises l'information en tête du fichier. Si tu vas jusqu'à la
déclarer invalide, c'est que tu as détecté par une autre technique
cet encodage
Tu te retrouves avec un fichier
de conf d'un bon millier de lignes avec dedans une information
'encodage=UTF-8' et un encodage réel qui n'a _rien_ à voir avec
l'UTF-8. Avec ta technique, tu as juste réussi à faire exploser la
lecture alors que ton fichier est cohérent à un autre encodage que
tu as _déjà_ décodé au moins partiellement puisque tu sais que ce n'est
pas de l'UTF-8.
Réfléchis un peu pour voir combien ton exemple tarte à la crème est
idiot dans ce contexte.
On s'en fout. Soit en en connaît assez pour le lire, soit on a une
ambiguïté
Non, en pratique, il y a très peu d'ambiguité.
Soit tu as des caractères qui te permettent de discriminer, soit le
problème ne se pose pas.
Et des cas ambigus, en pratique, il y en a très peu.
En fait, en quinze ans d'utilisation de mes propres parsers, je n'en
ai encore jamais vu.
Dans ce cas, je te déconseille fortement de te lancer dans
l'écriture d'un tel truc.
Ça y est, le revoilà. Je ne sais pas si tu arrives à imaginer
combien me faire traiter de médiocre par un type comme toi
m'indiffère.
Et dans ce cas, elle est inutile.
Et c'est bien notre cas. Si tu ne détectes pas l'encodage, tu
utilises l'information en tête du fichier. Si tu vas jusqu'à la
déclarer invalide, c'est que tu as détecté par une autre technique
cet encodage
Tu te retrouves avec un fichier
de conf d'un bon millier de lignes avec dedans une information
'encodage=UTF-8' et un encodage réel qui n'a _rien_ à voir avec
l'UTF-8. Avec ta technique, tu as juste réussi à faire exploser la
lecture alors que ton fichier est cohérent à un autre encodage que
tu as _déjà_ décodé au moins partiellement puisque tu sais que ce n'est
pas de l'UTF-8.
Réfléchis un peu pour voir combien ton exemple tarte à la crème est
idiot dans ce contexte.
On s'en fout. Soit en en connaît assez pour le lire, soit on a une
ambiguïté
Non, en pratique, il y a très peu d'ambiguité.
Est-ce que tu sais ce que veut dire _la plupart du temps_ ?
Est-ce que tu sais ce que veut dire _la plupart du temps_ ?
Est-ce que tu sais ce que veut dire _la plupart du temps_ ?
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.
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.
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.
JKB , dans le message , a
écrit :Soit tu as des caractères qui te permettent de discriminer, soit le
problème ne se pose pas.
Totalement faux. Je reprends l'exemple d'ISO-8859-1 vs. ISO-8859-15 : l'un a
1/2 là où l'autre a oe, qui sont des caractères qui ont des fonctions
totalement différentes, et que n'importe quel processus vaguement
linguistique (découpage de lignes en paragraphes, typiquement) doit traiter
différemment.
Évidemment, si ton petit monde se limite à distinguer EBCDIC d'ASCII et
d'ignorer les commentaires, c'est plus facile.
Et des cas ambigus, en pratique, il y en a très peu.
Faux.
En fait, en quinze ans d'utilisation de mes propres parsers, je n'en
ai encore jamais vu.
Peut-être sont-ils trop spécialisés pour que tu aies rencontré le problème.
Ça ne veut pas dire que le problème ne se pose pas.
Dans ce cas, je te déconseille fortement de te lancer dans
l'écriture d'un tel truc.
J'en ai déjà écrits, ils marchent très bien.Ça y est, le revoilà. Je ne sais pas si tu arrives à imaginer
combien me faire traiter de médiocre par un type comme toi
m'indiffère.
Apprends à lire, ceux que j'ai traités de médiocres, ce sont tes
condisciples, pas toi.
Et dans ce cas, elle est inutile.
Non, puisque la détection automatique de l'encodage n'est pas possible.
Et c'est bien notre cas. Si tu ne détectes pas l'encodage, tu
utilises l'information en tête du fichier. Si tu vas jusqu'à la
déclarer invalide, c'est que tu as détecté par une autre technique
cet encodage
Non, c'est faux. Exemple : si tu rencontres la séquence d'octets 0x74 0xE9
0x20 dans un fichier qui était censé être de l'UTF-8, tu peux affirmer avec
certitude que ce n'en est pas, mais tu ne peux pas en déduire plus.
Tu te retrouves avec un fichier
de conf d'un bon millier de lignes avec dedans une information
'encodage=UTF-8' et un encodage réel qui n'a _rien_ à voir avec
l'UTF-8. Avec ta technique, tu as juste réussi à faire exploser la
lecture alors que ton fichier est cohérent à un autre encodage que
tu as _déjà_ décodé au moins partiellement puisque tu sais que ce n'est
pas de l'UTF-8.
Je ne vois pas le problème : la lecture échoue avec un message d'erreur
explicite, l'utilisateur vient réparer, et en profite pour vérifier qu'il
n'y a pas eu d'autres erreurs introduites au passage.
Réfléchis un peu pour voir combien ton exemple tarte à la crème est
idiot dans ce contexte.
Le contexte, c'était contredire ton affirmation ultra-générique sur les
informations redondantes.
On s'en fout. Soit en en connaît assez pour le lire, soit on a une
ambiguïté
Dans ton petit monde peut-être. Dès qu'on a du texte à traiter comme tel
dans les données du fichier, c'est faux.
Non, en pratique, il y a très peu d'ambiguité.
Faux.
JKB , dans le message <slrnibqqvu.gq8.jkb@rayleigh.systella.fr>, a
écrit :
Soit tu as des caractères qui te permettent de discriminer, soit le
problème ne se pose pas.
Totalement faux. Je reprends l'exemple d'ISO-8859-1 vs. ISO-8859-15 : l'un a
1/2 là où l'autre a oe, qui sont des caractères qui ont des fonctions
totalement différentes, et que n'importe quel processus vaguement
linguistique (découpage de lignes en paragraphes, typiquement) doit traiter
différemment.
Évidemment, si ton petit monde se limite à distinguer EBCDIC d'ASCII et
d'ignorer les commentaires, c'est plus facile.
Et des cas ambigus, en pratique, il y en a très peu.
Faux.
En fait, en quinze ans d'utilisation de mes propres parsers, je n'en
ai encore jamais vu.
Peut-être sont-ils trop spécialisés pour que tu aies rencontré le problème.
Ça ne veut pas dire que le problème ne se pose pas.
Dans ce cas, je te déconseille fortement de te lancer dans
l'écriture d'un tel truc.
J'en ai déjà écrits, ils marchent très bien.
Ça y est, le revoilà. Je ne sais pas si tu arrives à imaginer
combien me faire traiter de médiocre par un type comme toi
m'indiffère.
Apprends à lire, ceux que j'ai traités de médiocres, ce sont tes
condisciples, pas toi.
Et dans ce cas, elle est inutile.
Non, puisque la détection automatique de l'encodage n'est pas possible.
Et c'est bien notre cas. Si tu ne détectes pas l'encodage, tu
utilises l'information en tête du fichier. Si tu vas jusqu'à la
déclarer invalide, c'est que tu as détecté par une autre technique
cet encodage
Non, c'est faux. Exemple : si tu rencontres la séquence d'octets 0x74 0xE9
0x20 dans un fichier qui était censé être de l'UTF-8, tu peux affirmer avec
certitude que ce n'en est pas, mais tu ne peux pas en déduire plus.
Tu te retrouves avec un fichier
de conf d'un bon millier de lignes avec dedans une information
'encodage=UTF-8' et un encodage réel qui n'a _rien_ à voir avec
l'UTF-8. Avec ta technique, tu as juste réussi à faire exploser la
lecture alors que ton fichier est cohérent à un autre encodage que
tu as _déjà_ décodé au moins partiellement puisque tu sais que ce n'est
pas de l'UTF-8.
Je ne vois pas le problème : la lecture échoue avec un message d'erreur
explicite, l'utilisateur vient réparer, et en profite pour vérifier qu'il
n'y a pas eu d'autres erreurs introduites au passage.
Réfléchis un peu pour voir combien ton exemple tarte à la crème est
idiot dans ce contexte.
Le contexte, c'était contredire ton affirmation ultra-générique sur les
informations redondantes.
On s'en fout. Soit en en connaît assez pour le lire, soit on a une
ambiguïté
Dans ton petit monde peut-être. Dès qu'on a du texte à traiter comme tel
dans les données du fichier, c'est faux.
Non, en pratique, il y a très peu d'ambiguité.
Faux.
JKB , dans le message , a
écrit :Soit tu as des caractères qui te permettent de discriminer, soit le
problème ne se pose pas.
Totalement faux. Je reprends l'exemple d'ISO-8859-1 vs. ISO-8859-15 : l'un a
1/2 là où l'autre a oe, qui sont des caractères qui ont des fonctions
totalement différentes, et que n'importe quel processus vaguement
linguistique (découpage de lignes en paragraphes, typiquement) doit traiter
différemment.
Évidemment, si ton petit monde se limite à distinguer EBCDIC d'ASCII et
d'ignorer les commentaires, c'est plus facile.
Et des cas ambigus, en pratique, il y en a très peu.
Faux.
En fait, en quinze ans d'utilisation de mes propres parsers, je n'en
ai encore jamais vu.
Peut-être sont-ils trop spécialisés pour que tu aies rencontré le problème.
Ça ne veut pas dire que le problème ne se pose pas.
Dans ce cas, je te déconseille fortement de te lancer dans
l'écriture d'un tel truc.
J'en ai déjà écrits, ils marchent très bien.Ça y est, le revoilà. Je ne sais pas si tu arrives à imaginer
combien me faire traiter de médiocre par un type comme toi
m'indiffère.
Apprends à lire, ceux que j'ai traités de médiocres, ce sont tes
condisciples, pas toi.
Et dans ce cas, elle est inutile.
Non, puisque la détection automatique de l'encodage n'est pas possible.
Et c'est bien notre cas. Si tu ne détectes pas l'encodage, tu
utilises l'information en tête du fichier. Si tu vas jusqu'à la
déclarer invalide, c'est que tu as détecté par une autre technique
cet encodage
Non, c'est faux. Exemple : si tu rencontres la séquence d'octets 0x74 0xE9
0x20 dans un fichier qui était censé être de l'UTF-8, tu peux affirmer avec
certitude que ce n'en est pas, mais tu ne peux pas en déduire plus.
Tu te retrouves avec un fichier
de conf d'un bon millier de lignes avec dedans une information
'encodage=UTF-8' et un encodage réel qui n'a _rien_ à voir avec
l'UTF-8. Avec ta technique, tu as juste réussi à faire exploser la
lecture alors que ton fichier est cohérent à un autre encodage que
tu as _déjà_ décodé au moins partiellement puisque tu sais que ce n'est
pas de l'UTF-8.
Je ne vois pas le problème : la lecture échoue avec un message d'erreur
explicite, l'utilisateur vient réparer, et en profite pour vérifier qu'il
n'y a pas eu d'autres erreurs introduites au passage.
Réfléchis un peu pour voir combien ton exemple tarte à la crème est
idiot dans ce contexte.
Le contexte, c'était contredire ton affirmation ultra-générique sur les
informations redondantes.
On s'en fout. Soit en en connaît assez pour le lire, soit on a une
ambiguïté
Dans ton petit monde peut-être. Dès qu'on a du texte à traiter comme tel
dans les données du fichier, c'est faux.
Non, en pratique, il y a très peu d'ambiguité.
Faux.
Je l'attendais celle-ci. C'est fou comme tu aimes donner les bâtons
pour te faire battre ! Ce problème n'en est généralement pas un parce
que tu ne peux pas prétendre avoir un 1/2 dans un nom ou une phrase
normale.
Pour faire simple, le récepteur optimal te calcule une probabilité
que le fichier soit dans tel ou tel encodage.
Plus le texte est long et moins
ta métrique fera d'erreur.
Mais dans quelle langue faut-il le dire. Je me contrefiche de savoir
que la séquence est valable ou non.
Mon affirmation n'est pas ultragénérique.
Je l'attendais celle-ci. C'est fou comme tu aimes donner les bâtons
pour te faire battre ! Ce problème n'en est généralement pas un parce
que tu ne peux pas prétendre avoir un 1/2 dans un nom ou une phrase
normale.
Pour faire simple, le récepteur optimal te calcule une probabilité
que le fichier soit dans tel ou tel encodage.
Plus le texte est long et moins
ta métrique fera d'erreur.
Mais dans quelle langue faut-il le dire. Je me contrefiche de savoir
que la séquence est valable ou non.
Mon affirmation n'est pas ultragénérique.
Je l'attendais celle-ci. C'est fou comme tu aimes donner les bâtons
pour te faire battre ! Ce problème n'en est généralement pas un parce
que tu ne peux pas prétendre avoir un 1/2 dans un nom ou une phrase
normale.
Pour faire simple, le récepteur optimal te calcule une probabilité
que le fichier soit dans tel ou tel encodage.
Plus le texte est long et moins
ta métrique fera d'erreur.
Mais dans quelle langue faut-il le dire. Je me contrefiche de savoir
que la séquence est valable ou non.
Mon affirmation n'est pas ultragénérique.
JKB , dans le message , a
écrit :Je l'attendais celle-ci. C'est fou comme tu aimes donner les bâtons
pour te faire battre ! Ce problème n'en est généralement pas un parce
que tu ne peux pas prétendre avoir un 1/2 dans un nom ou une phrase
normale.
Ah, tu n'as jamais vu quelqu'un écrire « 1/2 heure », par exemple ?
Pour faire simple, le récepteur optimal te calcule une probabilité
que le fichier soit dans tel ou tel encodage.
En d'autres termes, tu prônes un code complexe, qui nécessite des données
volumineuses, et qui donne un résultat juste de manière seulement probable,
tout ça pour éviter de lire une déclaration d'encodage.
Plus le texte est long et moins
ta métrique fera d'erreur.
Et donc sur un texte court, ce qui est le cas typique d'un fichier de
configuration, elle risque d'en faire facilement.
Tiens, un exemple : il existe des encodages qui ne diffèrent entre eux que
par un symbole monétaire à la place de l'autre. Ta métrique, elle est
capable de deviner, d'après le contexte, si on parle de dollars de Hong-Kong
ou de yuans ?
Mais dans quelle langue faut-il le dire. Je me contrefiche de savoir
que la séquence est valable ou non.
Ah, bon ? On se demande bien de quoi tu parles, alors.
JKB , dans le message <slrnibr0ag.gq8.jkb@rayleigh.systella.fr>, a
écrit :
Je l'attendais celle-ci. C'est fou comme tu aimes donner les bâtons
pour te faire battre ! Ce problème n'en est généralement pas un parce
que tu ne peux pas prétendre avoir un 1/2 dans un nom ou une phrase
normale.
Ah, tu n'as jamais vu quelqu'un écrire « 1/2 heure », par exemple ?
Pour faire simple, le récepteur optimal te calcule une probabilité
que le fichier soit dans tel ou tel encodage.
En d'autres termes, tu prônes un code complexe, qui nécessite des données
volumineuses, et qui donne un résultat juste de manière seulement probable,
tout ça pour éviter de lire une déclaration d'encodage.
Plus le texte est long et moins
ta métrique fera d'erreur.
Et donc sur un texte court, ce qui est le cas typique d'un fichier de
configuration, elle risque d'en faire facilement.
Tiens, un exemple : il existe des encodages qui ne diffèrent entre eux que
par un symbole monétaire à la place de l'autre. Ta métrique, elle est
capable de deviner, d'après le contexte, si on parle de dollars de Hong-Kong
ou de yuans ?
Mais dans quelle langue faut-il le dire. Je me contrefiche de savoir
que la séquence est valable ou non.
Ah, bon ? On se demande bien de quoi tu parles, alors.
JKB , dans le message , a
écrit :Je l'attendais celle-ci. C'est fou comme tu aimes donner les bâtons
pour te faire battre ! Ce problème n'en est généralement pas un parce
que tu ne peux pas prétendre avoir un 1/2 dans un nom ou une phrase
normale.
Ah, tu n'as jamais vu quelqu'un écrire « 1/2 heure », par exemple ?
Pour faire simple, le récepteur optimal te calcule une probabilité
que le fichier soit dans tel ou tel encodage.
En d'autres termes, tu prônes un code complexe, qui nécessite des données
volumineuses, et qui donne un résultat juste de manière seulement probable,
tout ça pour éviter de lire une déclaration d'encodage.
Plus le texte est long et moins
ta métrique fera d'erreur.
Et donc sur un texte court, ce qui est le cas typique d'un fichier de
configuration, elle risque d'en faire facilement.
Tiens, un exemple : il existe des encodages qui ne diffèrent entre eux que
par un symbole monétaire à la place de l'autre. Ta métrique, elle est
capable de deviner, d'après le contexte, si on parle de dollars de Hong-Kong
ou de yuans ?
Mais dans quelle langue faut-il le dire. Je me contrefiche de savoir
que la séquence est valable ou non.
Ah, bon ? On se demande bien de quoi tu parles, alors.
Si, "1/2 heure", très rarement "1/2heure".
Non, je te demande de calculer cette probabilité. Pour ta gouverne,
une simple adresse rend cette probabilité epsilonesque.
Si, "1/2 heure", très rarement "1/2heure".
Non, je te demande de calculer cette probabilité. Pour ta gouverne,
une simple adresse rend cette probabilité epsilonesque.
Si, "1/2 heure", très rarement "1/2heure".
Non, je te demande de calculer cette probabilité. Pour ta gouverne,
une simple adresse rend cette probabilité epsilonesque.
JKB , dans le message , a
écrit :Si, "1/2 heure", très rarement "1/2heure".
Tu as bien de la chance d'avoir des correspondants aussi soigneux.
Non, je te demande de calculer cette probabilité. Pour ta gouverne,
une simple adresse rend cette probabilité epsilonesque.
Même epsilonesque, ça fait un code complexe qui risque de se tromper. Belle
recommandation.
JKB , dans le message <slrnibr206.gq8.jkb@rayleigh.systella.fr>, a
écrit :
Si, "1/2 heure", très rarement "1/2heure".
Tu as bien de la chance d'avoir des correspondants aussi soigneux.
Non, je te demande de calculer cette probabilité. Pour ta gouverne,
une simple adresse rend cette probabilité epsilonesque.
Même epsilonesque, ça fait un code complexe qui risque de se tromper. Belle
recommandation.
JKB , dans le message , a
écrit :Si, "1/2 heure", très rarement "1/2heure".
Tu as bien de la chance d'avoir des correspondants aussi soigneux.
Non, je te demande de calculer cette probabilité. Pour ta gouverne,
une simple adresse rend cette probabilité epsilonesque.
Même epsilonesque, ça fait un code complexe qui risque de se tromper. Belle
recommandation.
Pour ton information, l'outil de détection fait 450 Ko de sources,
Pour ton information, l'outil de détection fait 450 Ko de sources,
Pour ton information, l'outil de détection fait 450 Ko de sources,
