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 !
Si les transformations CR LF se faisait, tout ce qui est signature électronique de documents textes attachés serait invalide. (à noter aussi que les signatures électroniques ne tiennent pas compte du fait que le document est texte ou binaire).
De même, pour conserver un format spécifique de retour charriot (que des CR, ou que des LF) en mode texte, la seule solution propre est d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
ou le base64.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding est à priori invalide, il me semble?
ce n'est pas une raison non plus pour le rejeter.
---
bon, je vais reprendre avec un exemple concret :
si par exemple j'envoie un script bash (qui est un programme standard qu'on trouve sur le net) et que j'envoie un md5sum pour qu'on s'assure de la fiabilité de ce que j'envoie.
Si on a les transformations des CR LF, on n'est pas embêté du tout !
mais effectivement OpenPGP résout presque le problème.
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
DINH Viêt Hoà wrote:
Si les transformations CR LF se faisait, tout ce qui est signature
électronique de documents textes attachés serait invalide. (à noter aussi
que les signatures électroniques ne tiennent pas compte du fait que le
document est texte ou binaire).
De même, pour conserver un format spécifique de retour charriot (que des
CR, ou que des LF) en mode texte, la seule solution propre est
d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
ou le base64.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding
est à priori invalide, il me semble?
ce n'est pas une raison non plus pour le rejeter.
---
bon, je vais reprendre avec un exemple concret :
si par exemple j'envoie un script bash (qui est un programme standard
qu'on trouve sur le net) et que j'envoie un md5sum pour qu'on s'assure de
la fiabilité de ce que j'envoie.
Si on a les transformations des CR LF, on n'est pas embêté du tout !
mais effectivement OpenPGP résout presque le problème.
--
DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Si les transformations CR LF se faisait, tout ce qui est signature électronique de documents textes attachés serait invalide. (à noter aussi que les signatures électroniques ne tiennent pas compte du fait que le document est texte ou binaire).
De même, pour conserver un format spécifique de retour charriot (que des CR, ou que des LF) en mode texte, la seule solution propre est d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
ou le base64.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding est à priori invalide, il me semble?
ce n'est pas une raison non plus pour le rejeter.
---
bon, je vais reprendre avec un exemple concret :
si par exemple j'envoie un script bash (qui est un programme standard qu'on trouve sur le net) et que j'envoie un md5sum pour qu'on s'assure de la fiabilité de ce que j'envoie.
Si on a les transformations des CR LF, on n'est pas embêté du tout !
mais effectivement OpenPGP résout presque le problème.
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
DINH Viêt Hoà
Si les transformations CR LF se faisait, tout ce qui est signature électronique de documents textes attachés serait invalide. (à noter aussi que les signatures électroniques ne tiennent pas compte du fait que le document est texte ou binaire).
Je suis incompétent dans ce domaine. Tu es sûr que la signature ne se fait pas juste avant l'envoi, c'est-à-dire dans le format d'échange commun, plutôt que dans le format interne de la machine ?
une signature de document ne sait pas forcément que le document va être passé sur le réseau par les protocoles non cités ci-dessus.
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Si les transformations CR LF se faisait, tout ce qui est signature
électronique de documents textes attachés serait invalide. (à noter aussi
que les signatures électroniques ne tiennent pas compte du fait que le
document est texte ou binaire).
Je suis incompétent dans ce domaine. Tu es sûr que la signature ne se
fait pas juste avant l'envoi, c'est-à-dire dans le format d'échange
commun, plutôt que dans le format interne de la machine ?
une signature de document ne sait pas forcément que le document va être
passé sur le réseau par les protocoles non cités ci-dessus.
--
DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Si les transformations CR LF se faisait, tout ce qui est signature électronique de documents textes attachés serait invalide. (à noter aussi que les signatures électroniques ne tiennent pas compte du fait que le document est texte ou binaire).
Je suis incompétent dans ce domaine. Tu es sûr que la signature ne se fait pas juste avant l'envoi, c'est-à-dire dans le format d'échange commun, plutôt que dans le format interne de la machine ?
une signature de document ne sait pas forcément que le document va être passé sur le réseau par les protocoles non cités ci-dessus.
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Olivier Miakinen
De même, pour conserver un format spécifique de retour charriot (que des CR, ou que des LF) en mode texte, la seule solution propre est d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
ou le base64.
Oui.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding est à priori invalide, il me semble?
ce n'est pas une raison non plus pour le rejeter.
Je ne sais pas ce que feraient les divers agents de transport de courrier si jamais un tel message était envoyé.
Le problème se pose en particulier si le message contient un '.' entre deux CR ou entre deux LF. S'agit-il ou non de la fin du message ? Pareil si on rencontre '..' entre deux CR ou entre deux LF : faut-il supprimer l'un des deux ?
Quoi qu'il en soit, un logiciel de messagerie qui enverrait un CR seul ou un LF seul au lieu de CR+LF serait bugué.
bon, je vais reprendre avec un exemple concret :
si par exemple j'envoie un script bash (qui est un programme standard qu'on trouve sur le net) et que j'envoie un md5sum pour qu'on s'assure de la fiabilité de ce que j'envoie.
Si on a les transformations des CR LF, on n'est pas embêté du tout !
C'est une formulation ironique pour dire que ce serait en fait plutôt embêtant ?
Si tu l'envoies sous la forme d'un attachement binaire, et que le destinataire utilise le même encodage que toi, cela ne posera pas de problème.
De même, pour conserver un format spécifique de retour charriot (que des
CR, ou que des LF) en mode texte, la seule solution propre est
d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
ou le base64.
Oui.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding
est à priori invalide, il me semble?
ce n'est pas une raison non plus pour le rejeter.
Je ne sais pas ce que feraient les divers agents de transport de
courrier si jamais un tel message était envoyé.
Le problème se pose en particulier si le message contient un '.' entre
deux CR ou entre deux LF. S'agit-il ou non de la fin du message ? Pareil
si on rencontre '..' entre deux CR ou entre deux LF : faut-il supprimer
l'un des deux ?
Quoi qu'il en soit, un logiciel de messagerie qui enverrait un CR seul
ou un LF seul au lieu de CR+LF serait bugué.
bon, je vais reprendre avec un exemple concret :
si par exemple j'envoie un script bash (qui est un programme standard
qu'on trouve sur le net) et que j'envoie un md5sum pour qu'on s'assure de
la fiabilité de ce que j'envoie.
Si on a les transformations des CR LF, on n'est pas embêté du tout !
C'est une formulation ironique pour dire que ce serait en fait plutôt
embêtant ?
Si tu l'envoies sous la forme d'un attachement binaire, et que le
destinataire utilise le même encodage que toi, cela ne posera pas de
problème.
De même, pour conserver un format spécifique de retour charriot (que des CR, ou que des LF) en mode texte, la seule solution propre est d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
ou le base64.
Oui.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding est à priori invalide, il me semble?
ce n'est pas une raison non plus pour le rejeter.
Je ne sais pas ce que feraient les divers agents de transport de courrier si jamais un tel message était envoyé.
Le problème se pose en particulier si le message contient un '.' entre deux CR ou entre deux LF. S'agit-il ou non de la fin du message ? Pareil si on rencontre '..' entre deux CR ou entre deux LF : faut-il supprimer l'un des deux ?
Quoi qu'il en soit, un logiciel de messagerie qui enverrait un CR seul ou un LF seul au lieu de CR+LF serait bugué.
bon, je vais reprendre avec un exemple concret :
si par exemple j'envoie un script bash (qui est un programme standard qu'on trouve sur le net) et que j'envoie un md5sum pour qu'on s'assure de la fiabilité de ce que j'envoie.
Si on a les transformations des CR LF, on n'est pas embêté du tout !
C'est une formulation ironique pour dire que ce serait en fait plutôt embêtant ?
Si tu l'envoies sous la forme d'un attachement binaire, et que le destinataire utilise le même encodage que toi, cela ne posera pas de problème.
