[spip-dev] Re: unicode

Dev
1

Heu, comment tu fais pour tester l'unicode ?

Bon, j'ai peut-être mal compris, je ne sais pas ce que tu appelles "tester
l'unicode", en fait je parle plutôt des Ӓ

En gros, tu avais installé cette fonction sur quelques champs, personne ne
s'est plaint et ces champs marchaient chez moi à la perfection (russe,
japonais..)- du coup j'ai étendu à tous les champs.

-- Fil

2

Bon, j'ai peut-être mal compris, je ne sais pas ce que tu appelles "tester
l'unicode", en fait je parle plutôt des Ӓ

Ah ok, je croyais que tu parlais d'avoir directement de l'unicode dans
la base. Je sais pas trop comment on peut faire pour ça.

3

@ Antoine Pitrou <antoine@rezo.net> :

>Bon, j'ai peut-être mal compris, je ne sais pas ce que tu appelles "tester
>l'unicode", en fait je parle plutôt des &#1234;

Ah ok, je croyais que tu parlais d'avoir directement de l'unicode dans
la base. Je sais pas trop comment on peut faire pour ça.

Je pense qu'on pourra essayer des choses du genre conversion de charset au
niveau de la restauration d'archives. Par exemple si je fais un site en
russe avec comme charset windows-1251, et que je veux l'exporter vers une
base dont le charset est iso8859-1, il faudra bien que mes caractères
passent de leur code ascii > 127 à une représentation en &#aaa;... et
vice-versa. Mais ça, c'est plutôt post-1.4 je pense :wink:

-- Fil

4

Dans la foulée, iso-8859-1 est complêtement hors d'age. C'est
sio-8859-15 qu'il faut utiliser (!)

5

> Dans la foulée, iso-8859-1 est complêtement hors d'age. C'est
> sio-8859-15 qu'il faut utiliser (!)

Concrètement ça veut dire quoi ? Si on passe le charset par défaut de
iso-8859-1 à iso-8859-15, est-ce qu'il y a la moindre chance qu'une base de
données existante se retrouve avec des caractères déformés, perdus,
illisibles, transformés etc. ?

Oui, bien sûr.

Et si on laisse iso-8859-1, qu'est-ce qu'on
perd ?

L'Euro, le . (oe ligaturé) entre autres..
Ces caractères remplacent d'autres caractères moins utilisés, comme le
symbole de devise internationale (dessiné sur les claviers PC à droite
du dollar (AltGr $) €
http://www.cs.tut.fi/~jkorpela/latin9.html

Les remplacements :

6

Autrement dit, si vous utilisez des diaresis, des barres brisées (un
pipe coupé) des 1/4, 1/2, 3/4, des cédilles (outes seules), des accents
aigus (tous seuls), des diaresis (tous seuls), il va y avoir des pb de
lecture, ils seront remplacés par d'autres caractères particuliers.

Autant faire les choses bien : les broken bar, currency, 1/2 3/4 1/4 peuvent
avoir été utilisés... Il faudrait donc procéder à la mise à jour de la base:

chr(164) -> &#00A4; // currency symbol
chr(166) -> &#00A6; // broken bar
chr(168) -> &#00A8; // diaeresis
chr(180) -> &#00B4; // acute accent
chr(184) -> &#00B8; // cedilla
chr(188) -> &#00BC; // vulgar fraction one quarter
chr(189) -> &#00BD; // vulgar fraction one half
chr(190) -> &#00BE; // vulgar fraction three quarters

Il faudra passer les nombre hex en décimal, et faire la requête SQL qui va
bien... (cf. fonction stripslashes_base() dans ecrire/inc_base.php3)

Puisque justement on introduit un charset de référence, autant faire ça
maintenant.

-- Fil

7

Heu, paraît qu'il y a plein de brouteurs qui ne supportent pas le
iso-8859-15... ? De plus, à part le symbole euro, l'intérêt est
limité, non ?

Fil wrote:

8

Heu, paraît qu'il y a plein de brouteurs qui ne supportent pas le
iso-8859-15... ?

Ah, faut faire gaffe...

De plus, à part le symbole euro, l'intérêt est limité, non ?

Le oe... et l'Avenir !

>Il faudra passer les nombre hex en décimal

C'est les mêmes 8-!

-- Fil

9

Plein, non. juste IE* :-). Et encore, je crois qu'ils ont (enfin !) accepté
ce standard. Vu le temps qu'ils ont mis à accepter le PNG, le -15... ils
n'ont mis que 4 ans. C'est pas si mal :wink:

Pour ce qui est de l'intérêt, c'est une question de normalisation. Elle
a changé, il faut la respecter, point barre... Tous les brouteurs
récents la gèrent, les netscape* la remplacent par l'iso -1. Les MSIE,
je ne sais pas....
Hormis l'euro, le -15 c'est le seul moyen (avec l'iso -15) de faire des
oe, des << et des >>, des tirets longs.. Bref, coller à la typo française.

10

Plein, non. juste IE* :-). Et encore, je crois qu'ils ont (enfin !) accepté
ce standard.

Ca fait plein de machines qui ne sont pas à jour.... Y aussi Netscape 4,
peut-être.

Pour ce qui est de l'intérêt, c'est une question de normalisation. Elle
a changé, il faut la respecter, point barre... Tous les brouteurs
récents la gèrent, les netscape* la remplacent par l'iso -1. Les MSIE,
je ne sais pas....

Tant qu'à utiliser un charset normalisé, autant attendre un peu et passer
en utf-8, non ? L'iso-8859-15 n'apporte pratiquement rien :

Hormis l'euro, le -15 c'est le seul moyen (avec l'iso -15) de faire des oe, des << et des >>, des tirets longs.. Bref, coller à la typo française.

Les tirets longs, je ne sais pas, c'est pas très pratique à taper dans un
brouteur. Les << et >>, pareil (Alt + 0171 et Alt + 0187), et il y a des
entités HTML pour ça (&laquo;, &raquo;).

Note que côté normalisation, on aurait des efforts à faire en HTML aussi :wink:

A propos d'Unicode, une FAQ assez riche :
http://www.cl.cam.ac.uk/~mgk25/unicode.html

11

Tant qu'à utiliser un charset normalisé, autant attendre un peu et passer
en utf-8, non ? L'iso-8859-15 n'apporte pratiquement rien :

Oui, mais il est compatible avec l'iso 8859-1.
Par contre, l'UTF8, c'est pas encore pour demain...

Les tirets longs, je ne sais pas, c'est pas très pratique à taper dans un
brouteur. Les << et >>, pareil (Alt + 0171 et Alt + 0187), et il y a des

Amis de la touche "compose", bonjour.

Je tape <COMPOSE> < < et j'ai «
Je tape <compose> o e et j'ai .

Note que côté normalisation, on aurait des efforts à faire en HTML aussi :wink:

yop :wink:

12

Amis de la touche "compose", bonjour.

Je tape <COMPOSE> < < et j'ai «
Je tape <compose> o e et j'ai .

"compose".... heu.... ?? c'est où sur mon clavier ?

note que ton "oe composé" s'affiche "." chez moi (mozilla), je sais pas
si c'est voulu.

13

pour l'un ou pour l'autre. Autant passer directement en UTF8, les navigateurs
récents le supportent très bien.

Je dis des bêtises : est-ce qu'on pourrait stocker en utf8, mais avoir des
pages dont le charset serait fixé par le webmaster : ainsi si mon brouteur
parle japonais (JIS-xxx) mais pas utf8, SPIP lui cause en JIS, reçoit du
JIS, et stocke tout ça en utf8 ? Idem avec iso-latin, windows-1251, etc..

C'est pas très lourd d'intégrer/refaire tous ces filtres, si ?

Si on peut le faire, on se retrouve avec la possibilité de mélanger
différents charsets dans une même base, voire même de "parler" des charsets
différents à des clients différents ?

J'ai bon ?

-- Fil

14

Sur tous les claviers unix, ou - sous linux - c'est la touche WIN-Droite

Hélas, cette super touche hyper pratique n'existe pas sur Mac ni sous
Win. Enfin... elle n'est pas gérée.

15

Refaire, très lourd, à mon avis. Si on passe un jour en utf-8, les
brouteurs devront suivre. Au pire on pourra faire une moulinette cradingue
pour l'iso-8859-occidental : prendre les 0x7F-0xFF utf-8 (sur deux
octets) et les décoder en 0x7F-0xFF normaux. Y en a qui vont hurler
mais c'est à peu près fidèle à mon avis (au niveau des caractères
accentués tout au moins).

Je connais pas assez : pointeurs ?

Note, pour l'utf-8, ça risque d'entraîner des bugs dans certaines
fonctions, à cause du codage multi-caractères....

Oui, couper() strlen() etc.. Il faudra les adapter ; c'est un gros chantier
en fait...

Un autre problème est la mise à jour de la base, qui va faire
timeouter une bonne partie des serveurs.

Il suffira d'y aller poco a poco.

Pour gérer les envois de mails ça va pas être triste non plus : on les
passera (horreur!) en HTML :wink:

-- Fil

16

Fil wrote:

Refaire, très lourd, à mon avis. Si on passe un jour en utf-8, les
brouteurs devront suivre. Au pire on pourra faire une moulinette cradingue
pour l'iso-8859-occidental : prendre les 0x7F-0xFF utf-8 (sur deux
octets) et les décoder en 0x7F-0xFF normaux. Y en a qui vont hurler
mais c'est à peu près fidèle à mon avis (au niveau des caractères
accentués tout au moins).

Je connais pas assez : pointeurs ?

http://www.cl.cam.ac.uk/~mgk25/unicode.html

Pour gérer les envois de mails ça va pas être triste non plus : on les
passera (horreur!) en HTML :wink:

Ah non ! On les passera en utf-8....

17

Ouais, quand tu vois que OE 6 ne gère toujours pas le -15, t'as bon
espoir pour l'UTF...

18

Ouais, quand tu vois que OE 6 ne gère toujours pas le -15, t'as bon
espoir pour l'UTF...

Raté, je viens d'essayer, OE 5.5 affiche l'UTF-8 :slight_smile:

D'ailleurs, ce message est composé en UTF-8, qui peut le lire
correctement ? (je rajoute un € dans la balance, tiens)

19

Ouais, quand tu vois que OE 6 ne gère toujours pas le -15,
t'as bon espoir pour l'UTF...

IE6 gere très bien l'UTF-8 (sous win, pour mac je ne sais pas).
J'ai fait pas mal de test pour gerer le japonais sous spip et les modifs
sont assez simples.

Il suffit d'indiquer le charset dans toutes les pages (public et prive)
et automatiquement toutes les "requetes" sont codees en UTF-8.
Conclusion tout le contenu de la base est en UTF-8 egalement. Et ensuite
lors de l'edition du texte on n'a aucune entite #XXX; meme en japonais
:wink:

Apres il faut adapter la fonction typo() (pas fait car elle ne sert pas
en japonais) et le plus gros boulot est d'avoir des fonctions strlen,
strtoupper, etc. qui soient compatibles utf8. Mais là je ne sais pas
trop comment aborder ce pb...

20

À part les ??? rajoutés dans la balance, aucun problème sous mutt/1.4i sur
FreeBSD/4.6. Mais un tel sondage est-il adapté pour cette liste? :slight_smile: