Sujet : Re: Champs d'en-tête personnalisés
De : om+news (at) *nospam* miakinen.net (Olivier Miakinen)
Groupes : fr.comp.usenet.lecteurs-de-newsDate : 17. Nov 2021, 12:22:27
Autres entêtes
Organisation : There's no cabale
Message-ID : <sn2olj$1grn$1@cabale.usenet-fr.net>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4
Le 17/11/2021 09:25, M.V. a écrit :
À l'exception de quelques entêtes que le serveur va refuser, les entêtes
sont par nature totalement libres.
>
Tout à fait.
Mais dès qu'il y a notamment des caractères accentués, le résultat est
désastreux…
Je vois mal comment il pourrait en être autrement, vu que les champs d'entêtes
sont toujours censés être en US-ASCII seulement [1], et que l'encodage MIME
ne peut s'appliquer que lorsque le champ est normalisé pour savoir s'il
contient des parties 'text', 'comment' ou 'phrase' [2]. Alors certes, on ne
sait pas comment sont codés tous les nouvelleurs, et certains pourraient
décider de décoder du MIME dans tous les champs d'entête inconnus, mais sauf
erreur de ma part ce n'est pas normalisé.
[1]<
https://datatracker.ietf.org/doc/html/rfc5536#section-2.2>
§
o The character set for header fields is US-ASCII. Where the use of
non-ASCII characters is required, they MUST be encoded using the
MIME mechanisms defined in [RFC2047] and [RFC2231].
§
[2]<
https://datatracker.ietf.org/doc/html/rfc2047#section-5>
§
(1) An 'encoded-word' may replace a 'text' token [...]
(2) An 'encoded-word' may appear within a 'comment' [...]
(3) As a replacement for a 'word' entity within a 'phrase', [...]
§
-- Olivier Miakinen