Effectivement, ce que j'ai repéré est en fait un 0D0A qui s'est transformé en 0A (l'octet qui a sauté, mais je n'avais pas fait le rapprochement avec les codages fin de lignes...)
A défaut d'expliquer l'origine du problème, ça explique sa nature. Si tu as un peu programmé, ou juste échangé des fichiers texte entre Windows et Linux, tu as du constater que "par défaut", Windows "code" les fins de ligne sur deux octets, le retour (0x0d ou '\r' en C), puis la nouvelle ligne (0x0a ou '\n' en C), alors que sous Linux (et tous les Unix), un 0x0a ou '\n' suffit.
Pire, quand tu accèdes sous Windows à un fichier par un bout de code en C, selon que tu ouvres un fichier en mode "texte" ou "binaire" (Linux et les Unix ne connaissent pas cette distinction), il remplace automatiquement les "0x0a" en "0x0d0a".
Et à mon avis, c'est pour corriger ce cas que l'opération inverse peut être faite.
Maintenant, reste à comprendre qui de l'OS/client mail/serveur mail/OS serveur fait la manip, et qu'est ce qui l'amène à tort à le faire ...
Pour la différence d'encodage (8bit ou base64), il faudrait creuser, mais je ne pense pas que ce soit là que se situe le problème.
Mais dans le doute, faudrait écouter les échanges HTTP entre client et serveur, car c'est là que se "négocie" le mode d'encodage. Sous Mozilla/Firefox, il existe un plugin "Live HTTP Headers". Si tu peux le trouver pour tes Firefox, regarde ce qui passe dans les deux cas.
Ou sinon, sniff le réseau sur ton serveur, avec ethereal par exemple.
[^] # Re: Probleme squirrelmail avec les PDF
Posté par Jllc . En réponse au message Probleme squirrelmail avec les PDF. Évalué à 1.
A défaut d'expliquer l'origine du problème, ça explique sa nature. Si tu as un peu programmé, ou juste échangé des fichiers texte entre Windows et Linux, tu as du constater que "par défaut", Windows "code" les fins de ligne sur deux octets, le retour (0x0d ou '\r' en C), puis la nouvelle ligne (0x0a ou '\n' en C), alors que sous Linux (et tous les Unix), un 0x0a ou '\n' suffit.
Pire, quand tu accèdes sous Windows à un fichier par un bout de code en C, selon que tu ouvres un fichier en mode "texte" ou "binaire" (Linux et les Unix ne connaissent pas cette distinction), il remplace automatiquement les "0x0a" en "0x0d0a".
Et à mon avis, c'est pour corriger ce cas que l'opération inverse peut être faite.
Maintenant, reste à comprendre qui de l'OS/client mail/serveur mail/OS serveur fait la manip, et qu'est ce qui l'amène à tort à le faire ...
Pour la différence d'encodage (8bit ou base64), il faudrait creuser, mais je ne pense pas que ce soit là que se situe le problème.
Mais dans le doute, faudrait écouter les échanges HTTP entre client et serveur, car c'est là que se "négocie" le mode d'encodage. Sous Mozilla/Firefox, il existe un plugin "Live HTTP Headers". Si tu peux le trouver pour tes Firefox, regarde ce qui passe dans les deux cas.
Ou sinon, sniff le réseau sur ton serveur, avec ethereal par exemple.