CSS, IE7 et background

À (at) Tue, 09 Feb 2010 17:17:56 +0100,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):

Ce qui est marrant, c'est que le fameux BOM utf-8 peut ne pas passer
ce test ! ;-)

Heu... Désolé, j'avais mal lu le test. Le BOM utf-8 le passe
heureusement bien.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

Eric Demeester wrote:

dans (in) fr.comp.infosystemes.www.auteurs, Olivier Miakinen
<om+news@miakinen.net> ecrivait (wrote) :
> Je te mets au défi de me trouver un seul texte ayant un sens dans

n'importe laquelle des langues du monde, encodé dans n'importe quel
charset autre qu'UTF-8, et dans lequel tous les caractères non-ASCII
s'enchaînent de telle sorte que l'on puisse croire à de l'UTF-8 :
[...]
Merci de ne pas prendre prétexte de problèmes avec UTF-16 pour justifier
un usage dans UTF-8. Le BOM *est* utile dans UTF-16, il ne l'est *pas*
dans UTF-8.

Je ne suis pas aussi pointu que toi concernant les jeux d'encodage, mais
après m'être renseigné un peu suite à ma mésaventure, j'en arrive à la
même conclusion.

Je ne suis pas sûr à 100%.

Thunderbird/Seamonkey Mail a une "feature" dans laquelle un en-tête
valide UTF-8 est décodé automatiquement en UTF-8 quoi qu'il soit marqué
par ailleurs, et il me semble qu'il s'est trouvé un ou deux cas sur des
groupes chinois où un en tête de message consitant uniquement en 2 ou 3
caractères chinois BIG-5 soit accidentellement de l'UTF-8 valide.

Malheureusement je ne suis pas convaincu d'avoir encore une référence à
un exemple précis de cela.

En y repensant, je crois que c'est un des gars de USEFOR qui avait fait
tourner une moulinette pour détecter l'usage d'UTF-8 dans des en-têtes
sur l'ensemble des groupes Usenet qui avait détecté ces cas là.

On 09/02/2010 16:59, Olivier Miakinen wrote:

Le BOM, m'avait-il dit, ne correspondait à aucun caractère
dans aucun charset ISO 8 bits dérivé de us-ascii.

C'est exact. Il y a trop peu d'emplacements dans les charsets 8 bits
pour en dépenser un avec un « zero-width no-break space ». De toute
manière il ne pourrait en aucun cas servir de « byte order mark »
puisque renverser l'ordre d'un seul octet donne le même octet, au
contraire du BOM en UTF-16 et UTF-32, où le renversement des 2 ou 4
octets donne une valeur qui est garantie être à jamais invalide.

Je ne suis pas sûr de t'avoir compris : dans les charsets ISO 8 bits, ce
sont les zones de 0x80 à 0x9F qui sont réservées, or les octets utilisés
dans les BOM pour UTF-32, UTF-16 ou UTF-8 sont tous hors de cette zone,
et correspondent donc bien à des caractères valides dans les charsets
ISO 8 bits.

Je pense que tu voulais dire que le caractère utilisé pour le BOM
(U+FEFF) n'était présent dans aucun des charsets ISO 8 bits ?

Si c'était la première solution, la suite d'octets débutant le fichier
permettrait d'être sûr que le codage n'est aucun des charsets ISO 8
bits. Or on peut encore avoir le doute comme je le disais dans mon
précédent message (en UTF-8 le BOM vaut EF BB BF soit la suite de
caractères "" en Latin-1 par exemple).

L'analyse du contenu d'un fichier dans un charset autre que l'UTF-8,
pour en déduire la langue et le charset, *est* un problème difficile.

Mais l'analyse d'un fichier dans un charset quelconque, simplement pour
en déduire si oui ou non c'est de l'UTF-8 (et ce, quelle que soit la
langue utilisée) est une question *triviale*. Un simple iconv de UTF-8
vers UTF-16, par exemple, te donne immédiatement la réponse.

Si l'on n'a pas de l'UTF-8, je suppose que iConv va tomber sur des
séquences d'octets invalides et qu'il va le signaler ?

index = 0
tant que index< longueur de la chaîne
{
si caractère(index) dans [0..x7f]
// ok
sinon, si caractère(index) dans [xc0..xdf]
index = index+1
si caractère(index) pas dans [x80..xbf] ERREUR
sinon, si caractère(index) dans [xe0..xef]
index = index+1
si caractère(index) pas dans [x80..xbf] ERREUR
index = index+1
si caractère(index) pas dans [x80..xbf] ERREUR
sinon, si caractère(index) dans [xf0..xf7]
index = index+1
si caractère(index) pas dans [x80..xbf] ERREUR
index = index+1
si caractère(index) pas dans [x80..xbf] ERREUR
index = index+1
si caractère(index) pas dans [x80..xbf] ERREUR
sinon
ERREUR
index = index + 1
si index> longueur de la chaine
ERREUR
}

Attention, je viens d'écrire ce test en lisant la doc, je ne garantis
pas sa validité absolue, et en outre il ne vérifie pas les séquences
invalides car trop longues. Malgré tout, un code de ce genre suffit pour
distinguer UTF-8 de tout le reste.

Euh... je suis preneur des explications sur le pourquoi du comment - en
fait vu que tu as lu la doc, si tu as des pointeurs ça me ferait gagner
du temps, hum

Le 15/02/2010 16:32, Pierre Goiffon a écrit :

Le BOM, m'avait-il dit, ne correspondait à aucun caractère
dans aucun charset ISO 8 bits dérivé de us-ascii.

C'est exact. Il y a trop peu d'emplacements dans les charsets 8 bits
pour en dépenser un avec un « zero-width no-break space ». De toute
manière il ne pourrait en aucun cas servir de « byte order mark »
puisque renverser l'ordre d'un seul octet donne le même octet, au
contraire du BOM en UTF-16 et UTF-32, où le renversement des 2 ou 4
octets donne une valeur qui est garantie être à jamais invalide.

Je ne suis pas sûr de t'avoir compris :

En effet. Pour comprendre ce que je voulais dire, il faut savoir ce
qu'est ce caractère Unicode bizarre qui s'est appelé d'abord ZWNBSP
avant de s'appeler BOM, pourquoi il peut servir de BOM dans UTF-16 et
pourquoi « ça marche », avant de se poser la question de l'existence
d'un BOM en UTF-8 ou dans les autres encodages dont la base est l'octet
et pas un mot de 2 ou 4 octets.

Le ZWNBSP (zero-width non-breaking space), de code Unicode U+FEFF, a
d'abord été utilisé pour empêcher la coupure entre deux mots, mais sans
ajouter d'espace visible (contrairement à l'espace insécable NBSP qui a
une certaine largeur). Cet usage est maintenant déconseillé, le gluon de
mots U+2060 lui étant préféré.

Mais pourquoi ce caractère U+FEFF peut-il aussi être utilisé dans UTF-16
comme indicateur d'ordre des octets (IOO) en français, c'est-à-dire BOM
(byte order mark) en anglais ? La raison tient à deux choses. La
première est qu'il existe deux versions d'UTF-16, l'une dans laquelle
U+FEFF est codé par FE suivi de FF, l'autre dans laquelle il est codé FF
suivi par FE. La seconde est que le caractère U+FFFE est *garanti* par
la norme Unicode de ne jamais être utilisé, et donc de toujours rester
invalide. Si par exemple on avait choisi notre bon vieux NBSP U+00A0
comme BOM, ça n'aurait pas marché parce que le caractère U+A000 existe
aussi (c'est la syllabe yi it du syllabaire yi des Monts frais !) : on
ne pourrait donc pas savoir si « A0 00 » est une espace insécable en
UTF-16 LE, ou bien une syllabe yi it en UTF-16 BE. Idem dans l'autre
sens pour « 00 A0 ».

Pour en savoir plus sur ces caractères :
--------------------------------------------------
U+FEFF :
http://www.unicode.org/fr/charts/PDF/UFE70.pdf
http://www.unicode.org/charts/PDF/UFE70.pdf

U+2060 :
http://www.unicode.org/fr/charts/PDF/U2000.pdf
http://www.unicode.org/charts/PDF/U2000.pdf

U+FFFE :
http://www.unicode.org/fr/charts/PDF/UFFF0.pdf
http://www.unicode.org/charts/PDF/UFFF0.pdf

U+00A0 :
http://www.unicode.org/fr/charts/PDF/U0080.pdf
http://www.unicode.org/charts/PDF/U0080.pdf

U+A000 :
http://www.unicode.org/fr/charts/PDF/UA000.pdf
http://www.unicode.org/charts/PDF/UA000.pdf
--------------------------------------------------

Un BOM n'a donc de sens que dans les encodages pour lesquels existent à
la fois des versions petit-boutiste et grand-boutiste, comme UTF-16. Au
contraire l'encodage UTF-8 n'existe qu'en une seule version, où l'ordre
des octets est parfaitement déterminé, il n'y a donc pas lieu d'avoir un
indicateur d'*ordre des octets*.

dans les charsets ISO 8 bits, ce
sont les zones de 0x80 à 0x9F qui sont réservées,

Si en écrivant « réservées » tu veux dire « dont toutes les positions
sont invalides », alors ceci vaut seulement pour ceux tels que "ISO
8859-1" (sans trait d'union). Dans "ISO-8859-1", toutes les positions
sont définies, dont des caractères de commande aux valeurs 00 à 1F, 7F,
et 80 à 9F. Et puis bien sûr il y a des charsets 8 bits tels que cp1252
ou cp850 qui définissent des caractères imprimables à ces positions.

<http://fr.wikipedia.org/wiki/ISO_8859-1#ISO_8859-1_par_rapport_.C3.A0_ISO-8859-1>

De toute manière, mon argument était que renverser l'ordre des octets
dans un charset 8 bits ne peut jamais remplacer un caractère valide par
un caractère invalide : la notion même de BOM ne peut donc pas exister
dans ces charsets.

or les octets utilisés
dans les BOM pour UTF-32, UTF-16 ou UTF-8 sont tous hors de cette zone,
et correspondent donc bien à des caractères valides dans les charsets
ISO 8 bits.

Oui. Note que je ne parlais pas de ça dans le paragraphe auquel tu
répondais, mais oui, tu as raison (en considérant bien sûr le NUL comme
valide dans les charsets ISO). Ceci prouve donc bien que le BOM UTF-16
ou UTF-32 n'est d'aucune utilité si le choix n'est pas restreint à
« petit-boutiste ou gros-boutiste ? » et que l'on risque de rencontrer
des charsets 8 bits.

Je pense que tu voulais dire que le caractère utilisé pour le BOM
(U+FEFF) n'était présent dans aucun des charsets ISO 8 bits ?

Non, j'étais plus radical que ça. Je voulais dire que la notion même de
BOM ne peut pas exister dans un charset 8 bits. Je ne me limitais donc
ni à la valeur du BOM spécifique U+FEFF, ni aux charsets ISO.

[...]

L'analyse du contenu d'un fichier dans un charset autre que l'UTF-8,
pour en déduire la langue et le charset, *est* un problème difficile.

Mais l'analyse d'un fichier dans un charset quelconque, simplement pour
en déduire si oui ou non c'est de l'UTF-8 (et ce, quelle que soit la
langue utilisée) est une question *triviale*. Un simple iconv de UTF-8
vers UTF-16, par exemple, te donne immédiatement la réponse.

Si l'on n'a pas de l'UTF-8, je suppose que iConv va tomber sur des
séquences d'octets invalides et qu'il va le signaler ?

Oui, c'est exactement ça. Il est extrêmement difficile de tomber par
hasard sur une séquence UTF-8 valide, à moins bien sûr de se limiter à
de l'ASCII 7 bits. Jean-Marc Desperrier a néanmoins expliqué que ce
n'était pas impossible (exemple de 2 ou 3 caractères chinois BIG-5).

[...]

Attention, je viens d'écrire ce test en lisant la doc, je ne garantis
pas sa validité absolue, et en outre il ne vérifie pas les séquences
invalides car trop longues. Malgré tout, un code de ce genre suffit pour
distinguer UTF-8 de tout le reste.

Euh... je suis preneur des explications sur le pourquoi du comment - en
fait vu que tu as lu la doc, si tu as des pointeurs ça me ferait gagner
du temps, hum

Désolé. Ma bible pour Unicode et UTF-8 est la page suivante :
<http://www.cl.cam.ac.uk/~mgk25/unicode.html>

En particulier <http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8>
explique l'encodage de toutes les valeurs possibles entre U+0000 et
U+7FFFFFFF. Noter que ce tableau est trop grand, puisque la norme
actuelle interdit les valeurs plus grandes que U+10FFFF, ce qui limite
les valeurs UTF-8 à 4 octets au maximum.

Cela dit, la page de Wikipédia en français me semble très bien faite :
<http://fr.wikipedia.org/wiki/UTF-8>.

Mon petit algo ne représentait pas autre chose que ceci :
--------------------------------------------------------------------

Représentation binaire UTF-8 Signification
0xxxxxxx 1 octet codant 1 à 7 bits
110xxxxx 10xxxxxx 2 octets codant 8 à 11 bits
1110xxxx 10xxxxxx 10xxxxxx 3 octets codant 12 à 16 bits
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 4 octets codant 17 à 21 bits

--------------------------------------------------------------------
... et on peut y ajouter les restrictions concernant d'une part
l'unicité du codage (interdiction de formes « overlong ») et d'autre
part l'interdiction de certains points de code.

Cordialement,
--
Olivier Miakinen

On 16/02/2010 00:52, Olivier Miakinen wrote:

Je ne suis pas sûr de t'avoir compris :

En effet. Pour comprendre ce que je voulais dire, il faut savoir ce
qu'est ce caractère Unicode bizarre qui s'est appelé d'abord ZWNBSP
avant de s'appeler BOM, pourquoi il peut servir de BOM dans UTF-16 et
pourquoi « ça marche », avant de se poser la question de l'existence
d'un BOM en UTF-8 ou dans les autres encodages dont la base est l'octet
et pas un mot de 2 ou 4 octets.

(...)

Olivier, milles merci de ce complément très instructif ! J'aurai sans
doute pu trouver ces infos quelque part, mais entre temps limité et
toutes les docs parcellaires qui existent de ce de là...
Donc un sincère grand merci pour cette vulgarisation !

dans les charsets ISO 8 bits, ce
sont les zones de 0x80 à 0x9F qui sont réservées,

Si en écrivant « réservées » tu veux dire « dont toutes les positions
sont invalides », alors ceci vaut seulement pour ceux tels que "ISO
8859-1" (sans trait d'union). Dans "ISO-8859-1", toutes les positions
sont définies, dont des caractères de commande aux valeurs 00 à 1F, 7F,
et 80 à 9F. Et puis bien sûr il y a des charsets 8 bits tels que cp1252
ou cp850 qui définissent des caractères imprimables à ces positions.

cp1252 et cp850 ne sont pas des charsets ISO...

Euh... je suis preneur des explications sur le pourquoi du comment

Désolé. Ma bible pour Unicode et UTF-8 est la page suivante :
<http://www.cl.cam.ac.uk/~mgk25/unicode.html>

En particulier<http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8>
explique l'encodage de toutes les valeurs possibles entre U+0000 et
U+7FFFFFFF. Noter que ce tableau est trop grand, puisque la norme
actuelle interdit les valeurs plus grandes que U+10FFFF, ce qui limite
les valeurs UTF-8 à 4 octets au maximum.

Cela dit, la page de Wikipédia en français me semble très bien faite :
<http://fr.wikipedia.org/wiki/UTF-8>.

Je n'étais jusqu'ici allé lire que la FAQ sur unicode.org (mais pas
encore tout...), et juste parcouru en diagonale la page Wikipedia fr. Je
vais essayer de trouver du temps pour me plonger plus en détails sur
celles-ci et l'autre url que tu me donne !

Merci !

Le 18/02/2010 12:14, Pierre Goiffon a écrit :

Olivier, mille mercis de ce complément très instructif !

C'était avec plaisir.

[...]

Si en écrivant « réservées » tu veux dire « dont toutes les positions
sont invalides », alors ceci vaut seulement pour ceux tels que "ISO
8859-1" (sans trait d'union). Dans "ISO-8859-1", toutes les positions
sont définies, dont des caractères de commande aux valeurs 00 à 1F, 7F,
et 80 à 9F. Et puis bien sûr il y a des charsets 8 bits tels que cp1252
ou cp850 qui définissent des caractères imprimables à ces positions.

cp1252 et cp850 ne sont pas des charsets ISO...

Nous sommes bien d'accord. Mais jusqu'à preuve du contraire ce sont
des charsets couramment utilisés, surtout cp1252. Et une solution qui
ne fonctionnerait que pour les charsets ISO -- à supposer que ce soit
possible -- ne serait pas viable.

Cordialement,
--
Olivier Miakinen