Bonjour,
J'utilise Squirrelmail sur un de mes serveurs et j'ai remarqué que lorsque je veux envoyer un mail avec un pdf en pièce jointe (depuis un poste client linux), le pdf n'est pas lisible chez le destinataire. Par contre, lorsque j'envoie le même pdf avec le même squirrelmail à partir d'un poste windows (XP avec Firefox), le pdf passe...
Mon poste linux : Ubuntu Edgy 6.10 avec Firefox 2.0.0.1
et le squirrelmail tourne sur un serveur Debian 3.1 en version 1.4.9a (dernière version, mais cela faisait aussi la même chose avec les versions précédentes)
Je ne sais pas si le bug vient de squirrelmail (je ne crois pas...) ou de ubuntu ou de la version linux firefox...
Est-ce que quelqu'un a eu le même problème( et trouvé une solution ?)
Merci d'avance...
# Probleme squirrelmail avec les PDF
Posté par Jllc . Évalué à 1.
Est-ce que tu utilises la même version de Firefox sur Windows et Linux ?
Tu devrais essayer d'envoyer (sur une adresse à toi) le même PDF, un coup en passant par Windows, un coup en passant par Linux, et essayer de comparer les deux versions du fichier à l'arrivée. Taille, contenu (avec un éditeur de texte) ...
De préférence, trouve un PDF contenant beaucoup de zones de textes, ce sera plus lisible qu'un exemple purement binaire. Peut être que tu arriveras à deviner ce qui le rend illisible.
[^] # Re: Probleme squirrelmail avec les PDF
Posté par Richard Cruz (site web personnel) . Évalué à 1.
Donc ma question est: ton fichier contient-il des espaces?
[^] # Re: Probleme squirrelmail avec les PDF
Posté par macgyvre . Évalué à 1.
Ce qui est bizarre, c'est que je m'envoie un pdf (départ squirrelmail sous windoze)et que je le recois sous squirrelmail sous linux, j'ai le fichier en attachement et acrobat se lance en cliquant dessus. Lorsque je m'envoie le fichier à partir de squirrelmail sous linux et que je le recois sous linux, en cliquant sur le fichier en attachement, j'ai le fichier qui s'affiche en texte brut (acrobat ne se lance même pas...)
J'utilise la même version de Firefox (2.0.0.1) (mais bon,c'est 2 systèmes différents, donc ca peut être un bug propre à la version linux). Je pense que c'est un problème lié au format de caractère (UTF-8 sous ubuntu), mais je ne suis pas sur du tout...
Pour ce qui est des autres fichiers, je n'ai pas eu ce problème. Je viens de me renvoyer un fichier en .odt pour être sûr et il passe sans problème...
Je précise que les espaces ou non dans les noms de fichiers n'y font rien...
[^] # Re: Probleme squirrelmail avec les PDF
Posté par Jllc . Évalué à 1.
As-tu noté une fréquence régulière (tous le N octets), ou des valeurs particulières qui ont changées, genre 0x0D0A devenu 0x0A (fin de ligne DOS et Unix) ?
Ce qui est bizarre, c'est que je m'envoie un pdf (départ squirrelmail sous windoze)et que je le recois sous squirrelmail sous linux, j'ai le fichier en attachement et acrobat se lance en cliquant dessus. Lorsque je m'envoie le fichier à partir de squirrelmail sous linux et que je le recois sous linux, en cliquant sur le fichier en attachement, j'ai le fichier qui s'affiche en texte brut (acrobat ne se lance même pas...)
Compare le "code source" des 2 mails. Avant la pièce jointe, il y a des infos comme celle-ci :
--------------090001010607040606060901
Content-Type: application/pdf;
name="toto.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="toto.pdf"
Dans l'exemple ci-dessus, il est indiqué qu'il s'agit d'un PDF, et le logiciel saura qu'il faut lancer acrobat.
Mais si autre chose apparait, "application/octet-stream" ou "Content-Type: text/plain;", ça marchera moins bien, forcément ...
[^] # Re: Probleme squirrelmail avec les PDF
Posté par macgyvre . Évalué à 1.
Par contre, plus intéressant, c'est ce qui suit:
extrait du source où le pdf ne passe pas: (sous ubuntu)
------=_20070207105524_68456
Content-Type: text/pdf; name="F0603-18 Mohr site Schwab.pdf"
Content-Disposition: attachment; filename="F0603-18 Mohr site Schwab.pdf"
Content-Transfer-Encoding: 8bit
%PDF-1.4
%äüöÃ
2 0 obj
<< /Length 3 0 R
/Filter /FlateDecode
>>
stream
xÍ[Û$¹}oèÈç÷*tII°
extrait du source où le PDf est passé (sous windows):
------=_20070207192735_46125
Content-Type: application/pdf; name="F0603-18 Mohr site Schwab.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="F0603-18 Mohr site Schwab.pdf"
JVBERi0xLjQNCiXDpMO8w7bDnw0KMiAwIG9iag0KPDwgL0xlbmd0aCAzIDAgUg0KICAgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCniczVvbiiS5EX1v6H/I5wX3KnRJSbAYqrqrjB/H
J'en conclu que c'est un problème d'encodage et .. et... je sais pas comment résoudre (mais ca doit paraître évident pour certains, j'en suis sûr)
[^] # Re: Probleme squirrelmail avec les PDF
Posté par Jllc . É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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.