Et vu de 40Tude Dialog, ça s'affiche correctement à l'arrivée aussi...
C'est super intéressant ! En effet le code source montre des choses différentes. J'analyse tout ça dès que je le peux. -- Olivier Miakinen
yamo'
Salut, Olivier Miakinen a écrit le 18/12/2018 à 01:37 :
Le 17/12/2018 23:26, je répondais à Pierre Pallier :
Note qu'il n'y a pas forcément de lien de cause à effet, car le codage desdits caractères était déjà défini bien avant 2009. Mais il est très possible que ton logiciel n'accepte aucun caractère Unicode en dehors du plan de base (de U+0000 à U+FFFF) alors que ces caractères sont dans le plan numéro 1 (de U+10000 à U+1FFFF).
Pour tester ma théorie, voici le tout premier caractère du plan 1, le caractère U+10000, rentré dans Unicode 4.0.0 en avril 2003 :
Salut,
Olivier Miakinen a écrit le 18/12/2018 à 01:37 :
Le 17/12/2018 23:26, je répondais à Pierre Pallier :
Note qu'il n'y a pas forcément de lien de cause à effet, car le codage
desdits caractères était déjà défini bien avant 2009. Mais il est très
possible que ton logiciel n'accepte aucun caractère Unicode en dehors
du plan de base (de U+0000 à U+FFFF) alors que ces caractères sont
dans le plan numéro 1 (de U+10000 à U+1FFFF).
Pour tester ma théorie, voici le tout premier caractère du plan 1,
le caractère U+10000, rentré dans Unicode 4.0.0 en avril 2003 :
Salut, Olivier Miakinen a écrit le 18/12/2018 à 01:37 :
Le 17/12/2018 23:26, je répondais à Pierre Pallier :
Note qu'il n'y a pas forcément de lien de cause à effet, car le codage desdits caractères était déjà défini bien avant 2009. Mais il est très possible que ton logiciel n'accepte aucun caractère Unicode en dehors du plan de base (de U+0000 à U+FFFF) alors que ces caractères sont dans le plan numéro 1 (de U+10000 à U+1FFFF).
Pour tester ma théorie, voici le tout premier caractère du plan 1, le caractère U+10000, rentré dans Unicode 4.0.0 en avril 2003 :
yamo'
Le Mon, 17 Dec 2018 10:35:06 +0100, yamo' a écrit :
Salut, ds a écrit le 16/12/2018 à 10:49 :
Le 16/12/2018 à 10:25, ds a écrit :
ceci est un test
et avec les accents: é è ç à ou caractères spéciaux: @ & $ £ €
La famille Mozilla gère bien les encodages :
Le Mon, 17 Dec 2018 10:35:06 +0100, yamo' a écrit :
Salut,
ds a écrit le 16/12/2018 à 10:49 :
Le 16/12/2018 à 10:25, ds a écrit :
ceci est un test
et avec les accents: é è ç à ou caractères spéciaux: @ & $ £ €
Ah ben ça alors... Ça s'affichait pourtant correctement avant l'envoi. ;-)
Attention à un truc, la police dans la fenêtre de composition peut être tout à fait différente de celle du corps de message une fois celui-ci envoyé... (onglet "Options" dans la fenêtre de composition) -- Pierre. Signature en grève.
Hello, DV a écrit dans <news:pvbi17$oh0$1@shakotay.alphanet.ch>
Ah ben ça alors... Ça s'affichait pourtant correctement avant l'envoi. ;-)
Attention à un truc, la police dans la fenêtre de composition peut être tout
à fait différente de celle du corps de message une fois celui-ci envoyé...
(onglet "Options" dans la fenêtre de composition)
--
Pierre.
Signature en grève.
Ah ben ça alors... Ça s'affichait pourtant correctement avant l'envoi. ;-)
Attention à un truc, la police dans la fenêtre de composition peut être tout à fait différente de celle du corps de message une fois celui-ci envoyé... (onglet "Options" dans la fenêtre de composition) -- Pierre. Signature en grève.
DV
DV a écrit ceci :
Effectivement, c'était le cas chez moi, je viens de rectifier. Cela dit, je teste un autre truc... ������������������������������������
J'ai essayé l'option "Autoriser les caractères 8 bit dans les emails". Vu de Thunderbird, ce n'est toujours pas ça. En revanche, Dialog lui-même affiche correctement mon message, comme la fois précédente. Drôle d'affaire... -- Denis
DV a écrit ceci :
Effectivement, c'était le cas chez moi, je viens de rectifier. Cela dit, je
teste un autre truc...
������������������������������������
J'ai essayé l'option "Autoriser les caractères 8 bit dans les emails".
Vu de Thunderbird, ce n'est toujours pas ça. En revanche, Dialog
lui-même affiche correctement mon message, comme la fois précédente.
Drôle d'affaire...
Effectivement, c'était le cas chez moi, je viens de rectifier. Cela dit, je teste un autre truc... ������������������������������������
J'ai essayé l'option "Autoriser les caractères 8 bit dans les emails". Vu de Thunderbird, ce n'est toujours pas ça. En revanche, Dialog lui-même affiche correctement mon message, comme la fois précédente. Drôle d'affaire... -- Denis
Olivier Miakinen
Voyons donc ce que cela donne. Les caractères étaient :
Voyons donc ce que cela donne. Les caractères étaient :
Olivier Miakinen
Le 19/12/2018 00:00, je répondais à DV :
������������������������������������
C'est-à-dire en UTF-8 : ED A0 BD ED B1 8C ED A0 BD ED B1 80 ED A0 BD ED B1 81 ED A0 BD ED B1 81 E2 80 8D ED A0 BD ED B7 A8 ED A0 BE ED B4 A0 Traduisons ça en points de code : D83D DC4C D83D DC40 D83D DC41 D83D DC41 200D D83D DDE8 D83E DD20
C'est bien un défaut de 40tude Dialog. Si jamais il existe un moyen de remonter des rapports de bug (et si ça n'a pas déjà été corrigé depuis octobre 2009), quiconque voudra le faire peut s'appuyer sur le RFC 3629. <cit. https://tools.ietf.org/html/rfc3629#page-5> The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which are reserved for use with the UTF-16 encoding form (as surrogate pairs) and do not directly represent characters. When encoding in UTF-8 from UTF-16 data, it is necessary to first decode the UTF-16 data to obtain character numbers, which are then encoded in UTF-8 as described above. </cit.> -- Olivier Miakinen
Le 19/12/2018 00:00, je répondais à DV :
������������������������������������
C'est-à-dire en UTF-8 :
ED A0 BD ED B1 8C ED A0 BD ED B1 80 ED A0 BD ED
B1 81 ED A0 BD ED B1 81 E2 80 8D ED A0 BD ED B7
A8 ED A0 BE ED B4 A0
Traduisons ça en points de code :
D83D DC4C D83D DC40 D83D DC41 D83D DC41 200D D83D DDE8
D83E DD20
C'est bien un défaut de 40tude Dialog. Si jamais il existe un moyen de
remonter des rapports de bug (et si ça n'a pas déjà été corrigé depuis
octobre 2009), quiconque voudra le faire peut s'appuyer sur le RFC 3629.
<cit. https://tools.ietf.org/html/rfc3629#page-5>
The definition of UTF-8 prohibits encoding character numbers between
U+D800 and U+DFFF, which are reserved for use with the UTF-16
encoding form (as surrogate pairs) and do not directly represent
characters. When encoding in UTF-8 from UTF-16 data, it is necessary
to first decode the UTF-16 data to obtain character numbers, which
are then encoded in UTF-8 as described above.
</cit.>
C'est-à-dire en UTF-8 : ED A0 BD ED B1 8C ED A0 BD ED B1 80 ED A0 BD ED B1 81 ED A0 BD ED B1 81 E2 80 8D ED A0 BD ED B7 A8 ED A0 BE ED B4 A0 Traduisons ça en points de code : D83D DC4C D83D DC40 D83D DC41 D83D DC41 200D D83D DDE8 D83E DD20
C'est bien un défaut de 40tude Dialog. Si jamais il existe un moyen de remonter des rapports de bug (et si ça n'a pas déjà été corrigé depuis octobre 2009), quiconque voudra le faire peut s'appuyer sur le RFC 3629. <cit. https://tools.ietf.org/html/rfc3629#page-5> The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which are reserved for use with the UTF-16 encoding form (as surrogate pairs) and do not directly represent characters. When encoding in UTF-8 from UTF-16 data, it is necessary to first decode the UTF-16 data to obtain character numbers, which are then encoded in UTF-8 as described above. </cit.> -- Olivier Miakinen
yamo'
Salut, Copie et FU2 fr.comp.usenet.lecteurs-de-news. Olivier Miakinen a écrit le 19/12/2018 à 00:09 sur fr.test :
Le 19/12/2018 00:00, je répondais à DV :
������������������������������������
C'est-à-dire en UTF-8 : ED A0 BD ED B1 8C ED A0 BD ED B1 80 ED A0 BD ED B1 81 ED A0 BD ED B1 81 E2 80 8D ED A0 BD ED B7 A8 ED A0 BE ED B4 A0 Traduisons ça en points de code : D83D DC4C D83D DC40 D83D DC41 D83D DC41 200D D83D DDE8 D83E DD20
C'est bien un défaut de 40tude Dialog. Si jamais il existe un moyen de remonter des rapports de bug (et si ça n'a pas déjà été corrigé depuis octobre 2009), quiconque voudra le faire peut s'appuyer sur le RFC 3629. <cit. https://tools.ietf.org/html/rfc3629#page-5> The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which are reserved for use with the UTF-16 encoding form (as surrogate pairs) and do not directly represent characters. When encoding in UTF-8 from UTF-16 data, it is necessary to first decode the UTF-16 data to obtain character numbers, which are then encoded in UTF-8 as described above. </cit.>
Il n'a plus l'air développé depuis un bail et il faut remonter loin dans les archives pour échapper aux erreurs 404 : <http://web.archive.org/web/20110929211448/http://40tude.com/dialog/contact.htm> <http://www.cj-web.de/40tude-dialog-faq/> Saurais-tu, si tu penses que ça peut être utile, expliciter ce problème en anglais ou en allemand sur un de ces groupes? news.software.readers de.comm.software.40tude-dialog Le test en question est :
Salut,
Copie et FU2 fr.comp.usenet.lecteurs-de-news.
Olivier Miakinen a écrit le 19/12/2018 à 00:09 sur fr.test :
Le 19/12/2018 00:00, je répondais à DV :
������������������������������������
C'est-à-dire en UTF-8 :
ED A0 BD ED B1 8C ED A0 BD ED B1 80 ED A0 BD ED
B1 81 ED A0 BD ED B1 81 E2 80 8D ED A0 BD ED B7
A8 ED A0 BE ED B4 A0
Traduisons ça en points de code :
D83D DC4C D83D DC40 D83D DC41 D83D DC41 200D D83D DDE8
D83E DD20
C'est bien un défaut de 40tude Dialog. Si jamais il existe un moyen de
remonter des rapports de bug (et si ça n'a pas déjà été corrigé depuis
octobre 2009), quiconque voudra le faire peut s'appuyer sur le RFC 3629.
<cit. https://tools.ietf.org/html/rfc3629#page-5>
The definition of UTF-8 prohibits encoding character numbers between
U+D800 and U+DFFF, which are reserved for use with the UTF-16
encoding form (as surrogate pairs) and do not directly represent
characters. When encoding in UTF-8 from UTF-16 data, it is necessary
to first decode the UTF-16 data to obtain character numbers, which
are then encoded in UTF-8 as described above.
</cit.>
Il n'a plus l'air développé depuis un bail et il faut remonter loin dans
les archives pour échapper aux erreurs 404 :
Salut, Copie et FU2 fr.comp.usenet.lecteurs-de-news. Olivier Miakinen a écrit le 19/12/2018 à 00:09 sur fr.test :
Le 19/12/2018 00:00, je répondais à DV :
������������������������������������
C'est-à-dire en UTF-8 : ED A0 BD ED B1 8C ED A0 BD ED B1 80 ED A0 BD ED B1 81 ED A0 BD ED B1 81 E2 80 8D ED A0 BD ED B7 A8 ED A0 BE ED B4 A0 Traduisons ça en points de code : D83D DC4C D83D DC40 D83D DC41 D83D DC41 200D D83D DDE8 D83E DD20
C'est bien un défaut de 40tude Dialog. Si jamais il existe un moyen de remonter des rapports de bug (et si ça n'a pas déjà été corrigé depuis octobre 2009), quiconque voudra le faire peut s'appuyer sur le RFC 3629. <cit. https://tools.ietf.org/html/rfc3629#page-5> The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which are reserved for use with the UTF-16 encoding form (as surrogate pairs) and do not directly represent characters. When encoding in UTF-8 from UTF-16 data, it is necessary to first decode the UTF-16 data to obtain character numbers, which are then encoded in UTF-8 as described above. </cit.>
Il n'a plus l'air développé depuis un bail et il faut remonter loin dans les archives pour échapper aux erreurs 404 : <http://web.archive.org/web/20110929211448/http://40tude.com/dialog/contact.htm> <http://www.cj-web.de/40tude-dialog-faq/> Saurais-tu, si tu penses que ça peut être utile, expliciter ce problème en anglais ou en allemand sur un de ces groupes? news.software.readers de.comm.software.40tude-dialog Le test en question est :
