On 19 oct, 01:21, Nicolas George <nicolas$ wrote:Tu le rejettes avec un message d'erreur clair, et éventuellement avec les
options offertes pour diverses tentatives de réparation partiellement
automatisées.
Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
lisible, exploitable, sans erreur ni corruption.
Juste que la personne qui a renseigné la déclaration s'est trompée. Au
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?
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 les
options offertes pour diverses tentatives de réparation partiellement
automatisées.
Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
lisible, exploitable, sans erreur ni corruption.
Juste que la personne qui a renseigné la déclaration s'est trompée. Au
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?
On 19 oct, 01:21, Nicolas George <nicolas$ wrote:Tu le rejettes avec un message d'erreur clair, et éventuellement avec les
options offertes pour diverses tentatives de réparation partiellement
automatisées.
Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
lisible, exploitable, sans erreur ni corruption.
Juste que la personne qui a renseigné la déclaration s'est trompée. Au
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?
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 !
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 !
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 !
Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
lisible, exploitable, sans erreur ni corruption.
Juste que la personne qui a renseigné la déclaration s'est trompée. Au
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?
Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
lisible, exploitable, sans erreur ni corruption.
Juste que la personne qui a renseigné la déclaration s'est trompée. Au
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?
Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
lisible, exploitable, sans erreur ni corruption.
Juste que la personne qui a renseigné la déclaration s'est trompée. Au
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?
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
Il suffit d'avoir un éditeur moisi pour qu'il modifie
dans le dos de l'utilisateur l'encodage lors d'une écriture.
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 tu le déclares, c'est pour utiliser cette info.
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)
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
Il suffit d'avoir un éditeur moisi pour qu'il modifie
dans le dos de l'utilisateur l'encodage lors d'une écriture.
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 tu le déclares, c'est pour utiliser cette info.
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)
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
Il suffit d'avoir un éditeur moisi pour qu'il modifie
dans le dos de l'utilisateur l'encodage lors d'une écriture.
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 tu le déclares, c'est pour utiliser cette info.
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)
Aeris , dans le message
, a
écrit :
> Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
> lisible, exploitable, sans erreur ni corruption.
Tu dis absolument n'importe quoi. Si le fichier est décodé comme de l'UTF-8
Aeris , dans le message
<efd28049-ac0a-4667-a577-2e3a9dc852d0@j25g2000yqa.googlegroups.com>, a
écrit :
> Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
> lisible, exploitable, sans erreur ni corruption.
Tu dis absolument n'importe quoi. Si le fichier est décodé comme de l'UTF-8
Aeris , dans le message
, a
écrit :
> Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
> lisible, exploitable, sans erreur ni corruption.
Tu dis absolument n'importe quoi. Si le fichier est décodé comme de l'UTF-8
Ca serait trop demander qu'un fichier de *configuration* soit en ASCII 7
bits pur et dur?
Ca serait trop demander qu'un fichier de *configuration* soit en ASCII 7
bits pur et dur?
Ca serait trop demander qu'un fichier de *configuration* soit en ASCII 7
bits pur et dur?
JKB , dans le message , a
écrit :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
La détection automatique d'un encodage n'est pas une opération fiable.
Comment tu distingues de l'ISO-8859-1 de l'ISO-8859-15, par exemple ?
Il suffit d'avoir un éditeur moisi pour qu'il modifie
dans le dos de l'utilisateur l'encodage lors d'une écriture.
Et il suffit que cette modification tombe dans un cas ambigu pour que ce
soit mort.
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).
Je ne vois pas le rapport avec la choucroute.
Si tu le déclares, c'est pour utiliser cette info.Mes profs d'info m'ont toujours interdit d'avoir deux informations
redondantes dans un bout de code.
Je ne sais pas si ce sont tes profs d'info qui ont trop simplifié pour que
leurs étudiants médiocres retiennent quelque chose ou toi qui as mal
compris, mais cette doctrine, formulée de manière aussi abrégée, est fausse.
Ce qu'il ne faut pas, c'est avoir deux informations redondantes _dont on
suppose qu'elles sont cohérentes_, c'est à dire telles que le comportement
du programme devient invalide si elles se retrouvent incohérentes.
L'exemple typique, c'est un tableau en C :
int values[10];
for(i = 0; i < 10; i++)
values[i] = 0;
Ça, c'est mauvais, parce que si un des 10 change sans que l'autre change de
la même manière, le programme va se mettre à faire n'importe quoi.
En revanche, avoir deux informations redondantes dont on _vérifie_ qu'elles
sont cohérentes, ce n'est pas un problème. Et c'est même souvent quelque
chose qui est recherché activement, parce que ça permet de détecter les
erreurs, intérieures (bugs dans le programme) ou extérieures (fichier qui a
été endommagé quelque part).
L'exemple tarte à la crème de ce cas, ce sont les sommes de contrôle dans un
fichier ou dans un protocole réseau : une somme de contrôle est une
information totalement redondante, et on la met là précisément pour détecter
les erreurs.
Le fichier contient cette
information d'encodage par lui-même
Seulement partiellement.
(sauf fichier pathologique, mais
pour un fichier texte, cela ne nous concerne pas)
C'est faux, les cas d'ambiguïté dans l'encodage sont très communs pour les
encodages historiques.
JKB , dans le message <slrnibqjqb.gq8.jkb@rayleigh.systella.fr>, a
écrit :
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
La détection automatique d'un encodage n'est pas une opération fiable.
Comment tu distingues de l'ISO-8859-1 de l'ISO-8859-15, par exemple ?
Il suffit d'avoir un éditeur moisi pour qu'il modifie
dans le dos de l'utilisateur l'encodage lors d'une écriture.
Et il suffit que cette modification tombe dans un cas ambigu pour que ce
soit mort.
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).
Je ne vois pas le rapport avec la choucroute.
Si tu le déclares, c'est pour utiliser cette info.
Mes profs d'info m'ont toujours interdit d'avoir deux informations
redondantes dans un bout de code.
Je ne sais pas si ce sont tes profs d'info qui ont trop simplifié pour que
leurs étudiants médiocres retiennent quelque chose ou toi qui as mal
compris, mais cette doctrine, formulée de manière aussi abrégée, est fausse.
Ce qu'il ne faut pas, c'est avoir deux informations redondantes _dont on
suppose qu'elles sont cohérentes_, c'est à dire telles que le comportement
du programme devient invalide si elles se retrouvent incohérentes.
L'exemple typique, c'est un tableau en C :
int values[10];
for(i = 0; i < 10; i++)
values[i] = 0;
Ça, c'est mauvais, parce que si un des 10 change sans que l'autre change de
la même manière, le programme va se mettre à faire n'importe quoi.
En revanche, avoir deux informations redondantes dont on _vérifie_ qu'elles
sont cohérentes, ce n'est pas un problème. Et c'est même souvent quelque
chose qui est recherché activement, parce que ça permet de détecter les
erreurs, intérieures (bugs dans le programme) ou extérieures (fichier qui a
été endommagé quelque part).
L'exemple tarte à la crème de ce cas, ce sont les sommes de contrôle dans un
fichier ou dans un protocole réseau : une somme de contrôle est une
information totalement redondante, et on la met là précisément pour détecter
les erreurs.
Le fichier contient cette
information d'encodage par lui-même
Seulement partiellement.
(sauf fichier pathologique, mais
pour un fichier texte, cela ne nous concerne pas)
C'est faux, les cas d'ambiguïté dans l'encodage sont très communs pour les
encodages historiques.
JKB , dans le message , a
écrit :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
La détection automatique d'un encodage n'est pas une opération fiable.
Comment tu distingues de l'ISO-8859-1 de l'ISO-8859-15, par exemple ?
Il suffit d'avoir un éditeur moisi pour qu'il modifie
dans le dos de l'utilisateur l'encodage lors d'une écriture.
Et il suffit que cette modification tombe dans un cas ambigu pour que ce
soit mort.
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).
Je ne vois pas le rapport avec la choucroute.
Si tu le déclares, c'est pour utiliser cette info.Mes profs d'info m'ont toujours interdit d'avoir deux informations
redondantes dans un bout de code.
Je ne sais pas si ce sont tes profs d'info qui ont trop simplifié pour que
leurs étudiants médiocres retiennent quelque chose ou toi qui as mal
compris, mais cette doctrine, formulée de manière aussi abrégée, est fausse.
Ce qu'il ne faut pas, c'est avoir deux informations redondantes _dont on
suppose qu'elles sont cohérentes_, c'est à dire telles que le comportement
du programme devient invalide si elles se retrouvent incohérentes.
L'exemple typique, c'est un tableau en C :
int values[10];
for(i = 0; i < 10; i++)
values[i] = 0;
Ça, c'est mauvais, parce que si un des 10 change sans que l'autre change de
la même manière, le programme va se mettre à faire n'importe quoi.
En revanche, avoir deux informations redondantes dont on _vérifie_ qu'elles
sont cohérentes, ce n'est pas un problème. Et c'est même souvent quelque
chose qui est recherché activement, parce que ça permet de détecter les
erreurs, intérieures (bugs dans le programme) ou extérieures (fichier qui a
été endommagé quelque part).
L'exemple tarte à la crème de ce cas, ce sont les sommes de contrôle dans un
fichier ou dans un protocole réseau : une somme de contrôle est une
information totalement redondante, et on la met là précisément pour détecter
les erreurs.
Le fichier contient cette
information d'encodage par lui-même
Seulement partiellement.
(sauf fichier pathologique, mais
pour un fichier texte, cela ne nous concerne pas)
C'est faux, les cas d'ambiguïté dans l'encodage sont très communs pour les
encodages historiques.
Nicolas George <nicolas$ wrote:Aeris , dans le message
, a
écrit :
> Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
> lisible, exploitable, sans erreur ni corruption.
Tu dis absolument n'importe quoi. Si le fichier est décodé comme de l'UTF-8
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.
Nicolas George <nicolas$george@salle-s.org> wrote:
Aeris , dans le message
<efd28049-ac0a-4667-a577-2e3a9dc852d0@j25g2000yqa.googlegroups.com>, a
écrit :
> Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
> lisible, exploitable, sans erreur ni corruption.
Tu dis absolument n'importe quoi. Si le fichier est décodé comme de l'UTF-8
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.
Nicolas George <nicolas$ wrote:Aeris , dans le message
, a
écrit :
> Y'a rien à réparer justement. Tout le fichier décodé est 100% correct,
> lisible, exploitable, sans erreur ni corruption.
Tu dis absolument n'importe quoi. Si le fichier est décodé comme de l'UTF-8
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.
La plupart du temps, les données
elles-mêmes sont ASCII, mais tu n'empêcheras jamais un type
particulièrement tordu de coller un commentaire avec des accents.
La plupart du temps, les données
elles-mêmes sont ASCII, mais tu n'empêcheras jamais un type
particulièrement tordu de coller un commentaire avec des accents.
La plupart du temps, les données
elles-mêmes sont ASCII, mais tu n'empêcheras jamais un type
particulièrement tordu de coller un commentaire avec des accents.
La plupart du temps, les données
elles-mêmes sont ASCII
La plupart du temps, les données
elles-mêmes sont ASCII
La plupart du temps, les données
elles-mêmes sont ASCII