Re: CSS, IE7 et background
Olivier Miakinen
Le 02/02/2010 16:26, Eric Demeester a ï¿œcrit :
>
> Je bricole un site pour un copain et aprￜs l'avoir vￜrifiￜ sous FF 3.5
> et Opera 10, vient le pï¿œnible moment de regarder ce qui se passe avec
> IE.
>
> Sous IE7 je rencontre un bug connu (mauvaise prise en compte du
> background dans le <body>, mais je ne trouve plus comment le contourner.
> Quand je rafraichis l'affichage de la page, tout rentre dans l'ordre.
Je ne connaissais pas ce bug, mais en effet je vois un truc bizarre,
mais pas aprï¿œs rechargement de la page, ni (chose encore plus curieuse)
si c'est la premiï¿œre page que j'affiche aprï¿œs la page d'accueil quand je
viens juste d'ouvrir IE.
Je ne dirais pas que le background seul n'est pas pris en compte : il y
a aussi une marge ou un espacement (padding) diffï¿œrents de 0.
> Curieusement, je n'ai le problï¿œme ni avec IE5.5 ni avec IE6 (pour IE8,
> je ne sais pas, je ne l'ai pas).
Le problï¿œme existe aussi dans IE8.
> Dans ma CSS, j'ai :
>
> [...]
> font-family: "Comic Sans MS", [...]
Beuah. ;-)
> La page d'accueil du site :
> http://www.pagliaghju-di-cannetu.com/
Quoique je ne sache absolument pas si ï¿œa peut ï¿œtre la cause du bug, ta
page css <http://www.pagliaghju-di-cannetu.com/css/bergerie.css> est
dï¿œclarï¿œe en UTF-8 mais enregistrï¿œe en Latin1. Tu pourrais commencer par
corriger ï¿œa, pour voir si ï¿œa change quelque chose.
Cordialement,
--
Olivier Miakinen
Alex Vaure
> > Dans ma CSS, j'ai :
> >
> > [...]
> > font-family: "Comic Sans MS", [...]
>
> Beuah. ;-)
Ha, toi aussi ;-)
--
Alex
Vous avez beau dire, y'a pas seulement que de la pomme, y'a aut'chose.
�a serait pas d�s fois de la betterave, hein ?
alainL
> dans (in) fr.comp.infosystemes.www.auteurs, Eric Demeester
> <eric+...@galacsys.net> ecrivait (wrote) :
>
>> Je continue � chercher...
>
> .............
> J'ai donc construit le d�but de toutes mes pages sur ce mod�le :
> .....................................................................
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd">
>
> <head>
> <meta http-equiv="content-type" content="text/html;charset=utf-8">
> <title>Bergerie de Canneto</title>
>
> <!-- champs meta de referencement -->
> <?php include("./scripts/referencement.html"); ?>
> <!-- fin r�f�rencement -->
>
> <link rel="stylesheet" href="./css/bergerie.css" type="text/css">
> </head>
> .....................................................................
>
> J'ai pass� �a au validateur html du w3c et j'ai �t� agoni d'injures. �a
> aurait du me mettre la puce � l'oreille, mais comme je ne voyais pas o�
> se situait le probl�me (et pour cause, je ne le vois toujours pas), je
> suis pass� outre.
>
> Mais �a me titillait, tous ces messages d'erreur, alors j'ai modifi� ma
> page en supprimant l'appel au fichier stockant les meta de
> r�f�rencement.
>
> Et l�, le probl�me a disparu.
>
> Je me suis dit qu'il devait y avoir des erreurs de syntaxe dans
> referencement.html. Pour m'en assurer, j'ai recopi� le contenu de ce
> fichier directement dans le code source de ma page :
>
> .....................................................................
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd">
> [...]
> <!-- champs meta de referencement -->
> <meta name="description" lang="fr" content=[...]
> <meta name="keywords" lang="fr" content==[...]
> <meta name="Web" content==[...]
> [...]
> .....................................................................
>
> Et l�, bingo, aucun probl�me !
>
> ............
>
Je n'y connais rien ou si peu, mais je me demande si on peut mettre du
code en php dans le head ?
--
Alain
Olivier Miakinen
>
> Une chose est sï¿œre, il ne s'agit pas d'un problï¿œme de CSS mais
> d'insertion de fichiers, je m'explique :
>
> [...]
>
> J'ai pensￜ ￜ un problￜme d'encodage du fichier inclus, mais il ￜtait
> bien en utf-8 comme le reste du site.
>
> Faites l'expï¿œrience, affichez le source de :
> http://www.pagliaghju-di-cannetu.com/index.php
>
> Ensuite affichez le source de :
> http://www.pagliaghju-di-cannetu.com/bergerie.php
Fais l'expï¿œrience de demander (dans Firefox par exemple) l'affichage en
Latin1 de ces deux codes sources en UTF-8.
Avec la premiￜre page, tu vois ￜ deux endroits la sￜquence  (une fois
au tout dￜbut de la page, la seconde fois au dￜbut du ￜ menu du haut ￜ
dont je suppose qu'il est inclus par PHP).
Avec la seconde page, tu en vois une troisiￜme occurrence, pile poil lￜ
oￜ tu inclus tes champs meta.
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 !
Cordialement,
--
Olivier Miakinen
Olivier Miakinen
> Eric Demeester a ï¿œcrit :
Merci de faire un peu le mï¿œnage dans les citations.
> Je n'y connais rien ou si peu, mais je me demande si on peut mettre du
> code en php dans le head ?
Pourvu qu'il n'y ait pas de saletï¿œs de BOM parasites, la page rï¿œsultante
n'a aucun moyen de savoir si le HTML provient d'un fichier statique, ou
bien s'il a ￜtￜ gￜnￜrￜ par PHP, par Perl, par Java, par un programme C
compilￜ, ou par quoi que ce soit d'autre. Donc oui, on peut ￜ mettre du
code en php dans le head ￜ.
Cordialement,
--
Olivier Miakinen
SAM
est-ce vraiment bien n�cessaire que les images 860/572px
pesassent de 220ko � plus de 300ko
alors qu'� qualit� 60% et de poids frisant les 70/80ko
elle soient tout � fait supportables, acceptables ?
avec ma connexion ADSL,
l'attente du slide-show est vraiment longuette !
(page: la bergerie)
Refroidi (ou �chaud�, comme on veut),
j'ai �vit� de voir d'autres pages ou de cliquer o� que ce soit.
l'histoire du bogggage IE m'apparait comme broutille en comparaison
(de ttes fa�ons je n'ai pas d'IE reli� � l'Internet pour la voir)
(en local avec IE7 c'est toubon)
--
sm
SAM
>
> Ay�, j'ai trouv�. J'ai modifi� le code source de la page d'accueil et le
> probl�me a disparu. D�monstration en visualisant avec IE7 ou IE8 :
> http://www.pagliaghju-di-cannetu.com/index.php
Ha! c'est pour �a que c'est OK chez moi ? !
> Les autres pages n'ont pas �t� modifi�es, comme �a on voit facilement la
> diff�rence.
>
> Par contre je n'ai pas compris le pourquoi du comment.
>
> Une chose est s�re, il ne s'agit pas d'un probl�me de CSS
D'ailleurs, � ce propos,
faudra m'esspliquer pourquoi le conteneur ou ses �l�ments contenus
doivent se refarcir ce qui a d�j� �t� d�clar� au body comme :
background, font-family, tex-align
et m�me esspliquer ces font-size: 1px;
> mais d'insertion de fichiers, je m'explique :
Non, tu te fourvoies (cf plus bas)
> .....................................................................
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd">
>
> <head>
> <meta http-equiv="content-type" content="text/html;charset=utf-8">
> <title>Bergerie de Canneto</title>
>
> <!-- champs meta de referencement -->
> <?php include("./scripts/referencement.html"); ?>
> <!-- fin r�f�rencement -->
>
> <link rel="stylesheet" href="./css/bergerie.css" type="text/css">
> </head>
> .....................................................................
>
> J'ai pass� �a au validateur html du w3c et j'ai �t� agoni d'injures.
On ne doit pas pratiquer le m�me validateur ? !
Le mien n'a seulement r�l� que pour la balise </html> manquante
(avec le copi�-coll� du code ci-haut)
La page elle-m�me, pars�e par le php au pr�alable, satisfait
parfaitement le validateur que je fr�quente.
O� est le bl�me ?
> Faites l'exp�rience, affichez le source de :
> http://www.pagliaghju-di-cannetu.com/index.php
>
> Ensuite affichez le source de :
> http://www.pagliaghju-di-cannetu.com/bergerie.php
L� ya plein d'erreurs
en html on ne met pas
<img src="1.jg" alt="" />
mais :
<img src="1.jg" alt="">
on n'a pas le droit d'avoir plus d'un et un seul ID de m�me nom
<div id="bloc_vignette">
est r�p�t� plusieurs fois (3 fois)
> Ce qui nous int�resse, c'est ce sont les champs <meta> contenus entre
> head et </head>.
et pourquoi �a ?
Le validateur n'y a rien vu qui cloch�t.
> Voyez-vous une diff�rence ?
Non et c'est bien triste
> Avez-vous une explication ?
Oui,
faut des m�ta description et keywords diff�rents d'une page � l'autre
sinon le r�f�renceur croit que tu te moques de lui et passe
> Parce que moi, je patauge.
Corrige tes IDs
et n'utilise pas de balise auto-fermante avec un DocType HTML
Elles ne sont requises et obligatoires qu'en XHTML
--
sm
Bernd
> 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 !
Dans l'urgence, tu �dites la page avec un �diteur hexa qui voit bien les
3 octets parasites que tu �limines alors facilement.
Ensuite en effet, un �diteur comme pspad entre autres enrgistre "comme
il faut".
--
A+
Romer
Bernd
> Beaucoup de logiciels Windows (incluant Windows Notepad) en ajoutent
> un aux fichiers UTF-8.
J'utilise NotePad et PSPad depuis des lontemps et peut te dire qu'il ne
les ajoute pas � moins qu'il existe un r�glage dans les options du 1er
qui les autorise ou pas. Si c'est r�gl� sur "autoris�" �videmment, le
probl�me va se poser. Je ne l'ai pas ici pour v�rifier.
Le probl�me se pose par ex. avec BBEdit sur Mac car celui-ci propose
dans les pr�f�rences "enregistement avec Bom" ou "enregistement sans
Bom" .
Si on ne sait pas ce que cela signifie, on a le pb !
J'ai eu ce m�me probl�me voil� peut-�tre une dizaine d'ann�e et ai mis
une semaine de gal�re � en d�couvrir l'origine ! Les aides d'autres
internautes �taient bien moins nombreuses que maintenant.
--
A+
Romer
Pierre-Alain Dorange
> > > Dans ma CSS, j'ai :
> > > font-family: "Comic Sans MS", [...]
> > Beuah. ;-)
>
> On est du m�me avis, mais le client est roi :)
<http://bancomicsans.com/home.html>
--
Pierre-Alain Dorange <http://microwar.sourceforge.net/>
Ce message est sous licence Creative Commons "by-nc-sa-2.0"
<http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
SAM
> dans (in) fr.comp.infosystemes.www.auteurs, SAM
> <stephanemor...@wanadoo.fr.invalid> ecrivait (wrote) :
>
>> La page elle-m�me, pars�e par le php au pr�alable, satisfait
>> parfaitement le validateur que je fr�quente.
>> O� est le bl�me ?
>
Peut-�tre ?
Ou parce que mon Fx l'a traduite ?
J'ai soumis le source au validator
(y a un bouton fait pour, c'est tr�s pratique)
> Ce qu'il y a de surprenant quand on soumet une question ici, c'est qu'on
> se retrouve comme un insecte sur une table de dissection :)
Ha! ben ! pour s�r ;-)
Et puis fallait bien que je trouve qque chose
puisque je n'ai pas eu l'heur de voir le d�faut ;-)
--
sm
Olivier Masson
> <http://bancomicsans.com/home.html>
>
J'adore :)
Olivier Miakinen
>
> Mon excellent ï¿œditeur (Notepad++) n'y ï¿œtait pour rien. Comme bien
> souvent, le bug se situait entre la chaise et le clavier :)
Tu es trop sￜvￜre envers toi-mￜme, car c'ￜtait vraiment difficile ￜ
dￜtecter. Moi-mￜme je n'ai pas du tout pensￜ au BOM, mￜme quand un
ￜ diff -b ￜ entre tes deux pages m'a signalￜ comme diffￜrentes deux
lignes qui me semblaient parfaitement identiques, caractï¿œre par
caractￜre. ￜa n'a pas plus tiltￜ quand, essayant de retirer toutes les
espaces de dï¿œbuts de lignes sous vi j'ai vu une des lignes conserver
encore des espaces au dï¿œbut. C'est seulement quand le mï¿œme vi a fini
par m'afficher ￜ <feff> ￜ quelque part (sans d'ailleurs que je comprenne
pourquoi) que j'ai enfin compris qu'il y avait une saletￜ de BOM au
milieu du fichier.
> J'ai ensuite un peu creusￜ la question et trouvￜ :
> http://fr.wikipedia.org/wiki/Marque_d%27ordre_des_octets
>
> ￜ Problￜmes liￜs ￜ l'utilisation de la marque d'ordre des octets
> [...] ￜ
Excellent texte.
Cordialement,
--
Olivier Miakinen
Patrick Texier
Le Wed, 03 Feb 2010 23:38:35 +0100, Olivier Miakinen a ￜcritￜ:
> > Mon excellent ï¿œditeur (Notepad++) n'y ï¿œtait pour rien. Comme bien
> > souvent, le bug se situait entre la chaise et le clavier :)
Il me semble qu'avec Notepad++, il dï¿œtecte cette m.... de BOM et le
coche dans le menu de choix de caractï¿œres.
> Tu es trop sￜvￜre envers toi-mￜme, car c'ￜtait vraiment difficile ￜ
> dￜtecter. Moi-mￜme je n'ai pas du tout pensￜ au BOM, mￜme quand un
> ￜ diff -b ￜ entre tes deux pages m'a signalￜ comme diffￜrentes deux
> lignes qui me semblaient parfaitement identiques, caractï¿œre par
> caractￜre. ￜa n'a pas plus tiltￜ quand, essayant de retirer toutes les
> espaces de dï¿œbuts de lignes sous vi j'ai vu une des lignes conserver
> encore des espaces au dï¿œbut. C'est seulement quand le mï¿œme vi a fini
> par m'afficher ￜ <feff> ￜ quelque part (sans d'ailleurs que je comprenne
> pourquoi) que j'ai enfin compris qu'il y avait une saletￜ de BOM au
> milieu du fichier.
Ce n'est pas vi qui affiche <feff> mais Vim.
Le vrai vi version sourceforge <http://ex-vi.sourceforge.net/> travaille
dans l'encodage du systï¿œme et il me semble qu'il ne gï¿œre pas le BOM. Il
suffit de virer les trois premiers caractï¿œres.
Avec Vim, la procï¿œdure est la suivante :
Passer l'ï¿œditeur en UTF-8 s'il n'y est pas en ajoutant dans .vimrc :
===== .vimrc =======
if has("multi_byte")
set enc=utf-8
set fencs=ucs-bom,utf-8,latin1
" si le systï¿œme n'est pas en UTF-8 mettre :
set tenc=latin1
endif
====================
Avec un fichier ouvert :
:set fenc? " affiche l'encodage du fichier.
:set bomb? " teste la prￜsence de cette saletￜ de BOM.
:set nobomb " vire cette saletￜ de BOM.
Si on veut ï¿œcrire dans un autre jeu de caractï¿œres, on modifie la valeur
de fenc mais on ne touche jamais ￜ enc.
Pour entrer des caractï¿œres unicodes, Vim est trï¿œs pratique :
Par code :
<CTRL-V>u <4 chiffres hexa>
<CTRL-Q>u <4 chiffres hexa>
Par digraphes (oe pour ￜ, /- pour la croix latine...) :
<CTRL-K><2 lettres>
On a la liste des digraphes par :dig
--
Patrick Texier
vim:syntax=mail:ai:ts=4:et:tw=72
Pierre Goiffon
> 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...)
Olivier Miakinen
>
>> 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
>
> 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
Pierre Goiffon
>> Le BOM en UTF-8 peut servir � quelque chose : permettre de d�terminer
>> 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� :)
Patrick Texier
> 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.
Olivier Miakinen
>>
>> C'est bien ce que je dis, ￜa ne sert ￜ rien. Parce que le simple fait
>> certaine que c'est effectivement de l'UTF-8 !
>
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
SAM
>
> 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
Pierre Goiffon
> 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
> 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
>
>> Mais si on souhaite faire un d�tection vraiment simple, simplement lire
>> l'existence d'un bom simplifie grandement la vie !
>
> 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 :) )
Olivier Miakinen
>
> Je me souvenais avoir entendu parler de cet usage en discutant avec un
> 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
Paul Gaborit
� (at) Tue, 09 Feb 2010 16:59:31 +0100,
Olivier Miakinen <om+...@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/>
Paul Gaborit
� (at) Tue, 09 Feb 2010 17:17:56 +0100,
Paul Gaborit <Paul.G...@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.
Jean-Marc Desperrier
> dans (in) fr.comp.infosystemes.www.auteurs, Olivier Miakinen
> <om+...@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.
>
> 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�.
Pierre Goiffon
>> 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
> 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
Olivier Miakinen
>
>>> Le BOM, m'avait-il dit, ne correspondait ￜ aucun caractￜre
>>
>> C'est exact. Il y a trop peu d'emplacements dans les charsets 8 bits
>> maniￜre il ne pourrait en aucun cas servir de ￜ byte order mark ￜ
>> 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
Pierre Goiffon
>> Je ne suis pas s�r de t'avoir compris :
>
> En effet. Pour comprendre ce que je voulais dire, il faut savoir ce
> avant de s'appeler BOM, pourquoi il peut servir de BOM dans UTF-16 et
> 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 !
Olivier Miakinen
>
> 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