Forum Ubuntu-fr.org / disparition 0D 0A

Réponse à : disparition 0D 0A

dummy@example.com (ar barzh paour) — Fri, 18 Jan 2013 14:27:24 +0000

là non , mais c'est trop compliqué à analyser

Réponse à : disparition 0D 0A

dummy@example.com (Braun) — Thu, 17 Jan 2013 12:59:55 +0000

ar barzh paour a écrit :

HS : contient 10521 octets au lieu de 10450 d'origine ( donc ajout d'octets à l'émission!! )

Et je serais prêt à parier qu'il est encadré par les chaînes:

begin ... 
... 
end

Réponse à : disparition 0D 0A

dummy@example.com (ar barzh paour) — Thu, 17 Jan 2013 08:58:31 +0000

j'ai paufiné un peu mes esais
t1 , t1.bin , t1.enc contiennent 41 42 43 0d 0a
t2 t2.bin t2.enc contiennent 82 00 43 0d 0a (j'ai mis un peu n'importe quoi mais je voulais au moins un 00)
y y.bin y.enc : un fichier de contenu réel (10450 octets)
j'envoie le tout avec évolution
je récupère l'ensemble de deux façons
une fois sans évolution , directement sur le serveur de mail
une fois avec évolution
résultat
récupérartion sans évolution :
t1 t1.bin t1.enc OK => ces fichiers ont été bien transmis
t2 t2.bin t2.enc OK => ces fichiers ont été bien transmis
y et y.bin OK => ces fichiers ont été bien transmis
y.enc HS HS : contient 10521 octets au lieu de 10450 d'origine ( donc ajout d'octets à l'émission!! )

récupération avec évolution :
t1 t1.bin t1.enc : HS 4 octets seulement
t2 t2.bin t2.enc OK=> emission et récupération OK)
y y.bin OK=> emission et récupération OK)
y.enc HS ( déjà HS à l'émission)

Réponse à : disparition 0D 0A

dummy@example.com (ar barzh paour) — Thu, 17 Jan 2013 08:31:28 +0000

impossible à ce jour de me connecter à bugzilla pour émettre ce "bug" si c'en est un

Réponse à : disparition 0D 0A

dummy@example.com (ar barzh paour) — Mon, 14 Jan 2013 11:32:20 +0000

j'ai effectué l'essai suivant
envoi de 3 fichiers contenant la même chose (41 4 2 43 0d 0a)
mais appelés différemment t5 , t5.enc , t5.bin
seul le fichier t5.bin a bien été envoyé et reçu correctement ,
les deux autres ne contiennent plus que 41 42 4 3 0a !!!!
dans nautilus
t5 est vu comme document text brut
t5.enc est vu comme Uuencode file
t5.bin est vu comme application
je vais essayer de créer un bug dans evolution !!!

Réponse à : disparition 0D 0A

dummy@example.com (Braun) — Sun, 13 Jan 2013 20:29:31 +0000

A priori ni l'un ni l'autre, je pense que l'encodage, si encodage il y a, ne se fait pas spontanément mais par ton client de messagerie qui lui (tare venue d'un autre système d'exploitation ) juge un fichier d'après son extension.
Je ne pratique pas Nautilus (pour cause de Kubuntu) mais cela m'étonnerait fort que Nautilus prenne l'initiative de transcoder un fichier surtout sans t'en informer.

Réponse à : disparition 0D 0A

dummy@example.com (ar barzh paour) — Sun, 13 Jan 2013 19:48:48 +0000

@Braun

braun a écrit :

Normalement tu devrais avoir une option pour désactiver cet en(dé)codage censé rendre les transmissions plus sûres.

quand tu dis cela tu penses désactivation dans nautilus ou dans linux ?

il doit y avoir un lien entre le nom de l'extension et le type , il suffirait peut-être que je modifie ce lien "enc"<==>"UUencoded" mais je ne sais pas du tout où aller

une idée ?

Réponse à : disparition 0D 0A

dummy@example.com (Braun) — Sat, 12 Jan 2013 20:44:23 +0000

Bonsoir,

UUE file is an Uuencoded data. The file is often used for e-mailing documents on Unix platforms so that the file does not get corrupted.
Uuencoding is a form of binary-to-text encoding ...

Il semblerait donc que ton système utilise en entrée et en sortie un dé(en)codage du genre Uuencode, ce qui me rappelle le BinHex du MacOs 9.
Normalement tu devrais avoir une option pour désactiver cet en(dé)codage censé rendre les transmissions plus sûres.

Réponse à : disparition 0D 0A

dummy@example.com (ar barzh paour) — Sat, 12 Jan 2013 16:54:22 +0000

@braun et tiramiseb : certainement un début d'explication :
ces fichiers ont comme extension ".enc"
exemple "essai.enc"
dans nautilus si je regarde les proriétés du fichier je trouve
Type :Uuencoded file (text/x-uuencode)
si je transmets ce fichier il se corrompt
il suffit que j'apelle ce fichier "essai.en"
son type devient : application (application/octet-stream)
et là c'est bon
un ubuntero ayant evolution pourrait-il effectuer l'essai suivant :
créé un fichier essai.enc contenant 41 42 43 0D 0A (code en hexa)
se l'envoyer via évolution et regarder le contenu de la réception : 41 42 43 0D 0A ou bien 41 42 43 0A ?

Réponse à : disparition 0D 0A

dummy@example.com (ar barzh paour) — Sat, 12 Jan 2013 15:14:43 +0000

bon je vais chercher ...
evolution est en cause
fichier envoyé par évolution récupéré par évolution : HS
fichier envoyé par évolution récupéré sans évolution : HS
fichier envoyé sans évolution récupéré sans evolution : OK (essai avec firefox et chromium)
fichier envoyé sans évolution récupéré par évolution : HS
donc
un fichier envoyé par évolution est corrompu lors de l'émission
un fichier récupéré par évolution est corrompu lors de la réception
maintenant où chercher dans les paramètres d'évolution ?
ce qui me chiffonne ce même fichier si je lui mets une extension de nom ".xxx" , devient correct et en émission et en réception

Réponse à : disparition 0D 0A

dummy@example.com (Vu) — Fri, 11 Jan 2013 22:31:07 +0000

Essayes de voir si Thunderbird permettrait de résoudre le problème ou de regarder dans les paramètres d'Évolution. De mémoire celui-ci permet des réglages assez fin après il faut savoir où chercher.

Réponse à : disparition 0D 0A

dummy@example.com (ar barzh paour) — Fri, 11 Jan 2013 19:05:12 +0000

merci de vous être penchés sur mon problème
j'utilise firefox comme navigateur et evolution comme courrielleur
je dirais qu'à priori evolution serait en cause
connexion avec firefox sur le serveur de mail : pas de problème
connexion avec chromium sur le serveur de mail : pas de problème
connexion via evolution : là il y a problème
le fichier bien que réellement "binaire" serait vu par evolution comme étant un fichier texte à cause de ces 0D 0A .. c'est bizarre

Réponse à : disparition 0D 0A

dummy@example.com (Vu) — Fri, 11 Jan 2013 16:50:14 +0000

Bonjour,

à la suite d' anomalies indiquées par mes correspondants lors de l'envoi par mail que je fais sur certains fichiers

Tu les fais comment ces envois: avec Thunderbird ou avec un navigateur web ??

Réponse à : disparition 0D 0A

dummy@example.com (tiramiseb) — Fri, 11 Jan 2013 11:42:26 +0000

En effet, 0D est le code ascii du retour chariot (CR) et 0A est le code ascii du saut de ligne (LF).

Certains systèmes (notamment Windows) utilisent les deux codes conjoints (on appelle ça CRLF) pour notifier une nouvelle ligne (c'est le fonctionnement des machines à écrire). D'autres systèmes (comme Linux) n'utilisent que 0A.

Dans la mesure où les codes 41, 42 et 43 sont ceux de A, B et C, il est fort possible qu'un logiciel (client mail ? serveur ?) interprète ce fichier comme un fichier texte contenant "A" puis "B" puis "C" puis un changement de ligne et remplace CRLF (0D0A) par LF (0A) seul. Et avec l'extension ".bin", le logiciel en question estime que c'est un fichier binaire et ne va pas trifouiller dedans.

Réponse à : disparition 0D 0A

dummy@example.com (Braun) — Fri, 11 Jan 2013 11:09:07 +0000

Bonjour,
Sauf erreur de ma part le code 0x0D [ctrl][M] est le "retour chariot" et le code 0x0A [ctrl][J] le code "linefeed".
Les deux sont utilisés en mode texte pour délimiter les lignes, mais le choix du délimiteur dépend du système et seuls quelques OS utilisent la conjonction des deux.
J'ai eu jadis des problèmes avec latex2html (Linux) qui n'appréciait pas les codes sources créés sous Mac OS 9 avec Emacs... mais un copié collé dans un fichier Latex créé par Linux résolvait complètement le problème en changeant le délimiteur.