Test.
--
Manfred
Middle Of Nowhere
iMac Intel Core 2 Duo, early 2009, OS X 10.11.6
"I would trade all my technology for an afternoon with Socrates."(S.J.)
Le 11/09/2019 21:44, Gilbert OLIVIER héhè a écrit :
Le 11 sep 2019, Pierre Pallier a écrit:
Hello, =?UTF-8?Q?Manfred La Cassagnère a écrit dans <news:qlb5pi$tmj$
Test.
Le From est original, en tout cas...
Aller je vais essayer de faire plaisir à tous, test d'un autre encodage dans le header ;-)
Ce n'est pas UTF-8 qui posait problème, mais le fait d'encoder l'adresse en plus du nom. Il vaut mieux garder UTF-8.
C'est ce que j'ai compris hier soir mais c'était l'heure d'aller faire dodo ;-) Si mon café matinal à fait son effet, cela devrait aller maintenant...
bonjour ;-) MacCafé sera payant ? -- / Croire c'est le contraire de savoir, -- o -- si j'y crois, je ne sais pas, / si je sais, pas la peine d'y croire. --> Je Croix Pas, car Je Sais que c'est Faux MalgRê TouT...
> Le 11/09/2019 21:44, Gilbert OLIVIER héhè <gilbert.olivier@orange.fr> a
> écrit :
>> Le 11 sep 2019, Pierre Pallier a écrit:
>>
>>> Hello, =?UTF-8?Q?Manfred La Cassagnère a écrit dans
>>> <news:qlb5pi$tmj$1@dont-email.me>
>>>
>>>> Test.
>>>
>>> Le From est original, en tout cas...
>>
>> Aller je vais essayer de faire plaisir à tous, test d'un autre
>> encodage dans le header ;-)
>
> Ce n'est pas UTF-8 qui posait problème, mais le fait d'encoder
> l'adresse en plus du nom. Il vaut mieux garder UTF-8.
>
C'est ce que j'ai compris hier soir mais c'était l'heure d'aller faire
dodo ;-)
Si mon café matinal à fait son effet, cela devrait aller maintenant...
bonjour ;-)
MacCafé sera payant ?
--
/ Croire c'est le contraire de savoir,
-- o -- si j'y crois, je ne sais pas,
/ si je sais, pas la peine d'y croire.
--> Je Croix Pas, car Je Sais que c'est Faux MalgRê TouT...
Le 11/09/2019 21:44, Gilbert OLIVIER héhè a écrit :
Le 11 sep 2019, Pierre Pallier a écrit:
Hello, =?UTF-8?Q?Manfred La Cassagnère a écrit dans <news:qlb5pi$tmj$
Test.
Le From est original, en tout cas...
Aller je vais essayer de faire plaisir à tous, test d'un autre encodage dans le header ;-)
Ce n'est pas UTF-8 qui posait problème, mais le fait d'encoder l'adresse en plus du nom. Il vaut mieux garder UTF-8.
C'est ce que j'ai compris hier soir mais c'était l'heure d'aller faire dodo ;-) Si mon café matinal à fait son effet, cela devrait aller maintenant...
bonjour ;-) MacCafé sera payant ? -- / Croire c'est le contraire de savoir, -- o -- si j'y crois, je ne sais pas, / si je sais, pas la peine d'y croire. --> Je Croix Pas, car Je Sais que c'est Faux MalgRê TouT...
Olivier Miakinen
Le 12/09/2019 11:14, Gilbert OLIVIER a écrit :
Le 12 sep 2019, Olivier Miakinen a écrit:
Oui, je confirme que le bug est corrigé. Pour bien faire tu pourrais mettre des _ à la place des pour rendre le quoted-printable plus lisible. Bien sûr, ce sont les _ qu'il faut encoder, et j'en ai ajouté un dans le titre pour voir ce que ça donnera dans ta réponse.
Ben le "_" apparait dans le sujet, dans MacSoup pareil, ce qui me semble normal.
Oui, car il est correctement encodé _ dans ta réponse au lieu d'être laissé tel quel. Sinon, il serait devenu une espace.
"Re: Test serveur avé des hù_hù" Je me sers des fonctions iconv... , et de toute façon si je traitait l'encodage pour transformer les en _ je pense que je ne serai compatible qu'avec moi même.
Bien sûr que non, puisque c'est dans la norme : <https://tools.ietf.org/html/rfc2047#section-4.2> § (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be represented as "_" (underscore, ASCII 95.). (This character may not pass through some internetwork mail gateways, but its use will greatly enhance readability of "Q" encoded data with mail readers that do not support this encoding.) Note that the "_" always represents hexadecimal 20, even if the SPACE character occupies a different code position in the character set in use. §
Sinon le champ References devrait être bien plus conforme à partir de ce message.
Oui, sauf pour le point suivant : <https://tools.ietf.org/html/rfc5536#section-3.2.10> § o Message identifiers MUST be separated with CFWS. § C'est-à-dire que les identifiants qui sont sur une même ligne doivent être séparés par une espace. Note que du coup cela simplifie énormément la coupure des lignes trop longues, puisqu'il suffit d'ajouter un CRLF avant l'espace plutôt que de chercher des séquences « >< » et d'ajouter CRLF+SPACE au milieu. -- Olivier Miakinen
Le 12/09/2019 11:14, Gilbert OLIVIER a écrit :
Le 12 sep 2019, Olivier Miakinen a écrit:
Oui, je confirme que le bug est corrigé.
Pour bien faire tu pourrais mettre des _ à la place des pour rendre
le quoted-printable plus lisible. Bien sûr, ce sont les _ qu'il faut
encoder, et j'en ai ajouté un dans le titre pour voir ce que ça donnera
dans ta réponse.
Ben le "_" apparait dans le sujet, dans MacSoup pareil, ce qui me
semble normal.
Oui, car il est correctement encodé _ dans ta réponse au lieu d'être
laissé tel quel. Sinon, il serait devenu une espace.
"Re: Test serveur avé des hù_hù"
Je me sers des fonctions iconv... , et de toute façon si je traitait
l'encodage pour transformer les en _ je pense que je ne serai
compatible qu'avec moi même.
Bien sûr que non, puisque c'est dans la norme :
<https://tools.ietf.org/html/rfc2047#section-4.2>
§
(2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
represented as "_" (underscore, ASCII 95.). (This character may
not pass through some internetwork mail gateways, but its use
will greatly enhance readability of "Q" encoded data with mail
readers that do not support this encoding.) Note that the "_"
always represents hexadecimal 20, even if the SPACE character
occupies a different code position in the character set in use.
§
Sinon le champ References devrait être bien plus conforme à partir de
ce message.
Oui, sauf pour le point suivant :
<https://tools.ietf.org/html/rfc5536#section-3.2.10>
§
o Message identifiers MUST be separated with CFWS.
§
C'est-à-dire que les identifiants qui sont sur une même ligne doivent
être séparés par une espace. Note que du coup cela simplifie énormément
la coupure des lignes trop longues, puisqu'il suffit d'ajouter un CRLF
avant l'espace plutôt que de chercher des séquences « >< » et d'ajouter
CRLF+SPACE au milieu.
Oui, je confirme que le bug est corrigé. Pour bien faire tu pourrais mettre des _ à la place des pour rendre le quoted-printable plus lisible. Bien sûr, ce sont les _ qu'il faut encoder, et j'en ai ajouté un dans le titre pour voir ce que ça donnera dans ta réponse.
Ben le "_" apparait dans le sujet, dans MacSoup pareil, ce qui me semble normal.
Oui, car il est correctement encodé _ dans ta réponse au lieu d'être laissé tel quel. Sinon, il serait devenu une espace.
"Re: Test serveur avé des hù_hù" Je me sers des fonctions iconv... , et de toute façon si je traitait l'encodage pour transformer les en _ je pense que je ne serai compatible qu'avec moi même.
Bien sûr que non, puisque c'est dans la norme : <https://tools.ietf.org/html/rfc2047#section-4.2> § (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be represented as "_" (underscore, ASCII 95.). (This character may not pass through some internetwork mail gateways, but its use will greatly enhance readability of "Q" encoded data with mail readers that do not support this encoding.) Note that the "_" always represents hexadecimal 20, even if the SPACE character occupies a different code position in the character set in use. §
Sinon le champ References devrait être bien plus conforme à partir de ce message.
Oui, sauf pour le point suivant : <https://tools.ietf.org/html/rfc5536#section-3.2.10> § o Message identifiers MUST be separated with CFWS. § C'est-à-dire que les identifiants qui sont sur une même ligne doivent être séparés par une espace. Note que du coup cela simplifie énormément la coupure des lignes trop longues, puisqu'il suffit d'ajouter un CRLF avant l'espace plutôt que de chercher des séquences « >< » et d'ajouter CRLF+SPACE au milieu. -- Olivier Miakinen
Olivier Miakinen
Le 12/09/2019 11:56, je répondais à Gilbert OLIVIER :
Je me sers des fonctions iconv... , et de toute façon si je traitait l'encodage pour transformer les en _ je pense que je ne serai compatible qu'avec moi même.
Bien sûr que non, puisque c'est dans la norme : <https://tools.ietf.org/html/rfc2047#section-4.2> § (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be represented as "_" (underscore, ASCII 95.). (This character may not pass through some internetwork mail gateways, but its use will greatly enhance readability of "Q" encoded data with mail readers that do not support this encoding.) Note that the "_" always represents hexadecimal 20, even if the SPACE character occupies a different code position in the character set in use. §
Voici un exemple pris au hasard sur fr.rec.bricolage : <news:5d558b62$0$20317$ <http://al.howardknight.net/?ID6828341400> § From: =?UTF-8?Q?Gérard_LAMBERT?= Subject: =?UTF-8?Q?Stabilité_cuvette_WC? § Une fois interprété, ça donne : De : Gérard LAMBERT Sujet : Stabilité cuvette WC -- Olivier Miakinen
Le 12/09/2019 11:56, je répondais à Gilbert OLIVIER :
Je me sers des fonctions iconv... , et de toute façon si je traitait
l'encodage pour transformer les en _ je pense que je ne serai
compatible qu'avec moi même.
Bien sûr que non, puisque c'est dans la norme :
<https://tools.ietf.org/html/rfc2047#section-4.2>
§
(2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
represented as "_" (underscore, ASCII 95.). (This character may
not pass through some internetwork mail gateways, but its use
will greatly enhance readability of "Q" encoded data with mail
readers that do not support this encoding.) Note that the "_"
always represents hexadecimal 20, even if the SPACE character
occupies a different code position in the character set in use.
§
Voici un exemple pris au hasard sur fr.rec.bricolage :
Le 12/09/2019 11:56, je répondais à Gilbert OLIVIER :
Je me sers des fonctions iconv... , et de toute façon si je traitait l'encodage pour transformer les en _ je pense que je ne serai compatible qu'avec moi même.
Bien sûr que non, puisque c'est dans la norme : <https://tools.ietf.org/html/rfc2047#section-4.2> § (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be represented as "_" (underscore, ASCII 95.). (This character may not pass through some internetwork mail gateways, but its use will greatly enhance readability of "Q" encoded data with mail readers that do not support this encoding.) Note that the "_" always represents hexadecimal 20, even if the SPACE character occupies a different code position in the character set in use. §
Voici un exemple pris au hasard sur fr.rec.bricolage : <news:5d558b62$0$20317$ <http://al.howardknight.net/?ID6828341400> § From: =?UTF-8?Q?Gérard_LAMBERT?= Subject: =?UTF-8?Q?Stabilité_cuvette_WC? § Une fois interprété, ça donne : De : Gérard LAMBERT Sujet : Stabilité cuvette WC -- Olivier Miakinen
Gilbert OLIVIER
Le 12 sep 2019, Olivier Miakinen a écrit:
Ben le "_" apparait dans le sujet, dans MacSoup pareil, ce qui me semble normal.
Oui, car il est correctement encodé _ dans ta réponse au lieu d'être laissé tel quel. Sinon, il serait devenu une espace.
Je parlais comment vois de ton message dans MacSoup, là, ce n'est pas moi qui encode ;-)
"Re: Test serveur avé des hù_hù"
<https://tools.ietf.org/html/rfc2047#section-4.2> § (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be represented as "_" (underscore, ASCII 95.). (This character may not pass through some internetwork mail gateways, but its use will greatly enhance readability of "Q" encoded data with mail readers that do not support this encoding.) Note that the "_" always represents hexadecimal 20, even if the SPACE character occupies a different code position in the character set in use. §
Plus de problème maintenat, plus de comme Mozilla c'est codé en base64.
Sinon le champ References devrait être bien plus conforme à partir de ce message.
Oui, sauf pour le point suivant : <https://tools.ietf.org/html/rfc5536#section-3.2.10> § o Message identifiers MUST be separated with CFWS. §
Corrigé, merci. -- Gilbert
Le 12 sep 2019, Olivier Miakinen a écrit:
Ben le "_" apparait dans le sujet, dans MacSoup pareil, ce qui me
semble normal.
Oui, car il est correctement encodé _ dans ta réponse au lieu d'être
laissé tel quel. Sinon, il serait devenu une espace.
Je parlais comment vois de ton message dans MacSoup, là, ce n'est pas
moi qui encode ;-)
"Re: Test serveur avé des hù_hù"
<https://tools.ietf.org/html/rfc2047#section-4.2>
§
(2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
represented as "_" (underscore, ASCII 95.). (This character may
not pass through some internetwork mail gateways, but its use
will greatly enhance readability of "Q" encoded data with mail
readers that do not support this encoding.) Note that the "_"
always represents hexadecimal 20, even if the SPACE character
occupies a different code position in the character set in use.
§
Plus de problème maintenat, plus de comme Mozilla c'est codé en
base64.
Sinon le champ References devrait être bien plus conforme à partir de
ce message.
Oui, sauf pour le point suivant :
<https://tools.ietf.org/html/rfc5536#section-3.2.10>
§
o Message identifiers MUST be separated with CFWS.
§
Ben le "_" apparait dans le sujet, dans MacSoup pareil, ce qui me semble normal.
Oui, car il est correctement encodé _ dans ta réponse au lieu d'être laissé tel quel. Sinon, il serait devenu une espace.
Je parlais comment vois de ton message dans MacSoup, là, ce n'est pas moi qui encode ;-)
"Re: Test serveur avé des hù_hù"
<https://tools.ietf.org/html/rfc2047#section-4.2> § (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be represented as "_" (underscore, ASCII 95.). (This character may not pass through some internetwork mail gateways, but its use will greatly enhance readability of "Q" encoded data with mail readers that do not support this encoding.) Note that the "_" always represents hexadecimal 20, even if the SPACE character occupies a different code position in the character set in use. §
Plus de problème maintenat, plus de comme Mozilla c'est codé en base64.
Sinon le champ References devrait être bien plus conforme à partir de ce message.
Oui, sauf pour le point suivant : <https://tools.ietf.org/html/rfc5536#section-3.2.10> § o Message identifiers MUST be separated with CFWS. §
Corrigé, merci. -- Gilbert
Olivier Miakinen
Le 12/09/2019 12:29, Gilbert OLIVIER a écrit :
Ben le "_" apparait dans le sujet, dans MacSoup pareil, ce qui me semble normal.
Oui, car il est correctement encodé _ dans ta réponse au lieu d'être laissé tel quel. Sinon, il serait devenu une espace.
Je parlais comment vois de ton message dans MacSoup, là, ce n'est pas moi qui encode ;-)
Et moi je parlais de comment Mac Café l'avait réencodé dans ta réponse.
"Re: Test serveur avé des hù_hù"
<https://tools.ietf.org/html/rfc2047#section-4.2> § (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be represented as "_" (underscore, ASCII 95.). (This character may not pass through some internetwork mail gateways, but its use will greatly enhance readability of "Q" encoded data with mail readers that do not support this encoding.) Note that the "_" always represents hexadecimal 20, even if the SPACE character occupies a different code position in the character set in use. §
Plus de problème maintenat, plus de comme Mozilla c'est codé en base64.
Je trouve ça dommage, et c'est justement un gros reproche que je fais à Mozilla pour les sujets en français (rien à dire pour ceux en japonais).
Sinon le champ References devrait être bien plus conforme à partir de ce message.
Oui, sauf pour le point suivant : <https://tools.ietf.org/html/rfc5536#section-3.2.10> § o Message identifiers MUST be separated with CFWS. §
Corrigé, merci.
Oui, c'est parfait. Merci à toi. -- Olivier Miakinen
Le 12/09/2019 12:29, Gilbert OLIVIER a écrit :
Ben le "_" apparait dans le sujet, dans MacSoup pareil, ce qui me
semble normal.
Oui, car il est correctement encodé _ dans ta réponse au lieu d'être
laissé tel quel. Sinon, il serait devenu une espace.
Je parlais comment vois de ton message dans MacSoup, là, ce n'est pas
moi qui encode ;-)
Et moi je parlais de comment Mac Café l'avait réencodé dans ta réponse.
"Re: Test serveur avé des hù_hù"
<https://tools.ietf.org/html/rfc2047#section-4.2>
§
(2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
represented as "_" (underscore, ASCII 95.). (This character may
not pass through some internetwork mail gateways, but its use
will greatly enhance readability of "Q" encoded data with mail
readers that do not support this encoding.) Note that the "_"
always represents hexadecimal 20, even if the SPACE character
occupies a different code position in the character set in use.
§
Plus de problème maintenat, plus de comme Mozilla c'est codé en
base64.
Je trouve ça dommage, et c'est justement un gros reproche que je fais
à Mozilla pour les sujets en français (rien à dire pour ceux en
japonais).
Sinon le champ References devrait être bien plus conforme à partir de
ce message.
Oui, sauf pour le point suivant :
<https://tools.ietf.org/html/rfc5536#section-3.2.10>
§
o Message identifiers MUST be separated with CFWS.
§
Ben le "_" apparait dans le sujet, dans MacSoup pareil, ce qui me semble normal.
Oui, car il est correctement encodé _ dans ta réponse au lieu d'être laissé tel quel. Sinon, il serait devenu une espace.
Je parlais comment vois de ton message dans MacSoup, là, ce n'est pas moi qui encode ;-)
Et moi je parlais de comment Mac Café l'avait réencodé dans ta réponse.
"Re: Test serveur avé des hù_hù"
<https://tools.ietf.org/html/rfc2047#section-4.2> § (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be represented as "_" (underscore, ASCII 95.). (This character may not pass through some internetwork mail gateways, but its use will greatly enhance readability of "Q" encoded data with mail readers that do not support this encoding.) Note that the "_" always represents hexadecimal 20, even if the SPACE character occupies a different code position in the character set in use. §
Plus de problème maintenat, plus de comme Mozilla c'est codé en base64.
Je trouve ça dommage, et c'est justement un gros reproche que je fais à Mozilla pour les sujets en français (rien à dire pour ceux en japonais).
Sinon le champ References devrait être bien plus conforme à partir de ce message.
Oui, sauf pour le point suivant : <https://tools.ietf.org/html/rfc5536#section-3.2.10> § o Message identifiers MUST be separated with CFWS. §
Corrigé, merci.
Oui, c'est parfait. Merci à toi. -- Olivier Miakinen
Olivier Miakinen
Le 12/09/2019 à 12:35, je répondais à Gilbert OLIVIER :
Plus de problème maintenat, plus de comme Mozilla c'est codé en base64.
Je trouve ça dommage, et c'est justement un gros reproche que je fais à Mozilla pour les sujets en français (rien à dire pour ceux en japonais).
Et finalement je comprends le choix fait par Mozilla, si le but est de choisir l'encodage le plus léger possible (en nombres d'octets). En effet, en supposant un texte n'utilisant que des caractères ASCII 7 bits (lettres non accentuées en particulier) et des caractères non-ASCII se trouvant dans ISO8859-1 (lettres accentuées du français), je viens de calculer qu'il faut moins d'une lettre accentuée tous les 15 caractères pour que le quoted-printable soit plus économe que le base64. -- Olivier Miakinen
Le 12/09/2019 à 12:35, je répondais à Gilbert OLIVIER :
Plus de problème maintenat, plus de comme Mozilla c'est codé en
base64.
Je trouve ça dommage, et c'est justement un gros reproche que je fais
à Mozilla pour les sujets en français (rien à dire pour ceux en
japonais).
Et finalement je comprends le choix fait par Mozilla, si le but
est de choisir l'encodage le plus léger possible (en nombres
d'octets).
En effet, en supposant un texte n'utilisant que des caractères ASCII
7 bits (lettres non accentuées en particulier) et des caractères
non-ASCII se trouvant dans ISO8859-1 (lettres accentuées du français),
je viens de calculer qu'il faut moins d'une lettre accentuée tous les
15 caractères pour que le quoted-printable soit plus économe que le
base64.
Le 12/09/2019 à 12:35, je répondais à Gilbert OLIVIER :
Plus de problème maintenat, plus de comme Mozilla c'est codé en base64.
Je trouve ça dommage, et c'est justement un gros reproche que je fais à Mozilla pour les sujets en français (rien à dire pour ceux en japonais).
Et finalement je comprends le choix fait par Mozilla, si le but est de choisir l'encodage le plus léger possible (en nombres d'octets). En effet, en supposant un texte n'utilisant que des caractères ASCII 7 bits (lettres non accentuées en particulier) et des caractères non-ASCII se trouvant dans ISO8859-1 (lettres accentuées du français), je viens de calculer qu'il faut moins d'une lettre accentuée tous les 15 caractères pour que le quoted-printable soit plus économe que le base64. -- Olivier Miakinen
