CSS, IE7 et background

On 03/02/2010 00:32, Olivier Miakinen wrote:

En conclusion : trouve-toi donc un éditeur UTF-8 qui sauve les pages
sans ces $#%¬ de saloperies de BOM qui foutent la merde alors que ça
ne sert strictement à *rien* en UTF-8 !

Oh olivier, te voilà bien aigris :D
Le BOM en UTF-8 peut servir à quelque chose : permettre de déterminer
facilement que l'on a à faire à un codage d'Unicode de manière quasi
certaine ! Dans un contexte Web, c'est par contre en effet, on peut le
dire, inutile, et source de nombreux bugs ! (j'ai en mémoire des crash
retentissants de PHP avec des fichiers sources en UTF-16 BOM, mais
c'était il y a quelques années...)

Le 05/02/2010 14:30, Pierre Goiffon m'a répondu :

En conclusion : trouve-toi donc un éditeur UTF-8 qui sauve les pages
sans ces $#%¬ de saloperies de BOM qui foutent la merde alors que ça
ne sert strictement à *rien* en UTF-8 !

Oh olivier, te voilà bien aigri :D

;-)

Le BOM en UTF-8 peut servir à quelque chose : permettre de déterminer
facilement que l'on a à faire à un codage d'Unicode de manière quasi
certaine !

C'est bien ce que je dis, ça ne sert à rien. Parce que le simple fait
pour un texte d'être décodable en UTF-8 prouve déjà de manière quasi
certaine que c'est effectivement de l'UTF-8 !

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 :
à moins de mettre exprès côte à côte des caractères improbables dans un
texte par ailleurs écrit sans accents, c'est impossible. Et bien entendu
si on s'amuse à ça on peut tout aussi bien commencer un texte par la
séquence  pour faire croire à un BOM, cet argument se retournant donc
contre lui-même.

Là où un BOM serait utile, ce serait pour distinguer entre des jeux de
caractères tels que tous les ISO-8859-X, EBCDIC, et l'ensemble des
CPnnnn, mais là bien sûr ça ne peut pas exister. Les deux seuls usages
possibles pour le BOM sont donc de distinguer entre UTF-16BE et UTF-16LE
d'une part, et entre UTF-32BE et UTF-32LE d'autre part.

Dans un contexte Web, c'est par contre en effet, on peut le
dire, inutile, et source de nombreux bugs ! (j'ai en mémoire des crash
retentissants de PHP avec des fichiers sources en UTF-16 BOM, mais
c'était il y a quelques années...)

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.

Cordialement,
--
Olivier Miakinen

dans (in) fr.comp.infosystemes.www.auteurs, Olivier Miakinen
<om+news@miakinen.net> ecrivait (wrote) :

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.

--
Eric

On 05/02/2010 16:14, Olivier Miakinen wrote:

Le BOM en UTF-8 peut servir à quelque chose : permettre de déterminer
facilement que l'on a à faire à un codage d'Unicode de manière quasi
certaine !

C'est bien ce que je dis, ça ne sert à rien. Parce que le simple fait
pour un texte d'être décodable en UTF-8 prouve déjà de manière quasi
certaine que c'est effectivement de l'UTF-8 !

Dans le cadre du Web, non. Et même dans la plupart des cas, en fait.
Mais si on souhaite faire un détection vraiment simple, simplement lire
l'existence d'un bom simplifie grandement la vie ! C'est tout ce que je
voulais dire, et c'était plutôt une réponse en forme de clin d'oeil,
mais il me semble que tu es de mauvaise humeur aujourd'hui ;)

Dans un contexte Web, c'est par contre en effet, on peut le
dire, inutile, et source de nombreux bugs ! (j'ai en mémoire des crash
retentissants de PHP avec des fichiers sources en UTF-16 BOM, mais
c'était il y a quelques années...)

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.

Oui, j'ai écrit un peu vite et j'aurais du peut être éviter le potentiel
raccourci.

Donc : le BOM sur UTF-8 ne sert à rien dans le contexte évoqué par le
posteur initial.
L'utilité première du BOM est sur UTF-16. Mais en parlant de UTF-16,
attention car il y a encore de bien trop nombreux prb avec des outils
pourtant récents et régulièrement mis à jour.

Voilà reformulé :)

Le Fri, 05 Feb 2010 14:30:33 +0100, Pierre Goiffon a écrit :

Le BOM en UTF-8 peut servir à quelque chose

À casser la comptabilité avec l'ASCII (7 bits évidemment). Un fichier
HTML, cgi-shell... est identique quelquesoit le jeu de caractères aux
données près.

Il y a un tas de programmes qui n'arrivent plus à lire la première ligne
d'un fichier avec un BOM.
--
Patrick Texier

vim:syntax=mail:ai:ts=4:et:twr

Le 05/02/2010 16:50, Pierre Goiffon m'a répondu :

C'est bien ce que je dis, ça ne sert à rien. Parce que le simple fait
pour un texte d'être décodable en UTF-8 prouve déjà de manière quasi
certaine que c'est effectivement de l'UTF-8 !

Dans le cadre du Web, non. Et même dans la plupart des cas, en fait.

Ben si. Je ne vois d'ailleurs pas pourquoi tu distingues à chaque fois
le cas du web des autres cas : il n'existe pas de domaine où la lecture
d'un BOM soit plus fiable que la lecture du contenu pour déterminer si
oui ou non on a de l'UTF-8. De deux choses l'une : soit tu peux obtenir
le charset par une information extérieure de type Content-Type et tu
n'as pas besoin de BOM ; soit tu ne peux te baser que sur le contenu
pour choisir entre les centaines d'encodages connus et autant le faire
complètement.

Mais si on souhaite faire un détection vraiment simple, simplement lire
l'existence d'un bom simplifie grandement la vie !

Je ne peux pas être d'accord. Les microsecondes gagnées pour reconnaître
l'encodage dans le cas où un BOM existe sont très loin de compenser les
inconvénients -- sans compter que tu ne peux pas te fier au seul BOM
puisque la plupart du temps il ne sera pas là.

C'est tout ce que je
voulais dire, et c'était plutôt une réponse en forme de clin d'oeil,
mais il me semble que tu es de mauvaise humeur aujourd'hui ;)

Non, je ne suis pas du tout de mauvaise humeur ! Je réagis juste face à
une affirmation fausse, de la même façon que tu réagirais si quelqu'un
prétendait que du XHTML 1.0 transitional permet d'écrire du code plus
propre que le HTML 4.01 Strict.

[...]
Donc : le BOM sur UTF-8 ne sert à rien dans le contexte évoqué par le
posteur initial.

Le BOM sur UTF-8 ne sert à rien, quel que soit le contexte. Enfin... si,
en cherchant bien je pourrais bien imaginer un contexte où on puisse lui
trouver une utilité : ce serait pour gérer un système de fichiers dans
lequel on ne puisse avoir que *deux* encodages en tout et pour tout,
mettons par exemple Windows1252 et UTF-8. En dehors de cette situation
hypothétique dont je ne sais même pas si elle pourrait exister quelque
part, il n'y a vraiment pas de raison de s'embêter avec ce machin qui,
comme le rappelle Patrick Texier, casse la compatibilité avec ASCII --
et qui casse aussi la concaténation de fichiers, problème encore
différent de celui de l'inclusion de fichiers rencontré par Éric.

L'utilité première du BOM est sur UTF-16. Mais en parlant de UTF-16,
attention car il y a encore de bien trop nombreux prb avec des outils
pourtant récents et régulièrement mis à jour.

L'utilité unique du BOM est sur UTF-16 *et sur UTF-32*.

--
Olivier Miakinen

Le 2/5/10 10:46 PM, Olivier Miakinen a écrit :

Je réagis juste face à
une affirmation fausse, de la même façon que tu réagirais si quelqu'un
prétendait que du XHTML 1.0 transitional permet d'écrire du code plus
propre que le HTML 4.01 Strict.

Ben ... là yapaphoto le XHTML c'est dégueu !
Yaka faire du HTML "propre" épivala.

--
sm

On 05/02/2010 22:46, Olivier Miakinen wrote:

il n'existe pas de domaine où la lecture
d'un BOM soit plus fiable que la lecture du contenu pour déterminer si
oui ou non on a de l'UTF-8. De deux choses l'une : soit tu peux obtenir
le charset par une information extérieure de type Content-Type et tu
n'as pas besoin de BOM ; soit tu ne peux te baser que sur le contenu
pour choisir entre les centaines d'encodages connus et autant le faire
complètement.

Mais si on souhaite faire un détection vraiment simple, simplement lire
l'existence d'un bom simplifie grandement la vie !

Je ne peux pas être d'accord. Les microsecondes gagnées pour reconnaître
l'encodage dans le cas où un BOM existe sont très loin de compenser les
inconvénients -- sans compter que tu ne peux pas te fier au seul BOM
puisque la plupart du temps il ne sera pas là.

Je me souvenais avoir entendu parler de cet usage en discutant avec un
partenaire. Le BOM, m'avait-il dit, ne correspondait à aucun caractère
dans aucun charset ISO 8 bits dérivé de us-ascii. J'ai peut être pris
cette affirmation pour acquise un peut trop rapidement... Dans leur cas,
ils avaient des tas de fichiers à traiter en Latin-1, Windows-1252 et
UTF-8, et un prb important de volume.

Les valeurs des BOM suivant les codages sont indiquées dans la FAQ Unicode :
http://www.unicode.org/faq/utf_bom.html#bom4
En UTF-8 c'est EF BB BF.
En Latin-1, cette suite correspond aux caractères "ï", "»" puis "¿". Il
n'est pas impossible qu'elle débute un fichier, juste peu probable.

L'analyse précise du contenu du fichier me parait extrêmement complexe,
et je ne connais pas de librairie libre (pas forcément gratuite) qui
proposent ce service intégrable dans une application. je crois me
rappeler que Mozilla avait commencé à rendre disponible l'api de
détection utilisée dans le browser ? En fait je n'ai pas eu trop à me
pencher sur le sujet...

Il est de toute façon préférable de bien stocker le charset à côté des
données, tout comme on n'imaginerai pas enregistrer un flux de données
binaire sans spécifier de quel format il s'agit !

L'utilité première du BOM est sur UTF-16. Mais en parlant de UTF-16,
attention car il y a encore de bien trop nombreux prb avec des outils
pourtant récents et régulièrement mis à jour.

L'utilité unique du BOM est sur UTF-16 *et sur UTF-32*.

Oui, j'avais oublié UTF-32 (reste encore UTF-7 :) )

Le 09/02/2010 15:56, Pierre Goiffon a écrit :

Je me souvenais avoir entendu parler de cet usage en discutant avec un
partenaire. 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.

[...]

L'analyse précise du contenu du fichier me parait extrêmement complexe,
et je ne connais pas de librairie libre (pas forcément gratuite) qui
proposent ce service intégrable dans une application. je crois me
rappeler que Mozilla avait commencé à rendre disponible l'api de
détection utilisée dans le browser ? En fait je n'ai pas eu trop à me
pencher sur le sujet...

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 c'est
encore trop long pour toi, tu peux te contenter du test suivant :

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.

Il est de toute façon préférable de bien stocker le charset à côté des
données, tout comme on n'imaginerai pas enregistrer un flux de données
binaire sans spécifier de quel format il s'agit !

Oui.


Cordialement,
--
Olivier Miakinen

À (at) Tue, 09 Feb 2010 16:59:31 +0100,
Olivier Miakinen <om+news@miakinen.net> écrivait (wrote):

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 c'est
encore trop long pour toi, tu peux te contenter du test suivant :

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.

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

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