Discussion:
utf-7 à utiliser ou pas ?
(trop ancien pour répondre)
Patrick Lamaizière
2005-01-02 21:38:28 UTC
Permalink
Bonjour,

Je me demandais si l'usage de l'utf-7 pour le courrier électronique et
les news est toujours d'actualité ; ou s'il est déprécié en faveur de
l'utf-8 ? Si oui pourquoi ?

Merci.
Antoine Leca
2005-01-03 09:45:12 UTC
Permalink
Post by Patrick Lamaizière
Je me demandais si l'usage de l'utf-7 pour le courrier électronique
et les news est toujours d'actualité ; ou s'il est déprécié en
faveur de l'utf-8 ? Si oui pourquoi ?
Pour les news, je ne sais pas (je crois que c'est une idée de OE4 de l'avoir
rameuté dans ce contexte-là, par analogie avec le mail; quand au pourquoi et
à l'intérêt de cette idée, cf. fr.usenet.* pour tout le bien que les gens
pensent en général de OE4 ;-)).

Pour le courrier électronique, je pense que l'argument original (passerelles
"7 bits" qui coupent systématiquement le 8e bit pour "éviter les
problèmes"), même s'il n'a pas la même validité qu'il y a quelques années,
reste d'actualité, comme nous pouvons nous en apercevoir de temps en temps.
Je crois que RFC2822 a confirmé cette règle, même si dans les faits tout le
monde utilise MIME et les sympathiques QP et Base64. Je crois bien que
l'avantage de la simplicité de programmation (au niveau des clients) de
UTF-8 l'emporte, quand bien même l'UTF-7 devrait être plus compact que de
l'UTF-8+QP pour du texte en alphabet latin.

Pour ce qui est de savoir si c'est toujours utilisé, j'ai mis en place il y
a peu un serveur avec un POST mailto. Et à l'autre bout, j'ai reçu (sans
l'avoir demandé expressement)... de l'UTF-7. M'est avis que les
programmeurs, peut-être moins pressés par les feux de la rampe, soit sont en
retard d'une génération et sont encore sur le même sentier que OE4 en 1997,
soit font les calculs complets et délivrent le message le plus compact (avis
perso).

Autrement dit, je pense que nous allons nous traîner ce boulet pendant
encore bien des années.


Antoine
Jean-Marc Desperrier
2005-01-03 11:02:27 UTC
Permalink
Pour le courrier électronique, je pense que l'argument original [...]
reste d'actualité, comme nous pouvons nous en apercevoir de temps en temps.
Je crois que RFC2822 a confirmé cette règle, même si dans les faits tout le
monde utilise MIME et les sympathiques QP et Base64. [...]
Tu me fais un peu peur, car je crains que certains personnes ne pensent
pouvoir interpréter ton message comme signifiant que UTF-7 est
raisonnable pour le courrier, alors que la bonne réponse est "surtout
pas, malheureux !".

UTF-7 est totalement déprécié. Quand on a tenté de l'utiliser, il est
devenu rapidement évident qu'il y avait des problèmes majeurs pour le
mail. C'est certainement un peu la faute d'encodeur qui ne font pas bien
ce qu'il faut, mais il reste justement que UTF-7 oblige à faire très
attention, et que le résultat pratique est des plantages. UTF-7 oblige à
encoder de nombreux caractère ASCII utilisé comme délimiteurs dans les
en-têtes mail, et génère lui même des caractères ressemblant à ces
délimiteurs. Le résultat est qu'un en-tête encodés UTF-7 passe très mal
dans un logiciel non "UTF-7 aware", et c'est un défaut rapidement
rédhibitoire.
Pource qui est de savoir si c'est toujours utilisé, j'ai mis en place
il y a peu un serveur avec un POST mailto. Et à l'autre bout, j'ai
reçu (sans l'avoir demandé expressement)... de l'UTF-7. M'est avis
que les programmeurs, peut-être moins pressés par les feux de la
rampe, soit sont en retard d'une génération et sont encore sur le
même sentier que OE4 en 1997, soit font les calculs complets et
délivrent le message le plus compact (avis perso).
Je ne vois pas très précisément à quoi tu fais référence. Le seul cas
dans lequel j'ai vu de l'UTF-7 encore récemment est un certain serveur
de mail (je crois que c'est une déclinaison d'Exchange) qui a tendance à
envoyer des accusés d'erreur en UTF-7. Ici, il n'y a aucun calcul, c'est
se configuration par défaut. Et la résultat est de la bouillie sur la
plupart des clients.
Autrement dit, je pense que nous allons nous traîner ce boulet pendant
encore bien des années.
Je ne suis pas convaincu qu'il soit nécessaire de faire grand chose pour
traiter UTF-7 sur les news/le mail. Son taux de survie aux transferts
n'est de toute façon pas supérieur à celui d'un piéton sur une bande
d'arrêt d'urgence d'autoroute.
Antoine Leca
2005-01-03 13:51:04 UTC
Permalink
Post by Jean-Marc Desperrier
Post by Antoine Leca
Pour le courrier électronique, je pense que l'argument original
[...] reste d'actualité, comme nous pouvons nous en apercevoir de
temps en temps. Je crois que RFC2822 a confirmé cette règle, même
si dans les faits tout le monde utilise MIME et les sympathiques
QP et Base64. [...]
Tu me fais un peu peur, car je crains que certains personnes ne
pensent pouvoir interpréter ton message comme signifiant que UTF-7
est raisonnable pour le courrier, alors que la bonne réponse est
"surtout pas, malheureux !".
UTF-7 est totalement déprécié.
Références ?

Ce n'est pas que je fasse partie de la S.P.R.M. (sté de prot. des RFC
malheureuses/maudites), mais le problème c'est que quand tu essayes de faire
valoir ce genre de point de vue vis-à-vis des éditeurs de logiciels « d'une
certaine taille », il faut venir avec des biscuits... Les programmeurs
OpenSource ou équivalent ne sont pas ceux qui posent problème ici, ce sont
« les autres ».
Post by Jean-Marc Desperrier
Quand on a tenté de l'utiliser, il est devenu rapidement évident
qu'il y avait des problèmes majeurs pour le mail. C'est
certainement un peu la faute d'encodeur qui ne font pas bien
ce qu'il faut, mais il reste justement que UTF-7 oblige à faire très
attention, et que le résultat pratique est des plantages.
Je pensais au contenu des messages, pas aux entêtes. Et quand j'écrivais
MIME, je pensais RFC 2045, pas 2047... C'est vrai que pour les entêtes (qui
est /probablement/ le sujet qui intéresse Patrick ;-)) il y a risque
/important/ de cassage de gueule :O).
Post by Jean-Marc Desperrier
Post by Antoine Leca
Pource qui est de savoir si c'est toujours utilisé, j'ai mis en
place il y a peu un serveur avec un POST mailto. Et à l'autre
bout, j'ai reçu (sans l'avoir demandé expressement)...
de l'UTF-7.
Je ne vois pas très précisément à quoi tu fais référence.
Désolé, je n'ai pas sous la main de messages correspondants pour te dire
exactement qui est le fautif. La seule chose que je sais, c'est que le
serveur HTTP dit être IIS/5.0 (ce qui donne des idées).
De plus, les messages en question n'ont pas de UTF-7 dans les entêtes
(heureusement), seulement dans le contenu (et en plus, mal ou pas annoncé).
Post by Jean-Marc Desperrier
Le seul cas dans lequel j'ai vu de l'UTF-7 encore récemment
est un certain serveur de mail (je crois que c'est une
déclinaison d'Exchange) qui a tendance à envoyer des accusés
d'erreur en UTF-7.
Je confirme, ici aussi. Mais je ne m'en étais pas aperçu, preuve que cela ne
posait pas réellement de problème. J'ai aussi des messages de Kmail 1.5.3
(de 2003) en réponse à des courriers avec du contenu Unicode.


Antoine
Patrick Lamaizière
2005-01-03 15:09:27 UTC
Permalink
Post by Antoine Leca
Post by Jean-Marc Desperrier
UTF-7 est totalement déprécié.
Références ?
J'ai fouillé un peu le site d'Unicode ils ne sont pas très causant sur
l'utf-7. Par exemple rien là :
http://www.unicode.org/unicode/faq/utf_bom.html

Il y a un aussi un exemple de programme en C pour l'encodage mais il est
indiqué comme étant obsolète. Je pense que l'utf-7 est déprécié parce
qu'il ne supporte que les caractères sur 16 bits (le BMP).

Peut-être que le seul usage légitime qui reste c'est l'utf-7 modifié
pour l'IMAP ?
Post by Antoine Leca
Je pensais au contenu des messages, pas aux entêtes. Et quand
j'écrivais MIME, je pensais RFC 2045, pas 2047... C'est vrai que pour
les entêtes (qui est /probablement/ le sujet qui intéresse Patrick
;-)) il y a risque /important/ de cassage de gueule :O).
Les deux m'intéressent, entêtes et corps. Mais je ne vais implémenter
que le décodage s'il n'y a pas d'intérêt à l'encoder. En fait c'est
juste parce que 40titude Dialog a la manie d'envoyer de l'utf-7.

Merci.
Laurent Wacrenier
2005-01-03 15:19:35 UTC
Permalink
Post by Patrick Lamaizière
Il y a un aussi un exemple de programme en C pour l'encodage mais il est
indiqué comme étant obsolète. Je pense que l'utf-7 est déprécié parce
qu'il ne supporte que les caractères sur 16 bits (le BMP).
UTF-7 supporte le codage de tout unicode, il me semble.

Il a toutefois des problèmes sur utf-8. Notement :
- il ne résiste pas à la perte ou l'ajout d'un octet
- un caractère peut être codé de différentes manières,
ce qui fait qu'on ne peut pas faire de recherche dans le texte
sans utiliser un encodage intermédiaire.
Patrick Lamaizière
2005-01-03 15:38:32 UTC
Permalink
Post by Laurent Wacrenier
UTF-7 supporte le codage de tout unicode, il me semble.
Ce n'est pas ce qui est dit dans la RFC2152 (j'avais d'abord regardé la
RFC1642 qui est rendue obsolète par celle ci):

«
UTF-7 Definition
A UTF-7 stream represents 16-bit Unicode characters using 7-bit US-ASCII
octets as follows:
»
et plus loin :
«ISO 10646 characters outside the range addressable via surrogate pairs
cannot be encoded.»

C'est quoi les "surrogate pairs" ? Bon la RFC n'étant pas super claire
j'ai peut-être mal compris. Pas étonnant qu'il y ait des bugs sur les
implémentations.
Laurent Wacrenier
2005-01-03 16:18:16 UTC
Permalink
Post by Patrick Lamaizière
Post by Laurent Wacrenier
UTF-7 supporte le codage de tout unicode, il me semble.
Ce n'est pas ce qui est dit dans la RFC2152 (j'avais d'abord regardé la
Heu si, c'est dit implicitement.
Post by Patrick Lamaizière
«
UTF-7 Definition
A UTF-7 stream represents 16-bit Unicode characters using 7-bit US-ASCII
»
«ISO 10646 characters outside the range addressable via surrogate pairs
cannot be encoded.»
C'est quoi les "surrogate pairs" ?
Une bidouille pour élargir l'espace d'encodage des codage en 16 bits
de 0x010000 à 0x10FFFF en utilisant deux mots de 16 bits.

exemple sur http://zsigri.tripod.com/fontboard/cjk/surrog.html

Or tout l'espace alloué se trouve avant 0x10FFFF, donc tout unicode
est représenté.
Post by Patrick Lamaizière
Bon la RFC n'étant pas super claire
j'ai peut-être mal compris. Pas étonnant qu'il y ait des bugs sur les
implémentations.
Cette RFC ne défini pas UTF-7, elle le décrit.
En gros ça consiste à coder de l'UTF-16 en base64, mixable avec de
l'ASCII
Patrick Lamaizière
2005-01-03 18:32:20 UTC
Permalink
Post by Laurent Wacrenier
Post by Patrick Lamaizière
C'est quoi les "surrogate pairs" ?
Une bidouille pour élargir l'espace d'encodage des codage en 16 bits
de 0x010000 à 0x10FFFF en utilisant deux mots de 16 bits.
Ah d'accord, j'avais pas vu ça. Merci.

...
Post by Laurent Wacrenier
Cette RFC ne défini pas UTF-7, elle le décrit.
En gros ça consiste à coder de l'UTF-16 en base64, mixable avec de
l'ASCII
Où trouve-t-on la définition alors ?
J'ai du mal à trouver des exemples de codes pour le décodage aussi (à
part un truc pour emacs en Lisp).
Antoine Leca
2005-01-03 19:03:42 UTC
Permalink
Post by Patrick Lamaizière
J'ai du mal à trouver des exemples de codes pour le décodage aussi
(à part un truc pour emacs en Lisp).
Normalement, cela devrait aller tout seul: tu découpes le base64 (suivant ce
que dit la RFC) en unités de 16 bits, et tu obtiens un flux UTF-16 (sans
exception pour la zone U+D800-U+DFFF). Si tu veux de l'UTF-8, tu prends
l'algorithme UTF-16 vers UTF-8.

Les vrais soucis commencent quand tu as une erreur de synchronisation, un -
qui arrive quand on l'attend pas ou un caractère hors du jeu de codage. Et
là, au niveau récupération des erreurs, on est pas dans le cas d'un
protocole éprouvé...


Antoine
Laurent Wacrenier
2005-01-04 09:52:36 UTC
Permalink
Post by Patrick Lamaizière
Où trouve-t-on la définition alors ?
J'ai du mal à trouver des exemples de codes pour le décodage aussi (à
part un truc pour emacs en Lisp).
Tu veux le recoder à partir de rien ?
Sinon, le mieux est d'utiliser iconv(3).

Il y a des réponses sur tout ça dans http://czyborra.com/utf/ (Unicode
Transformation Formats) Comme le site a l'air mort, je reproduis la
partie concernant utf-7 :

* UTF-7

All of the above UTFs produce 8bit bytes that are not in ASCII and
that will get stripped on any terminal that is still set to character
size 7 or any mail gateway that ensures RFC 822's rule that mail
messages have to be in ASCII. To solve that problem, David Goldsmith
and Mark Davis invented a mail-safe transformation format UTF-7. It
was first published in RFC 1642 in 1994, prominently included as
Appendix A.1 in The Unicode Standard, Version 2.0, and now updated in
RFC 2152. It makes partial use of the MIME base64 encoding and goes
roughly like this:

char base64[]=
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";

putwchar(c)
{
if (c == '+') {
putchar('+');
putchar('-');
}
else if (c < 0x80) {
putchar(c);
}
else if (c < 0x10000) {
putchar('+');
putchar(base64[c>>10&63]);
putchar(base64[c>>4&63]);
putchar(base64[c<<2&63]);
putchar('-');
}
else if (c < 0x110000) {
c = 0xD7C0DC00 + (c >> 10 << 16 | c & 0x3FF);
putchar('+');
putchar(base64[c>>26&63]);
putchar(base64[c>>20&63]);
putchar(base64[c>>14&63]);
putchar(base64[c>>8&63]);
putchar(base64[c>>2&63]);
putchar(base64[c<<4&63]);
putchar('-');
}
}

Except for the '+' escaping, ASCII text remains unchanged with
UTF-7. In some situations, the trailing '-' is optional. And by
joining a whole stretch of non-ASCII characters into a larger base64
block you can encode an average of 3 Unicode characters in 8 bytes
which is much better than the 9 bytes "=E5=A4=A9" for 1 CJK ideograph
in quoted-printable UTF-8.

However, base64 or 8bit SCSU can achieve much better compression, and
UTF-7 is a bad general-purpose processing format: its flickering
base64 grouping is awkward to program, most ASCII values can stand for
almost any character and there are many different possible UTF-7
encodings of the same character so that UTF-7 is practically
unsearchable without conversion.
Patrick Lamaizière
2005-01-04 19:03:34 UTC
Permalink
Post by Laurent Wacrenier
Post by Patrick Lamaizière
J'ai du mal à trouver des exemples de codes pour le décodage aussi (à
part un truc pour emacs en Lisp).
Tu veux le recoder à partir de rien ?
Oui, ça doit pas aller très loin. Surtout avec l'exemple fourni merci.
Post by Laurent Wacrenier
Sinon, le mieux est d'utiliser iconv(3).
C'est tentant, je regarderais ça de plus près.
Xavier Roche
2005-01-04 19:45:32 UTC
Permalink
+ non facilement sécable (avec UTF-8 on sait toujours où on en est, soit
en ascii, soit en début de séquence, soit en inter-séquence)
+ décodage malaisé (base64)
+ expansion importante dès que l'on sort de ascii..

et bien sûr la restriction au 16-bit (sauf à jouer avec les surrogates,
miam miam) alors que utf-8 peut coder potentiellement très loin (il
reste de la place pour étendre au delà de 32-bit, soyons fous)
Antoine Leca
2005-01-05 11:05:43 UTC
Permalink
Post by Xavier Roche
et bien sûr la restriction au 16-bit (sauf à jouer avec les
surrogates, miam miam) alors que utf-8 peut coder potentiellement
très loin (il reste de la place pour étendre au delà de 32-bit,
soyons fous)
Peux-tu préciser ta pensée ?

UTF-7 a exactement la même portée que UTF-16, ni plus, ni moins (selon la
RFC 2152).

De son côté UCS-4 ou UTF-8 (l'original, 2044/2279) pouvait aller jusqu'à
_31_ bits, mais aujourd'hui (RFC 3629, ISO/CÉI 10646) la portée comme celle
de UTF-32 est réduite au même ensemble que UTF-16.

D'un autre côté, concernant les supplétifs (surrogates), cela dépend de ton
flux de conversion. Si tu utilises UTF-16 en interne, UTF-7 (ou CESU-8) sont
plus "faciles", il n'y a rien à faire ou presque; par contre UTF-8 (ou
UTF-32) te demande de faire explicitement la conversion des plans supérieurs
(>0xFFFF) en paires de supplétifs ou vice-versa. Inversement, si tu utilises
UTF-8 ou UTF-32 en interne, les rôles sont inversés, UTF-7 est aussi ch**t
que UTF-16 sur ce point.


Antoine
Xavier Roche
2005-01-05 11:14:49 UTC
Permalink
Post by Antoine Leca
Post by Xavier Roche
et bien sûr la restriction au 16-bit (sauf à jouer avec les
UTF-7 a exactement la même portée que UTF-16, ni plus, ni moins (selon la
RFC 2152).
Je comparais avec UTF-8.
Post by Antoine Leca
De son côté UCS-4 ou UTF-8 (l'original, 2044/2279) pouvait aller jusqu'à
_31_ bits, mais aujourd'hui (RFC 3629, ISO/CÉI 10646) la portée comme celle
de UTF-32 est réduite au même ensemble que UTF-16.
UTF-8 peut être encore étendu (les derniers codes de démarrage de
séquence n'ont pas été utilisés: F5..FF)
Post by Antoine Leca
D'un autre côté, concernant les supplétifs (surrogates), cela dépend de ton
flux de conversion. Si tu utilises UTF-16 en interne, UTF-7 (ou CESU-8) sont
plus "faciles"
Bof. Coder en base64 au lieu de faire la conversion UTF-8 ? Je préfère
la conversion UTF-8, très largement.
Antoine Leca
2005-01-05 16:10:51 UTC
Permalink
Post by Xavier Roche
Post by Antoine Leca
Post by Xavier Roche
utf-8 peut coder potentiellement très loin (il
reste de la place pour étendre au delà de 32-bit, soyons fous)
UTF-8 peut être encore étendu (les derniers codes de démarrage de
séquence n'ont pas été utilisés: F5..FF)
F5 à FD, si (lis RFC 2044 ou 2279 ou l'original de l'annexe 4, celle de
10646:2000 si tu n'as jamais fait).

Comment définis-tu plus de 31 bits en UTF-8 ?

Utiliser FF et FE serait ÀMHA une mauvaise idée, on aurait alors du mal
(sans information extérieure)à séparer un flux UTF-8 d'un flux UTF-16
annoncé avec BOM, comme on peut le faire actuellement.
Post by Xavier Roche
Post by Antoine Leca
D'un autre côté, concernant les supplétifs (surrogates), cela
dépend de ton flux de conversion. Si tu utilises UTF-16 en
interne, UTF-7 (ou CESU-8) sont plus "faciles"
Bof. Coder en base64 au lieu de faire la conversion UTF-8 ? Je
préfère la conversion UTF-8, très largement.
C'est vrai que les deux cas sont très différents, donc difficiles à
comparer.

Pour décoder UTF-7 c'est trois ou quatre recherches dans une table à 64 (en
fait on utilise 82, de '-' à 'z') entrées avec dix valeurs (correspondant
aux 3 ou 4 "lettres" base64 pour chacune des 3 "positions" posibles), c'est
tout. Rien d'autre à faire pour gérer les supplétifs etc., tu as juste à
gérer le cas de sortie de décodeur quand tu reçois un caractère hors
"alphabet" (y compris les cas d'erreurs quand il reste des bits décodés).
Seule autre chose, vérifier qu'un petit malin ne t'a pas envoyé codé un
caractère de la série A-Za-z0-9'(),-./:?

Décoder UTF-8 en UTF-16, c'est un grand entremelas de gestion des différents
cas d'erreur, et la pratique montre que c'est un nid à bogues (remember
CodeRed), surtout avec les séquences invalides.

Je pensais surtout au décodage. Encoder UTF-7 est plus complexe parce qu'il
faut déterminer quand encoder et quand ne pas encoder (et c'est
potentiellement contextuel). Sinon quand c'est fait, c'est juste aussi
compliqué que UTF-8: décalage, masquage et encodage, rien de sorcier.


Tout ceci n'enlève rien aux défauts majeurs de UTF-7, sensibilité plus
grande à la perte d'un octet et "chiffrage". Ni bien sûr que quand tu es sur
une architecture UTF-8 ou UTF-32, c'est double boulot (le codage comme
ci-dessus, plus les em**des du codage/décodage des supplétifs).


Antoine

Jean-Marc Desperrier
2005-01-03 16:28:41 UTC
Permalink
Post by Antoine Leca
Post by Jean-Marc Desperrier
UTF-7 est totalement déprécié.
Références ?
http://www.unicode.org/unicode/reports/tr17/
"The Unicode Standard has seven character encoding schemes: UTF-8,
UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, and UTF-32LE."

http://www.awprofessional.com/articles/article.asp?p=30893&seqNum=5
"In addition, some allied specifications aren't officially part of the
Unicode standard:
[...]
# UTF-7 is a mostly obsolete character encoding scheme for use with
7-bit Internet standards that maps UTF-16 code units to sequences of
7-bit values."

C'est le stade de dépréciation où l'on ne cite plus le nom :-)

Cela dit il reste effectivement, et malheureusement, l'usage à travers IMAP.
Antoine Leca
2005-01-03 18:57:04 UTC
Permalink
Post by Jean-Marc Desperrier
Post by Antoine Leca
Post by Jean-Marc Desperrier
UTF-7 est totalement déprécié.
Références ?
http://www.unicode.org/unicode/reports/tr17/
"The Unicode Standard has seven character encoding schemes: UTF-8,
UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, and UTF-32LE."
Mmmm.
Tu m'excuseras de ne pas considérer "The Unicode Standard" comme la seule et
unique référence de ce qui circule sur Internet. Parce qu'à cette aune-là,
ISO/CÉI 8859-1:1998 aussi, c'est déprécié... Et pourtant, c'est ce que je
vais envoyer comme flux d'octets quand je vais appuyer sur Enviar, et c'est
parmi ce qu'il y a de mieux pour toutes les passerelles entre nous deux !
;-)


UTF-7 n'est pas à ma connaissance une émanation directe de Unicode (pas plus
que ne l'étaient UTF-1 ou UTF-2 si j'ai bien compris), même si le supporter
nº1 en est Mark Davis (actuel directeur du consortium et un des architectes
originaux).

Je sais bien que dans le monde des RFC, officiellement, un truc qui est
depuis 7 ans au niveau "informatif" n'a pas grande importance. Mais de fait,
tant qu'on ne trouve pas une RFC qui dit "surtout ne pas faire cela" (Best
practice), tu as toujours le "risque" d'avoir un vendeur qui te sorte une
solution --voire pire une spécification d'interface-- utilisant ce schéma,
et tu es marron (je ne me rappelais plus du cas IMAP, mais on dirait bien
que ce soit effectivement le cas).


En fait, pour en revenir au problème de Patrick et en tenant compte du
contexte (supposé) où il se place (Patrick écrit un outil de conversion au
vol, cf. http://www.lamaiziere.net/), il est peut-être sain de dégommer dès
que possible (en sortie de domaine) les utilisations de UTF-7 et de les
remplacer par de l'UTF-8 (à encoder en QP ou Base64, délicat problème) ou
autre chose.

En passant, je note que dans les exemples de UTF-7 que j'ai trouvé, il est
annoncé "unicode-1-1-utf-7", et non pas "utf-7" comme il serait de bon aloi.
Preuve que l'on n'est pas en présence de clients de dernière génération,
puisqu'ils ont loupé la mise à jour... qui date de 1998.


Antoine
Laurent Wacrenier
2005-01-04 10:01:50 UTC
Permalink
Post by Antoine Leca
En passant, je note que dans les exemples de UTF-7 que j'ai trouvé, il est
annoncé "unicode-1-1-utf-7", et non pas "utf-7" comme il serait de bon aloi.
Preuve que l'on n'est pas en présence de clients de dernière génération,
puisqu'ils ont loupé la mise à jour... qui date de 1998.
UNICODE-1-1-UTF-7 est l'identifiant original de l'encodage (RFC 1642,
juillet 1994, experimental).
Xavier Roche
2005-01-04 19:36:42 UTC
Permalink
Post by Jean-Marc Desperrier
Cela dit il reste effectivement, et malheureusement, l'usage à travers IMAP.
Nan, IMAP c'est un UTF-7 _modifié_ (UTF-7 était pas encore assez naze),
et utilisé uniquement en interne pour coder les noms des répertoires,
etc. si je dis pas de conneries. Les body sont balancés en 8bit
directement après déclaration de la taille ({size}<data>)
Loading...