Dans Panther, Mail comporte désormais une case à cocher "envoyer des
pièces jointes compatibles avec Windows". Peut-on en déduire que Mail
gère enfin correctement l'encodage des pièces jointes, ce qui était
jusqu'ici un de ses points faibles.
Si l'on coche "Envoyer des pièces jointes compatibles avec Windows" alors Mail supprime sans autre forme de procès la partie ressource du fichier, la deuxième section du email contiendra alors directement le fichier encodé (en base64). Ce mode correspond aussi au cas où le fichier joint n'a pas de ressource. L'appeler "compatibles avec Windows" n'est donc pas tout à fait exacte, ce serait plutôt "supprimer les ressources HFS" du fichier.
Tu crois que c'est juste ca ? C'est pas une histoire que microsoft fait son propre protocol ?
Éric Lévénez <news@levenez.com> wrote:
Si l'on coche "Envoyer des pièces jointes compatibles avec Windows" alors
Mail supprime sans autre forme de procès la partie ressource du fichier, la
deuxième section du email contiendra alors directement le fichier encodé (en
base64). Ce mode correspond aussi au cas où le fichier joint n'a pas de
ressource. L'appeler "compatibles avec Windows" n'est donc pas tout à fait
exacte, ce serait plutôt "supprimer les ressources HFS" du fichier.
Tu crois que c'est juste ca ? C'est pas une histoire que microsoft fait
son propre protocol ?
Si l'on coche "Envoyer des pièces jointes compatibles avec Windows" alors Mail supprime sans autre forme de procès la partie ressource du fichier, la deuxième section du email contiendra alors directement le fichier encodé (en base64). Ce mode correspond aussi au cas où le fichier joint n'a pas de ressource. L'appeler "compatibles avec Windows" n'est donc pas tout à fait exacte, ce serait plutôt "supprimer les ressources HFS" du fichier.
Tu crois que c'est juste ca ? C'est pas une histoire que microsoft fait son propre protocol ?
Éric Lévénez
Le 9/12/03 22:15, dans <1g5q0g6.1d1eal9fp7xvkN%, « Jérôme Lebel » a écrit :
Éric Lévénez wrote:
Si l'on coche "Envoyer des pièces jointes compatibles avec Windows" alors Mail supprime sans autre forme de procès la partie ressource du fichier, la deuxième section du email contiendra alors directement le fichier encodé (en base64). Ce mode correspond aussi au cas où le fichier joint n'a pas de ressource. L'appeler "compatibles avec Windows" n'est donc pas tout à fait exacte, ce serait plutôt "supprimer les ressources HFS" du fichier.
Tu crois que c'est juste ca ?
Oui. Pour tester il suffit de s'envoyer un email et de regarder le codage avec un éditeur dans le fichier mbox du wrappper .mbox.
C'est pas une histoire que microsoft fait son propre protocol ?
Où as-tu lu ça ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 9/12/03 22:15, dans <1g5q0g6.1d1eal9fp7xvkN%jeromelebel@mac.com>,
« Jérôme Lebel » <jeromelebel@mac.com> a écrit :
Éric Lévénez <news@levenez.com> wrote:
Si l'on coche "Envoyer des pièces jointes compatibles avec Windows" alors
Mail supprime sans autre forme de procès la partie ressource du fichier, la
deuxième section du email contiendra alors directement le fichier encodé (en
base64). Ce mode correspond aussi au cas où le fichier joint n'a pas de
ressource. L'appeler "compatibles avec Windows" n'est donc pas tout à fait
exacte, ce serait plutôt "supprimer les ressources HFS" du fichier.
Tu crois que c'est juste ca ?
Oui. Pour tester il suffit de s'envoyer un email et de regarder le codage
avec un éditeur dans le fichier mbox du wrappper .mbox.
C'est pas une histoire que microsoft fait
son propre protocol ?
Où as-tu lu ça ?
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 9/12/03 22:15, dans <1g5q0g6.1d1eal9fp7xvkN%, « Jérôme Lebel » a écrit :
Éric Lévénez wrote:
Si l'on coche "Envoyer des pièces jointes compatibles avec Windows" alors Mail supprime sans autre forme de procès la partie ressource du fichier, la deuxième section du email contiendra alors directement le fichier encodé (en base64). Ce mode correspond aussi au cas où le fichier joint n'a pas de ressource. L'appeler "compatibles avec Windows" n'est donc pas tout à fait exacte, ce serait plutôt "supprimer les ressources HFS" du fichier.
Tu crois que c'est juste ca ?
Oui. Pour tester il suffit de s'envoyer un email et de regarder le codage avec un éditeur dans le fichier mbox du wrappper .mbox.
C'est pas une histoire que microsoft fait son propre protocol ?
Où as-tu lu ça ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
jeromelebel
Éric Lévénez wrote:
C'est pas une histoire que microsoft fait son propre protocol ?
Où as-tu lu ça ?
Nul part, j'imaginais que des personnes se plaignaient que les attachements ne passaient pas correctement (ca m'ai arrivé, enfin surtout en reception), et qu'apple avait trouvé le moyen de s'adapter a windows. Et puis microsoft ne pas respecter une norme, ca me semblait evident :-)
Éric Lévénez <news@levenez.com> wrote:
C'est pas une histoire que microsoft fait
son propre protocol ?
Où as-tu lu ça ?
Nul part, j'imaginais que des personnes se plaignaient que les
attachements ne passaient pas correctement (ca m'ai arrivé, enfin
surtout en reception), et qu'apple avait trouvé le moyen de s'adapter a
windows.
Et puis microsoft ne pas respecter une norme, ca me semblait evident :-)
C'est pas une histoire que microsoft fait son propre protocol ?
Où as-tu lu ça ?
Nul part, j'imaginais que des personnes se plaignaient que les attachements ne passaient pas correctement (ca m'ai arrivé, enfin surtout en reception), et qu'apple avait trouvé le moyen de s'adapter a windows. Et puis microsoft ne pas respecter une norme, ca me semblait evident :-)
Éric Lévénez
Le 9/12/03 23:26, dans <1g5q3og.1hugrb5givcbuN%, « Jérôme Lebel » a écrit :
Éric Lévénez wrote:
C'est pas une histoire que microsoft fait son propre protocol ?
Où as-tu lu ça ?
Nul part, j'imaginais que des personnes se plaignaient que les attachements ne passaient pas correctement (ca m'ai arrivé, enfin surtout en reception), et qu'apple avait trouvé le moyen de s'adapter a windows.
Le problème ne vient pas de Windows (ou de Linux, ou d'Unix, ou de n'importe quelle plateforme non Mac), mais vient des ressources HFS. Apple aurait aussi pu mettre "Compatible Unix" sur son option.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 9/12/03 23:26, dans <1g5q3og.1hugrb5givcbuN%jeromelebel@mac.com>,
« Jérôme Lebel » <jeromelebel@mac.com> a écrit :
Éric Lévénez <news@levenez.com> wrote:
C'est pas une histoire que microsoft fait
son propre protocol ?
Où as-tu lu ça ?
Nul part, j'imaginais que des personnes se plaignaient que les
attachements ne passaient pas correctement (ca m'ai arrivé, enfin
surtout en reception), et qu'apple avait trouvé le moyen de s'adapter a
windows.
Le problème ne vient pas de Windows (ou de Linux, ou d'Unix, ou de n'importe
quelle plateforme non Mac), mais vient des ressources HFS. Apple aurait
aussi pu mettre "Compatible Unix" sur son option.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 9/12/03 23:26, dans <1g5q3og.1hugrb5givcbuN%, « Jérôme Lebel » a écrit :
Éric Lévénez wrote:
C'est pas une histoire que microsoft fait son propre protocol ?
Où as-tu lu ça ?
Nul part, j'imaginais que des personnes se plaignaient que les attachements ne passaient pas correctement (ca m'ai arrivé, enfin surtout en reception), et qu'apple avait trouvé le moyen de s'adapter a windows.
Le problème ne vient pas de Windows (ou de Linux, ou d'Unix, ou de n'importe quelle plateforme non Mac), mais vient des ressources HFS. Apple aurait aussi pu mettre "Compatible Unix" sur son option.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
herve.nospam
Salut,
Je reviens sur les explications détaillées données par Eric :
Éric Lévénez wrote in message news:<BBFA6B02.61CBE%...
Maintenant si l'on regarde comment est encodé un simple email sous Mail. Supposons que l'on ait du texte, puis un fichier Mac, puis encore du texte. À l'écran on voit une icône entouré de texte. Si on émet cet email alors il arrivera en 3 sections. La première contient le texte du début, la deuxième contient le fichier, et la troisième le texte de fin. Le problème vient du fait que la deuxième section est codée en AppleDouble (un RFC jamais ratifié et donc ignoré sur les autres plateformes).
Et qu'en est-il dans le cas d'Eudora : 1. Lors de l'_envoi_ d'un message, où les pièces jointes n'apparaissent pas dans le corps du message comme avec Mail, mais dans un des champs d'en-tête (X-Attachements) ? 2. Lors de la réception d'un message, où les pièces jointes apparaissent : - parfois sous la forme d'une icone + nom de fichier dans le champ "X-Attachments" des en-têtes, - parfois sous la forme d'une icone + nom de fichier à la fin du message, - parfois (notamment dans le cas d'une image) sous la forme des lignes suivantes : Content-Type: image/jpeg; name="106_0697.JPG" Content-Description: 106_0697.JPG Content-Disposition: attachment; filename="106_0697.JPG" suivies de l'image elle-même, suivie du nom du fichier.
Hervé
Salut,
Je reviens sur les explications détaillées données par Eric :
Éric Lévénez <news@levenez.com> wrote in message news:<BBFA6B02.61CBE%news@levenez.com>...
Maintenant si l'on regarde comment est encodé un simple email sous Mail.
Supposons que l'on ait du texte, puis un fichier Mac, puis encore du texte.
À l'écran on voit une icône entouré de texte. Si on émet cet email alors il
arrivera en 3 sections. La première contient le texte du début, la deuxième
contient le fichier, et la troisième le texte de fin. Le problème vient du
fait que la deuxième section est codée en AppleDouble (un RFC jamais ratifié
et donc ignoré sur les autres plateformes).
Et qu'en est-il dans le cas d'Eudora :
1. Lors de l'_envoi_ d'un message, où les pièces jointes
n'apparaissent pas dans le corps du message comme avec Mail, mais dans
un des champs d'en-tête (X-Attachements) ?
2. Lors de la réception d'un message, où les pièces jointes
apparaissent :
- parfois sous la forme d'une icone + nom de fichier dans le champ
"X-Attachments" des en-têtes,
- parfois sous la forme d'une icone + nom de fichier à la fin du
message,
- parfois (notamment dans le cas d'une image) sous la forme des lignes
suivantes :
Content-Type: image/jpeg;
name="106_0697.JPG"
Content-Description: 106_0697.JPG
Content-Disposition: attachment;
filename="106_0697.JPG"
suivies de l'image elle-même, suivie du nom du fichier.
Je reviens sur les explications détaillées données par Eric :
Éric Lévénez wrote in message news:<BBFA6B02.61CBE%...
Maintenant si l'on regarde comment est encodé un simple email sous Mail. Supposons que l'on ait du texte, puis un fichier Mac, puis encore du texte. À l'écran on voit une icône entouré de texte. Si on émet cet email alors il arrivera en 3 sections. La première contient le texte du début, la deuxième contient le fichier, et la troisième le texte de fin. Le problème vient du fait que la deuxième section est codée en AppleDouble (un RFC jamais ratifié et donc ignoré sur les autres plateformes).
Et qu'en est-il dans le cas d'Eudora : 1. Lors de l'_envoi_ d'un message, où les pièces jointes n'apparaissent pas dans le corps du message comme avec Mail, mais dans un des champs d'en-tête (X-Attachements) ? 2. Lors de la réception d'un message, où les pièces jointes apparaissent : - parfois sous la forme d'une icone + nom de fichier dans le champ "X-Attachments" des en-têtes, - parfois sous la forme d'une icone + nom de fichier à la fin du message, - parfois (notamment dans le cas d'une image) sous la forme des lignes suivantes : Content-Type: image/jpeg; name="106_0697.JPG" Content-Description: 106_0697.JPG Content-Disposition: attachment; filename="106_0697.JPG" suivies de l'image elle-même, suivie du nom du fichier.
Hervé
Éric Lévénez
Le 10/12/03 9:23, dans , « herve » a écrit :
Salut,
Je reviens sur les explications détaillées données par Eric :
Éric Lévénez wrote in message news:<BBFA6B02.61CBE%...
Maintenant si l'on regarde comment est encodé un simple email sous Mail. Supposons que l'on ait du texte, puis un fichier Mac, puis encore du texte. À l'écran on voit une icône entouré de texte. Si on émet cet email alors il arrivera en 3 sections. La première contient le texte du début, la deuxième contient le fichier, et la troisième le texte de fin. Le problème vient du fait que la deuxième section est codée en AppleDouble (un RFC jamais ratifié et donc ignoré sur les autres plateformes).
Et qu'en est-il dans le cas d'Eudora :
Aucune idée, je n'ai pas Eudora.
1. Lors de l'_envoi_ d'un message, où les pièces jointes n'apparaissent pas dans le corps du message comme avec Mail, mais dans un des champs d'en-tête (X-Attachements) ? 2. Lors de la réception d'un message, où les pièces jointes apparaissent : - parfois sous la forme d'une icone + nom de fichier dans le champ "X-Attachments" des en-têtes, - parfois sous la forme d'une icone + nom de fichier à la fin du message, - parfois (notamment dans le cas d'une image) sous la forme des lignes suivantes : Content-Type: image/jpeg; name="106_0697.JPG" Content-Description: 106_0697.JPG Content-Disposition: attachment; filename="106_0697.JPG" suivies de l'image elle-même, suivie du nom du fichier.
Le champ Content-Disposition permet à l'émetteur de préciser la position de la section Mime (aka pièce jointe) par rapport à la section du dessus (ou au corps du message si on est au niveau supérieur). On peut mettre "inline" et "attachment". Dans le premier cas l'affichage peut se faire dans le corps du document (genre une image au milieu de texte), dans le second cas, l'affichage peut se faire à l'extérieur du document (dans une fenêtres...). Certains mailers ne savent pas gérer cela lors de la création d'un email, d'autres ne savent pas gérer cela à la lecture d'un email. Beaucoup de mailers ne savent pas gérer le inline et considèrent tout comme des attachment. Une section en mode attachment peut aussi être affichée de 2 manières : en inline (si possible) et en attachment. Lié à la section mime il y a des tas de champs standard (filename, creation-date, modification-date, read-date...).
Il n'y a pas de champx X-Attachments normalisé car tout ce qui commence par x indique des extensions. Alors que Eudora traite ou non ce champ et que d'autres mailers ne le traite pas me semble "normal".
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 10/12/03 9:23, dans <df8aa16d.0312100023.2456b9a9@posting.google.com>,
« herve » <herve.nospam@tiscali.fr> a écrit :
Salut,
Je reviens sur les explications détaillées données par Eric :
Éric Lévénez <news@levenez.com> wrote in message
news:<BBFA6B02.61CBE%news@levenez.com>...
Maintenant si l'on regarde comment est encodé un simple email sous Mail.
Supposons que l'on ait du texte, puis un fichier Mac, puis encore du texte.
À l'écran on voit une icône entouré de texte. Si on émet cet email alors il
arrivera en 3 sections. La première contient le texte du début, la deuxième
contient le fichier, et la troisième le texte de fin. Le problème vient du
fait que la deuxième section est codée en AppleDouble (un RFC jamais ratifié
et donc ignoré sur les autres plateformes).
Et qu'en est-il dans le cas d'Eudora :
Aucune idée, je n'ai pas Eudora.
1. Lors de l'_envoi_ d'un message, où les pièces jointes
n'apparaissent pas dans le corps du message comme avec Mail, mais dans
un des champs d'en-tête (X-Attachements) ?
2. Lors de la réception d'un message, où les pièces jointes
apparaissent :
- parfois sous la forme d'une icone + nom de fichier dans le champ
"X-Attachments" des en-têtes,
- parfois sous la forme d'une icone + nom de fichier à la fin du
message,
- parfois (notamment dans le cas d'une image) sous la forme des lignes
suivantes :
Content-Type: image/jpeg;
name="106_0697.JPG"
Content-Description: 106_0697.JPG
Content-Disposition: attachment;
filename="106_0697.JPG"
suivies de l'image elle-même, suivie du nom du fichier.
Le champ Content-Disposition permet à l'émetteur de préciser la position de
la section Mime (aka pièce jointe) par rapport à la section du dessus (ou au
corps du message si on est au niveau supérieur). On peut mettre "inline" et
"attachment". Dans le premier cas l'affichage peut se faire dans le corps du
document (genre une image au milieu de texte), dans le second cas,
l'affichage peut se faire à l'extérieur du document (dans une fenêtres...).
Certains mailers ne savent pas gérer cela lors de la création d'un email,
d'autres ne savent pas gérer cela à la lecture d'un email. Beaucoup de
mailers ne savent pas gérer le inline et considèrent tout comme des
attachment. Une section en mode attachment peut aussi être affichée de 2
manières : en inline (si possible) et en attachment. Lié à la section mime
il y a des tas de champs standard (filename, creation-date,
modification-date, read-date...).
Il n'y a pas de champx X-Attachments normalisé car tout ce qui commence par
x indique des extensions. Alors que Eudora traite ou non ce champ et que
d'autres mailers ne le traite pas me semble "normal".
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Je reviens sur les explications détaillées données par Eric :
Éric Lévénez wrote in message news:<BBFA6B02.61CBE%...
Maintenant si l'on regarde comment est encodé un simple email sous Mail. Supposons que l'on ait du texte, puis un fichier Mac, puis encore du texte. À l'écran on voit une icône entouré de texte. Si on émet cet email alors il arrivera en 3 sections. La première contient le texte du début, la deuxième contient le fichier, et la troisième le texte de fin. Le problème vient du fait que la deuxième section est codée en AppleDouble (un RFC jamais ratifié et donc ignoré sur les autres plateformes).
Et qu'en est-il dans le cas d'Eudora :
Aucune idée, je n'ai pas Eudora.
1. Lors de l'_envoi_ d'un message, où les pièces jointes n'apparaissent pas dans le corps du message comme avec Mail, mais dans un des champs d'en-tête (X-Attachements) ? 2. Lors de la réception d'un message, où les pièces jointes apparaissent : - parfois sous la forme d'une icone + nom de fichier dans le champ "X-Attachments" des en-têtes, - parfois sous la forme d'une icone + nom de fichier à la fin du message, - parfois (notamment dans le cas d'une image) sous la forme des lignes suivantes : Content-Type: image/jpeg; name="106_0697.JPG" Content-Description: 106_0697.JPG Content-Disposition: attachment; filename="106_0697.JPG" suivies de l'image elle-même, suivie du nom du fichier.
Le champ Content-Disposition permet à l'émetteur de préciser la position de la section Mime (aka pièce jointe) par rapport à la section du dessus (ou au corps du message si on est au niveau supérieur). On peut mettre "inline" et "attachment". Dans le premier cas l'affichage peut se faire dans le corps du document (genre une image au milieu de texte), dans le second cas, l'affichage peut se faire à l'extérieur du document (dans une fenêtres...). Certains mailers ne savent pas gérer cela lors de la création d'un email, d'autres ne savent pas gérer cela à la lecture d'un email. Beaucoup de mailers ne savent pas gérer le inline et considèrent tout comme des attachment. Une section en mode attachment peut aussi être affichée de 2 manières : en inline (si possible) et en attachment. Lié à la section mime il y a des tas de champs standard (filename, creation-date, modification-date, read-date...).
Il n'y a pas de champx X-Attachments normalisé car tout ce qui commence par x indique des extensions. Alors que Eudora traite ou non ce champ et que d'autres mailers ne le traite pas me semble "normal".
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
