Je reposte mon message, je ne sais pas ce qui est arrivé à celui que
j'ai posté hier soir ???
**********
Bonjour à tous,
petit problème irritant dont j'aimerais trouver la solution :
un collègue m'envoie régulièrement des messages avec pièces jointes
(généralement des .doc ou .rtf). Pour environ un message sur cinq, pas
de problème, je vois le message, je peux lire la pièce jointe,
l'enregistrer etc.
Par contre, 4 fois sur 5, le message m'apparaît comme complètement vide
(rien dans le corps du message, je ne peux lire le corps du message
qu'en passant par la source) et la pièce jointe s'affiche simplement
comme "attachment", sans extension. Elle existe, la taille du message le
confirme, je peux l'enregistrer, je peux l'ouvrir dans un éditeur de
texte (mais ça me donne en général quelques mots lisibles au milieu d'un
fouillis inommable), mais impossible de l'ouvrir ni sous word ni sous
openoffice même en la renommant par exemple en .doc ou .rtf.
J'ai comparé la source de deux de ces messages, l'un qui passait bien,
l'autre pas, et la *seule* différence que j'ai trouvée est celle-ci :
Donc dans un cas le "Content-Transfer-Encoding" est "base64", dans
l'autre "quoted-printable".
Cette différence peut-elle expliquer l'illisibilité du deuxième message
? Peut-elle venir d'une manipulation différente de mon correspondant
dans les deux cas (celui-ci n'a pas réussi à m'expliquer comment il
avait procédé) ? Que puis-je (ou plutôt l'expéditeur des messages plus
probablement) faire pour remédier au problème ?
Je précise pour finir que j'utilise Mozilla 1.4, et que mon collègue
utilise, d'après ses en-têtes, OE 6.00.2600.0000.
Merci d'avance pour votre aide, et désolée pour la longueur de ce
message, j'ai essayé d'être aussi claire que possible !
Donc dans un cas le "Content-Transfer-Encoding" est "base64", dans l'autre "quoted-printable".
Une autre différence est un fichier avec extension .doc dans un cas, .rtf dans l'autre. Je ne sais pas si cela peut faire quelque chose.
Cette différence peut-elle expliquer l'illisibilité du deuxième message ?
C'est possible. Ce qu'il serait intéressant de savoir, c'est si ton collègue peut relire les messages qu'il a lui-même envoyé. Pour cela il faut bien sûr qu'il se mette aussi dans la liste des destinataires.
Peut-elle venir d'une manipulation différente de mon correspondant dans les deux cas (celui-ci n'a pas réussi à m'expliquer comment il avait procédé) ?
Je ne pense pas. À priori, le choix base64/QP se fait en fonction de la quantité de caractères qui sont en dehors de us-ascii (lettres non accentuées, chiffres, ponctuation usuelle).
Que puis-je (ou plutôt l'expéditeur des messages plus probablement) faire pour remédier au problème ?
Quelques idées en vrac : - d'abord qu'il essaye de relire ses propres envois (cf supra) - qu'il envoie le même fichier en .doc et en .rtf, pour voir - qu'il essaye de rajouter une image dans le document pour tenter de forcer le base64 si vraiment c'est le quoted-printable qui pose problème - en dernier ressort, qu'il m'envoie deux fichiers, un OK et un illisible, en courrier privé
Je précise pour finir que j'utilise Mozilla 1.4, et que mon collègue utilise, d'après ses en-têtes, OE 6.00.2600.0000.
Merci de la précision.
Merci d'avance pour votre aide, et désolée pour la longueur de ce message, j'ai essayé d'être aussi claire que possible !
C'était le cas, ta question est très claire.
Olivier
Je reposte mon message, je ne sais pas ce qui est arrivé à celui que
j'ai posté hier soir ???
Donc dans un cas le "Content-Transfer-Encoding" est "base64", dans
l'autre "quoted-printable".
Une autre différence est un fichier avec extension .doc dans un cas,
.rtf dans l'autre. Je ne sais pas si cela peut faire quelque chose.
Cette différence peut-elle expliquer l'illisibilité du deuxième message
?
C'est possible. Ce qu'il serait intéressant de savoir, c'est si ton
collègue peut relire les messages qu'il a lui-même envoyé. Pour cela il
faut bien sûr qu'il se mette aussi dans la liste des destinataires.
Peut-elle venir d'une manipulation différente de mon correspondant
dans les deux cas (celui-ci n'a pas réussi à m'expliquer comment il
avait procédé) ?
Je ne pense pas. À priori, le choix base64/QP se fait en fonction de la
quantité de caractères qui sont en dehors de us-ascii (lettres non
accentuées, chiffres, ponctuation usuelle).
Que puis-je (ou plutôt l'expéditeur des messages plus
probablement) faire pour remédier au problème ?
Quelques idées en vrac :
- d'abord qu'il essaye de relire ses propres envois (cf supra)
- qu'il envoie le même fichier en .doc et en .rtf, pour voir
- qu'il essaye de rajouter une image dans le document pour tenter
de forcer le base64 si vraiment c'est le quoted-printable qui pose
problème
- en dernier ressort, qu'il m'envoie deux fichiers, un OK et un
illisible, en courrier privé
Je précise pour finir que j'utilise Mozilla 1.4, et que mon collègue
utilise, d'après ses en-têtes, OE 6.00.2600.0000.
Merci de la précision.
Merci d'avance pour votre aide, et désolée pour la longueur de ce
message, j'ai essayé d'être aussi claire que possible !
Donc dans un cas le "Content-Transfer-Encoding" est "base64", dans l'autre "quoted-printable".
Une autre différence est un fichier avec extension .doc dans un cas, .rtf dans l'autre. Je ne sais pas si cela peut faire quelque chose.
Cette différence peut-elle expliquer l'illisibilité du deuxième message ?
C'est possible. Ce qu'il serait intéressant de savoir, c'est si ton collègue peut relire les messages qu'il a lui-même envoyé. Pour cela il faut bien sûr qu'il se mette aussi dans la liste des destinataires.
Peut-elle venir d'une manipulation différente de mon correspondant dans les deux cas (celui-ci n'a pas réussi à m'expliquer comment il avait procédé) ?
Je ne pense pas. À priori, le choix base64/QP se fait en fonction de la quantité de caractères qui sont en dehors de us-ascii (lettres non accentuées, chiffres, ponctuation usuelle).
Que puis-je (ou plutôt l'expéditeur des messages plus probablement) faire pour remédier au problème ?
Quelques idées en vrac : - d'abord qu'il essaye de relire ses propres envois (cf supra) - qu'il envoie le même fichier en .doc et en .rtf, pour voir - qu'il essaye de rajouter une image dans le document pour tenter de forcer le base64 si vraiment c'est le quoted-printable qui pose problème - en dernier ressort, qu'il m'envoie deux fichiers, un OK et un illisible, en courrier privé
Je précise pour finir que j'utilise Mozilla 1.4, et que mon collègue utilise, d'après ses en-têtes, OE 6.00.2600.0000.
Merci de la précision.
Merci d'avance pour votre aide, et désolée pour la longueur de ce message, j'ai essayé d'être aussi claire que possible !
C'était le cas, ta question est très claire.
Olivier
DINH Viêt Hoà
Je ne pense pas. À priori, le choix base64/QP se fait en fonction de la quantité de caractères qui sont en dehors de us-ascii (lettres non accentuées, chiffres, ponctuation usuelle).
enfin reste que les retours à la ligne sont moyennement définis en quoted-printable, vu que tous les logiciels de courriers électroniques (ou presque tous) transforment les CR LF en LF. Par contre, le RTF est censé être du format plus ou moins texte, non ? Enfin si word (ou autre lecteur de RFC) n'accepte que des CR LF par exemple, cela peut poser problème.
Que puis-je (ou plutôt l'expéditeur des messages plus probablement) faire pour remédier au problème ?
Quelques idées en vrac : - d'abord qu'il essaye de relire ses propres envois (cf supra) - qu'il envoie le même fichier en .doc et en .rtf, pour voir - qu'il essaye de rajouter une image dans le document pour tenter de forcer le base64 si vraiment c'est le quoted-printable qui pose problème
effectivement, le quoted-printable n'est pas bien implémenté partout. Il peut donc y avoir une différence entre le fichier initialement envoyé et le fichier reçu.
-- DINH V. Hoa,
"monde de merde" -- Erwan David
Je ne pense pas. À priori, le choix base64/QP se fait en fonction de la
quantité de caractères qui sont en dehors de us-ascii (lettres non
accentuées, chiffres, ponctuation usuelle).
enfin reste que les retours à la ligne sont moyennement définis en
quoted-printable, vu que tous les logiciels de courriers électroniques (ou
presque tous) transforment les CR LF en LF.
Par contre, le RTF est censé être du format plus ou moins texte, non ?
Enfin si word (ou autre lecteur de RFC) n'accepte que des CR LF par
exemple, cela peut poser problème.
Que puis-je (ou plutôt l'expéditeur des messages plus
probablement) faire pour remédier au problème ?
Quelques idées en vrac :
- d'abord qu'il essaye de relire ses propres envois (cf supra)
- qu'il envoie le même fichier en .doc et en .rtf, pour voir
- qu'il essaye de rajouter une image dans le document pour tenter
de forcer le base64 si vraiment c'est le quoted-printable qui pose
problème
effectivement, le quoted-printable n'est pas bien implémenté partout.
Il peut donc y avoir une différence entre le fichier initialement envoyé
et le fichier reçu.
Je ne pense pas. À priori, le choix base64/QP se fait en fonction de la quantité de caractères qui sont en dehors de us-ascii (lettres non accentuées, chiffres, ponctuation usuelle).
enfin reste que les retours à la ligne sont moyennement définis en quoted-printable, vu que tous les logiciels de courriers électroniques (ou presque tous) transforment les CR LF en LF. Par contre, le RTF est censé être du format plus ou moins texte, non ? Enfin si word (ou autre lecteur de RFC) n'accepte que des CR LF par exemple, cela peut poser problème.
Que puis-je (ou plutôt l'expéditeur des messages plus probablement) faire pour remédier au problème ?
Quelques idées en vrac : - d'abord qu'il essaye de relire ses propres envois (cf supra) - qu'il envoie le même fichier en .doc et en .rtf, pour voir - qu'il essaye de rajouter une image dans le document pour tenter de forcer le base64 si vraiment c'est le quoted-printable qui pose problème
effectivement, le quoted-printable n'est pas bien implémenté partout. Il peut donc y avoir une différence entre le fichier initialement envoyé et le fichier reçu.
-- DINH V. Hoa,
"monde de merde" -- Erwan David
Olivier Zolli
Le 13/11/2003 à 14:58 DINH Viêt Hoà écrivait :
enfin reste que les retours à la ligne sont moyennement définis en quoted-printable, vu que tous les logiciels de courriers électroniques (ou presque tous) transforment les CR LF en LF.
Ça ne serait pas plutôt le contraire ?
-- Olivier Zolli http://www.hamster-fr.org/
Le 13/11/2003 à 14:58 DINH Viêt Hoà écrivait :
enfin reste que les retours à la ligne sont moyennement définis en
quoted-printable, vu que tous les logiciels de courriers électroniques (ou
presque tous) transforment les CR LF en LF.
enfin reste que les retours à la ligne sont moyennement définis en quoted-printable, vu que tous les logiciels de courriers électroniques (ou presque tous) transforment les CR LF en LF.
Ça ne serait pas plutôt le contraire ?
-- Olivier Zolli http://www.hamster-fr.org/
DINH Viêt Hoà
Le 13/11/2003 à 14:58 DINH Viêt Hoà écrivait :
enfin reste que les retours à la ligne sont moyennement définis en quoted-printable, vu que tous les logiciels de courriers électroniques (ou presque tous) transforment les CR LF en LF.
Ça ne serait pas plutôt le contraire ?
sur Internet, les messages circulent avec des CR LF pour les retours à la ligne (standardisé IETF), que ce soit NNTP (groupes de discussion) ou bien SMTP (courriers électroniques).
-- DINH V. Hoa,
"monde de merde" -- Erwan David
Le 13/11/2003 à 14:58 DINH Viêt Hoà écrivait :
enfin reste que les retours à la ligne sont moyennement définis en
quoted-printable, vu que tous les logiciels de courriers électroniques (ou
presque tous) transforment les CR LF en LF.
Ça ne serait pas plutôt le contraire ?
sur Internet, les messages circulent avec des CR LF pour les retours à la
ligne (standardisé IETF), que ce soit NNTP (groupes de discussion) ou bien
SMTP (courriers électroniques).
enfin reste que les retours à la ligne sont moyennement définis en quoted-printable, vu que tous les logiciels de courriers électroniques (ou presque tous) transforment les CR LF en LF.
Ça ne serait pas plutôt le contraire ?
sur Internet, les messages circulent avec des CR LF pour les retours à la ligne (standardisé IETF), que ce soit NNTP (groupes de discussion) ou bien SMTP (courriers électroniques).
-- DINH V. Hoa,
"monde de merde" -- Erwan David
Olivier Miakinen
enfin reste que les retours à la ligne sont moyennement définis en quoted-printable, vu que tous les logiciels de courriers électroniques (ou presque tous) transforment les CR LF en LF.
En envoi ou en réception ?
En principe, il ne doit pas y avoir de problème. Le seul code de fin de ligne reconnu par SMTP est CR LF. Si c'est bien ce qu'il y a dans le message à transmettre, la séquence peut être envoyée telle quelle. Sinon, un CR seul ou LF seul doit être encodé. Du moins, c'est le souvenir que j'en ai, mais il faudra que je vérifie.
Par contre, le RTF est censé être du format plus ou moins texte, non ? Enfin si word (ou autre lecteur de RFC) n'accepte que des CR LF par exemple, cela peut poser problème.
C'est plutôt le contraire, mais cf supra.
effectivement, le quoted-printable n'est pas bien implémenté partout. Il peut donc y avoir une différence entre le fichier initialement envoyé et le fichier reçu.
Suite à ta réponse, je pourrais imaginer le bug suivant dans un logiciel de courrier qui n'implémenterait pas correctement la norme : ce serait de considérer le fichier attaché comme du texte (bien qu'il soit déclaré comme application/msword), et de transformer les CR seuls et/ou les LF seuls en CR+LF au lieu d'encoder ces caractères.
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un manque dans la définition du format comme tu semblais le penser.
enfin reste que les retours à la ligne sont moyennement définis en
quoted-printable, vu que tous les logiciels de courriers électroniques (ou
presque tous) transforment les CR LF en LF.
En envoi ou en réception ?
En principe, il ne doit pas y avoir de problème. Le seul code de fin de
ligne reconnu par SMTP est CR LF. Si c'est bien ce qu'il y a dans le
message à transmettre, la séquence peut être envoyée telle quelle.
Sinon, un CR seul ou LF seul doit être encodé. Du moins, c'est le
souvenir que j'en ai, mais il faudra que je vérifie.
Par contre, le RTF est censé être du format plus ou moins texte, non ?
Enfin si word (ou autre lecteur de RFC) n'accepte que des CR LF par
exemple, cela peut poser problème.
C'est plutôt le contraire, mais cf supra.
effectivement, le quoted-printable n'est pas bien implémenté partout.
Il peut donc y avoir une différence entre le fichier initialement envoyé
et le fichier reçu.
Suite à ta réponse, je pourrais imaginer le bug suivant dans un logiciel
de courrier qui n'implémenterait pas correctement la norme : ce serait
de considérer le fichier attaché comme du texte (bien qu'il soit déclaré
comme application/msword), et de transformer les CR seuls et/ou les LF
seuls en CR+LF au lieu d'encoder ces caractères.
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un
manque dans la définition du format comme tu semblais le penser.
enfin reste que les retours à la ligne sont moyennement définis en quoted-printable, vu que tous les logiciels de courriers électroniques (ou presque tous) transforment les CR LF en LF.
En envoi ou en réception ?
En principe, il ne doit pas y avoir de problème. Le seul code de fin de ligne reconnu par SMTP est CR LF. Si c'est bien ce qu'il y a dans le message à transmettre, la séquence peut être envoyée telle quelle. Sinon, un CR seul ou LF seul doit être encodé. Du moins, c'est le souvenir que j'en ai, mais il faudra que je vérifie.
Par contre, le RTF est censé être du format plus ou moins texte, non ? Enfin si word (ou autre lecteur de RFC) n'accepte que des CR LF par exemple, cela peut poser problème.
C'est plutôt le contraire, mais cf supra.
effectivement, le quoted-printable n'est pas bien implémenté partout. Il peut donc y avoir une différence entre le fichier initialement envoyé et le fichier reçu.
Suite à ta réponse, je pourrais imaginer le bug suivant dans un logiciel de courrier qui n'implémenterait pas correctement la norme : ce serait de considérer le fichier attaché comme du texte (bien qu'il soit déclaré comme application/msword), et de transformer les CR seuls et/ou les LF seuls en CR+LF au lieu d'encoder ces caractères.
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un manque dans la définition du format comme tu semblais le penser.
Olivier Zolli
Le 13/11/2003 à 20:45 DINH Viêt Hoà écrivait :
enfin reste que les retours à la ligne sont moyennement définis en quoted-printable, vu que tous les logiciels de courriers électroniques (ou presque tous) transforment les CR LF en LF.
Ça ne serait pas plutôt le contraire ?
sur Internet, les messages circulent avec des CR LF pour les retours à la ligne (standardisé IETF), que ce soit NNTP (groupes de discussion) ou bien SMTP (courriers électroniques).
Ok, je n'avais pas saisi que tu parlais du traitement à réception, je pensais à l'envoi...
-- Olivier Zolli http://www.hamster-fr.org/
Le 13/11/2003 à 20:45 DINH Viêt Hoà écrivait :
enfin reste que les retours à la ligne sont moyennement définis en
quoted-printable, vu que tous les logiciels de courriers électroniques (ou
presque tous) transforment les CR LF en LF.
Ça ne serait pas plutôt le contraire ?
sur Internet, les messages circulent avec des CR LF pour les retours à la
ligne (standardisé IETF), que ce soit NNTP (groupes de discussion) ou bien
SMTP (courriers électroniques).
Ok, je n'avais pas saisi que tu parlais du traitement à réception, je
pensais à l'envoi...
enfin reste que les retours à la ligne sont moyennement définis en quoted-printable, vu que tous les logiciels de courriers électroniques (ou presque tous) transforment les CR LF en LF.
Ça ne serait pas plutôt le contraire ?
sur Internet, les messages circulent avec des CR LF pour les retours à la ligne (standardisé IETF), que ce soit NNTP (groupes de discussion) ou bien SMTP (courriers électroniques).
Ok, je n'avais pas saisi que tu parlais du traitement à réception, je pensais à l'envoi...
-- Olivier Zolli http://www.hamster-fr.org/
DINH Viêt Hoà
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un manque dans la définition du format comme tu semblais le penser.
Le format est bien défini mais son application sur les fichiers textes est mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR, en CR LF ou en LF.
-- DINH V. Hoa,
"monde de merde" -- Erwan David
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un
manque dans la définition du format comme tu semblais le penser.
Le format est bien défini mais son application sur les fichiers textes est
mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR,
en CR LF ou en LF.
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un manque dans la définition du format comme tu semblais le penser.
Le format est bien défini mais son application sur les fichiers textes est mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR, en CR LF ou en LF.
-- DINH V. Hoa,
"monde de merde" -- Erwan David
Pierre Duhem
On Thu, 13 Nov 2003 21:20:01 +0100, DINH Viêt Hoà wrote:
Le format est bien défini mais son application sur les fichiers textes est
mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR,
en CR LF ou en LF.
Dans un souci d'exhaustivité, je dirai que j'ai même déjà vu des LF+CR.
Pierre Duhem Logiciels & Services Duhem, Paris, France http://www.macdisk.com
Please remove the X from the address to answer through email
On Thu, 13 Nov 2003 21:20:01 +0100, DINH Viêt Hoà
<dinh.viet.hoa@free.fr> wrote:
Le format est bien défini mais son application sur les fichiers textes
est
mal défini vu qu'un fichier texte peut avoir des retours à la ligne en
CR,
en CR LF ou en LF.
Dans un souci d'exhaustivité, je dirai que j'ai même déjà vu des LF+CR.
Pierre Duhem
Logiciels & Services Duhem, Paris, France
http://www.macdisk.com
duhem@Xmacdisk.com
Please remove the X from the address to answer through email
On Thu, 13 Nov 2003 21:20:01 +0100, DINH Viêt Hoà wrote:
Le format est bien défini mais son application sur les fichiers textes est
mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR,
en CR LF ou en LF.
Dans un souci d'exhaustivité, je dirai que j'ai même déjà vu des LF+CR.
Pierre Duhem Logiciels & Services Duhem, Paris, France http://www.macdisk.com
Please remove the X from the address to answer through email
Olivier Miakinen
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un manque dans la définition du format comme tu semblais le penser.
Le format est bien défini mais son application sur les fichiers textes est mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR, en CR LF ou en LF.
Il ne peut pas y avoir plusieurs représentations internes différentes sur un même système(*). Prenons un exemple concret bien compliqué : un courrier envoyé d'une machine Unix (ASCII, fin de ligne en LF seul) à une machine propriétaire IBM (EBCDIC, je vais supposer que la fin de ligne est CR+LF mais je n'en suis pas sûr).
Supposons que le message contienne : "GHIJK<fin de ligne>"
Sur la machine Unix, il est stocké ainsi : 47 48 49 4a 4b 0A
Sur le réseau, il est transmis ainsi : 47 48 49 4a 4b 0D 0A
Sur la machine IBM il devient : C7 C8 C9 D1 D2 0D 25
... et pareil dans l'autre sens. C'est aux logiciels de courrier de savoir traduire du format interne au format réseau en réciproquement.
Olivier
(*) En fait si, il peut y en avoir, mais le logiciel responsable du format interne doit savoir lequel il utilise, sinon c'est le bordel !
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un
manque dans la définition du format comme tu semblais le penser.
Le format est bien défini mais son application sur les fichiers textes est
mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR,
en CR LF ou en LF.
Il ne peut pas y avoir plusieurs représentations internes différentes
sur un même système(*). Prenons un exemple concret bien compliqué : un
courrier envoyé d'une machine Unix (ASCII, fin de ligne en LF seul) à
une machine propriétaire IBM (EBCDIC, je vais supposer que la fin de
ligne est CR+LF mais je n'en suis pas sûr).
Supposons que le message contienne : "GHIJK<fin de ligne>"
Sur la machine Unix, il est stocké ainsi :
47 48 49 4a 4b 0A
Sur le réseau, il est transmis ainsi :
47 48 49 4a 4b 0D 0A
Sur la machine IBM il devient :
C7 C8 C9 D1 D2 0D 25
... et pareil dans l'autre sens. C'est aux logiciels de courrier de
savoir traduire du format interne au format réseau en réciproquement.
Olivier
(*) En fait si, il peut y en avoir, mais le logiciel responsable du
format interne doit savoir lequel il utilise, sinon c'est le bordel !
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un manque dans la définition du format comme tu semblais le penser.
Le format est bien défini mais son application sur les fichiers textes est mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR, en CR LF ou en LF.
Il ne peut pas y avoir plusieurs représentations internes différentes sur un même système(*). Prenons un exemple concret bien compliqué : un courrier envoyé d'une machine Unix (ASCII, fin de ligne en LF seul) à une machine propriétaire IBM (EBCDIC, je vais supposer que la fin de ligne est CR+LF mais je n'en suis pas sûr).
Supposons que le message contienne : "GHIJK<fin de ligne>"
Sur la machine Unix, il est stocké ainsi : 47 48 49 4a 4b 0A
Sur le réseau, il est transmis ainsi : 47 48 49 4a 4b 0D 0A
Sur la machine IBM il devient : C7 C8 C9 D1 D2 0D 25
... et pareil dans l'autre sens. C'est aux logiciels de courrier de savoir traduire du format interne au format réseau en réciproquement.
Olivier
(*) En fait si, il peut y en avoir, mais le logiciel responsable du format interne doit savoir lequel il utilise, sinon c'est le bordel !
DINH Viêt Hoà
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un manque dans la définition du format comme tu semblais le penser.
Le format est bien défini mais son application sur les fichiers textes est mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR, en CR LF ou en LF.
Il ne peut pas y avoir plusieurs représentations internes différentes sur un même système(*). Prenons un exemple concret bien compliqué : un courrier envoyé d'une machine Unix (ASCII, fin de ligne en LF seul) à une machine propriétaire IBM (EBCDIC, je vais supposer que la fin de ligne est CR+LF mais je n'en suis pas sûr).
Supposons que le message contienne : "GHIJK<fin de ligne>"
Sur la machine Unix, il est stocké ainsi : 47 48 49 4a 4b 0A
Sur le réseau, il est transmis ainsi : 47 48 49 4a 4b 0D 0A
Sur la machine IBM il devient : C7 C8 C9 D1 D2 0D 25
... et pareil dans l'autre sens. C'est aux logiciels de courrier de savoir traduire du format interne au format réseau en réciproquement.
certes mais ce que je voulais dire, c'est, si tu attaches un fichier texte, est-ce que tu vas t'amuser à changer le format d'un réseau à l'autre ?
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un
manque dans la définition du format comme tu semblais le penser.
Le format est bien défini mais son application sur les fichiers textes est
mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR,
en CR LF ou en LF.
Il ne peut pas y avoir plusieurs représentations internes différentes
sur un même système(*). Prenons un exemple concret bien compliqué : un
courrier envoyé d'une machine Unix (ASCII, fin de ligne en LF seul) à
une machine propriétaire IBM (EBCDIC, je vais supposer que la fin de
ligne est CR+LF mais je n'en suis pas sûr).
Supposons que le message contienne : "GHIJK<fin de ligne>"
Sur la machine Unix, il est stocké ainsi :
47 48 49 4a 4b 0A
Sur le réseau, il est transmis ainsi :
47 48 49 4a 4b 0D 0A
Sur la machine IBM il devient :
C7 C8 C9 D1 D2 0D 25
... et pareil dans l'autre sens. C'est aux logiciels de courrier de
savoir traduire du format interne au format réseau en réciproquement.
certes mais ce que je voulais dire, c'est, si tu attaches un fichier
texte, est-ce que tu vas t'amuser à changer le format d'un réseau à
l'autre ?
--
DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Quoi qu'il en soit, ce serait clairement un bug du logiciel, et pas un manque dans la définition du format comme tu semblais le penser.
Le format est bien défini mais son application sur les fichiers textes est mal défini vu qu'un fichier texte peut avoir des retours à la ligne en CR, en CR LF ou en LF.
Il ne peut pas y avoir plusieurs représentations internes différentes sur un même système(*). Prenons un exemple concret bien compliqué : un courrier envoyé d'une machine Unix (ASCII, fin de ligne en LF seul) à une machine propriétaire IBM (EBCDIC, je vais supposer que la fin de ligne est CR+LF mais je n'en suis pas sûr).
Supposons que le message contienne : "GHIJK<fin de ligne>"
Sur la machine Unix, il est stocké ainsi : 47 48 49 4a 4b 0A
Sur le réseau, il est transmis ainsi : 47 48 49 4a 4b 0D 0A
Sur la machine IBM il devient : C7 C8 C9 D1 D2 0D 25
... et pareil dans l'autre sens. C'est aux logiciels de courrier de savoir traduire du format interne au format réseau en réciproquement.
certes mais ce que je voulais dire, c'est, si tu attaches un fichier texte, est-ce que tu vas t'amuser à changer le format d'un réseau à l'autre ?
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
