Le 20/12/2007 22:56, regis a écrit :
>>
>>>oh ma joye c'est son lecteur qui supporte pas les accents pas lui ;-)
>>
>> Oui, mais le lecteur ne les efface pas, il fait de son mieux de les
>> traduire, genre ^$*%*
>
> non, c'est le protocole nntp qui les interdit.

Si je puis me permettre, ce n'est pas le protocole NNTP [RFC977] qui les
interdit (sinon il serait tout aussi interdit d'avoir des caractères 8
bits non encodés dans le corps des articles) mais plus probablement le
format Usenet [RFC850/RFC1036]. J'ai la flemme de vérifier alors je fais
une diapublication avec suivi sur fr.usenet.8bits.

Olivier Miakinen wrote:
> Le 20/12/2007 22:56, regis a écrit :
>>>> oh ma joye c'est son lecteur qui supporte pas les accents pas lui ;-)
>>> Oui, mais le lecteur ne les efface pas, il fait de son mieux de les
>>> traduire, genre ^$*%*
>> non, c'est le protocole nntp qui les interdit.
>
> Si je puis me permettre, ce n'est pas le protocole NNTP [RFC977] qui les
> interdit (sinon il serait tout aussi interdit d'avoir des caractères 8
> bits non encodés dans le corps des articles) mais plus probablement le
> format Usenet [RFC850/RFC1036]. J'ai la flemme de vérifier alors je fais
> une diapublication avec suivi sur fr.usenet.8bits.

Tu as raison, je n'ai rien trouvé dans
RFC 977 (Network News Transfert Protocol) qui definit le
protocole de communication pour l'obtention des articles.

RFC 850 et 1036 (Standard for Interchange of USENET Messages)
ne semblent rien contenir à ce propos directement mais
précisent que RFC 822 (Standard for the format of
Arpa Internet Messages) doit etre respecté,
tout message de news devant etre un message de mail correct.
Dans RFC 822, on trouve:

3.1. GENERAL DESCRIPTION

A message consists of header fields and, optionally, a body.
The body is simply a sequence of lines containing ASCII charac-
ters. It is separated from the headers by a null line (i.e., a
line with nothing preceding the CRLF).

3.1.2. STRUCTURE OF HEADER FIELDS

Once a field has been unfolded, it may be viewed as being com-
posed of a field-name followed by a colon (":"), followed by a
field-body, and terminated by a carriage-return/line-feed.
The field-name must be composed of printable ASCII characters
(i.e., characters that have values between 33. and 126.,
decimal, except colon). The field-body may be composed of any
ASCII characters, except CR or LF. (While CR and/or LF may be
present in the actual text, they are removed by the action of
unfolding the field.)

Donc, si on en croit RFC 822, c'est carré: tout est ascii,
corps et entete.

Après, il y a RFC 2045-2047 MIME (Multipurpose Internet Mail Extensions)
qui tente d'etendre RFC 822 aux jeux de caracteres non ascii
dans les corps et les entetes.

Abstract

STD 11, RFC 822, defines a message representation protocol specifying
considerable detail about US-ASCII message headers, and leaves the
message content, or message body, as flat US-ASCII text. This set of
documents, collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to allow for

(1) textual message bodies in character sets other than
US-ASCII,

(2) an extensible set of different formats for non-textual
message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other than
US-ASCII.

Je retourne demain matin en Normandie, et je n'aurais pas de connexion.
Donc, je ne pourrais poursuivre le sujet (jusqu'au 3 Janvier...)

--
regis

Le 21/12/2007 00:53, regis a écrit :
>
> Je retourne demain matin en Normandie, et je n'aurais pas de connexion.
> Donc, je ne pourrais poursuivre le sujet (jusqu'au 3 Janvier...)

Je crois que tu en as parfaitement fait le tour. Les RFC 850 et 1036 se
réclament du RFC 822 pour le format des champs d'entête, donc ASCII
seul, puis les RFC MIME sont venus étendre la signification des carac-
tères ASCII dans les champs d'entête, mais seulement pour le courriel.

Quant à ton problème particulier, je me demande si tu n'utiliserais pas
un logiciel en avance sur les autres, plutôt qu'en retard, en ce qu'il
s'attend à trouver éventuellement du 8 bits dans les entêtes mais
seulement si c'est de l'UTF-8. Du coup, le 8 bits que l'on rencontre
souvent sur usenet-fr, supposément du Latin-1, serait considéré par ton
logiciel comme trop nul pour être traité autrement que par le mépris (et
donc supprimé).

Olivier Miakinen wrote:
> Le 21/12/2007 00:53, regis a écrit :
>> Je retourne demain matin en Normandie, et je n'aurais pas de connexion.
>> Donc, je ne pourrais poursuivre le sujet (jusqu'au 3 Janvier...)
>
> Je crois que tu en as parfaitement fait le tour. Les RFC 850 et 1036 se
> réclament du RFC 822 pour le format des champs d'entête, donc ASCII
> seul, puis les RFC MIME sont venus étendre la signification des carac-
> tères ASCII dans les champs d'entête, mais seulement pour le courriel.
>
> Quant à ton problème particulier, je me demande si tu n'utiliserais pas
> un logiciel en avance sur les autres, plutôt qu'en retard, en ce qu'il
> s'attend à trouver éventuellement du 8 bits dans les entêtes mais
> seulement si c'est de l'UTF-8. Du coup, le 8 bits que l'on rencontre
> souvent sur usenet-fr, supposément du Latin-1, serait considéré par ton
> logiciel comme trop nul pour être traité autrement que par le mépris (et
> donc supprimé).

oui et non:
mozilla/seamonkey affiche correctement le message à l'arrivée.
c'est seulement lorsque je fait Reply qu'il génère un
"Re: " + (rien) dans l'éditeur.

De plus, si l'auteur a choisit un pseudo contenant un
caractère 8-bit comme Phénix l'a fait récemment,
le reply génère "Phix wrote:", en mangeant le "én" de "Phénix",
probablement parce que la séquence d'octets est interprétée
comme invalide en utf-8. En effet:

(é, n) en latin-1= (E9, 6E) en hexa= (11101001, 01101110) en binaire,
or les sequences utf-8 légales (hors extensions à venir) sont:

-le singleton (0xxxxxxx): ascii
-la paire (110xxxxx, 10xxxxxx): langues latines
-le triplet (1110xxxx, 10xxxxxx, 10xxxxxx): langues asiatiques...

donc à la vue du 1er octet (é) 11101001, deux autres octets
de forme 10xxxxxx sont attendus, mais (n) 01101110 arrive à la place,
et les 2 sont dégagés.

--
regis

En news:476b0629***neottia.net, Olivier Miakinen va escriure:
> Le 21/12/2007 00:53, regis a écrit
.... dans news:476b0055$0$10227$426a74cc***news.free.fr,

> Je crois que tu en as parfaitement fait le tour. Les RFC 850 et 1036
> se réclament du RFC 822 pour le format des champs d'entête, donc ASCII
> seul, puis les RFC MIME sont venus étendre la signification des carac-
> tères ASCII dans les champs d'entête, mais seulement pour le courriel.

Mmmm. D'accord sauf sur le tout dernier point.

A priori MIME pourrait s'appliquer à Usenet sans autre forme de procès; mais
la pratique Usenet s'est orienté vers une autre solution, savoir le 8bit par
défaut.
Au niveau de RFC2045 (contenu du message) il n'y a pas de différence
notable.

Par contre, au niveau des entêtes, il y a en a une grande, qui est que MIME
(RFC2047) demande un encodage tarabiscoté des entêtes (avec les
=?charset?B/Q), tandis que la pratique prépondérante sur Usenet à la même
époque (95-96) était d'utiliser du 8 bit pur idem que pour le texte.

Avantage de la solution MIME, il est possible de lire un sujet sans devoir
faire des devinettes sur le charset utilisé.
Avantage de la solution Usenet, c'est plus léger, un argument de poids à
l'époque.

Résultat des courses, personne n'a voulu céder. Donc officiellement pour
Usenet il restait interdit de mettre le moindre accent dans les entêtes
(suivant en cela RFC822, alors que pour le texte du message on s'en
affranchissant allégrement), et les emberlifications MIME était mal vues.
Au fil du temps et sous la pression des clients (MUA servant à lire les
news), le seconde restriction a été levée, je ne pense plus qu'il y ait
encore les robots envoyant des messages incendiaires lorsqu'ils détectent un
QP dans un entête (d'ailleurs avec le spam, ces robots ne risquent pas de
trouver l'émetteur correct !)

Le problème est toujours le même : on voudrait bien (pour des raisons
d'efficacité) pouvoir mettre de l'UTF-8 (ou du Latin-1) pur dans les sujets,
mais cela reste tabou pour le mail (cf. message de Jean-Marc,
news:fkdovf$3e2$1***reader1.imaginet.fr)


> Quant à ton problème particulier, je me demande si tu n'utiliserais
> pas un logiciel en avance sur les autres, plutôt qu'en retard, en ce
> qu'il s'attend à trouver éventuellement du 8 bits dans les entêtes
> mais seulement si c'est de l'UTF-8. Du coup, le 8 bits que l'on
> rencontre souvent sur usenet-fr, supposément du Latin-1, serait
> considéré par ton logiciel comme trop nul pour être traité autrement
> que par le mépris (et donc supprimé).

Là est TOUT le problème de la migration VERS utf-8...


Antoine

regis wrote:
> mozilla/seamonkey affiche correctement le message à l'arrivée.
> c'est seulement lorsque je fait Reply qu'il génère un
> "Re: " + (rien) dans l'éditeur.

Utilisateur Linux, hein ? Bon, j'essaierais de regarder à nouveau ce bug
pendant les vacances :-)

> De plus, si l'auteur a choisit un pseudo contenant un
> caractère 8-bit comme Phénix l'a fait récemment,
> le reply génère "Phix wrote:", en mangeant le "én" de "Phénix",
> probablement parce que la séquence d'octets est interprétée
> comme invalide en utf-8.

Pas très surprenant, ce code est tellement merdique que quand on corrige
le problème pour un champ, il reste pas mal de boulot pour le faire pour
les autres champs.