Coucou,
est-ce que quelqu'un a sous la main une fonction de conversion de caractères
isolatin -> { (numéro unicode du caractère) ?
Merci
-- Fil
Coucou,
est-ce que quelqu'un a sous la main une fonction de conversion de caractères
isolatin -> { (numéro unicode du caractère) ?
Merci
-- Fil
est-ce que quelqu'un a sous la main une fonction de conversion de caractères
isolatin -> { (numéro unicode du caractère) ?
RTFM ;-)) T'as de la chance :
"The first 128 characters are thus the ASCII characters. The octet
representing an ISO/IEC 8859-1 character is easily transformed to the
representation in UCS, by putting a 0 octet in front of it."
http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html#2
Enfin, ça ne marche que pour iso-8859-1...
Note : on parle d'Unicode pur, pas du codage UTF-8 qui est une version
"packée" d'Unicode !!! ;-)))))
@ Antoine Pitrou <antoine@rezo.net> :
> est-ce que quelqu'un a sous la main une fonction de conversion de caractères
> isolatin -> { (numéro unicode du caractère) ?RTFM ;-)) T'as de la chance :
"The first 128 characters are thus the ASCII characters. The octet
representing an ISO/IEC 8859-1 character is easily transformed to the
representation in UCS, by putting a 0 octet in front of it."Dismissed site: www.nada.kth.se
Enfin, ça ne marche que pour iso-8859-1...
Note : on parle d'Unicode pur, pas du codage UTF-8 qui est une version
"packée" d'Unicode !!! ;-)))))
Ce qui serait pas mal, c'est d'en faire une fonction php qui agisse en
fonction de lire_meta('charset'). Ainsi nos amis i18n compléteront la chose
au fur et à mesure.
function entites_unicode($texte) {
switch (lire_meta('charset')) {
case 'iso8859-1':
$texte = ...
}
return $texte;
}
Si quelqu'un veut se dévouer, j'ai la flemme
-- Fil
Heuuu....
Fil :
Ce qui serait pas mal, c'est d'en faire une fonction php qui agisse en
fonction de lire_meta('charset'). Ainsi nos amis i18n compléteront la chose
au fur et à mesure.
Je comprends pas, ça servirait à quoi ?
Yannick :
Mais il me semble que justement, en utf-8, iso-latin1 marche teckel...
Ah non pas du tout...
Bonjour,
Le 26 Nov 2002 23:13:52 +0100, Antoine a dit :
Yannick :
Mais il me semble que justement, en utf-8, iso-latin1 marche teckel...
Ah non pas du tout...
Ah ben si. Les 256 premiers caractères sont ISO-Latin 1 pile-poil. Ce
qui n'empêche pas le « é », par exemple, de se retrouver plus loin dans
le codage au bon moment. Mais ils ont fait ça justement pour que ISO-
Latin 1 serve de base et passe quasiment sans problème.
Gilles.
From spada@no-log.org Wed Nov 27 09:35:19 2002
Return-Path: <spada@no-log.org>
Received: from no-log.org (www.sinerj.org [80.67.172.6])
by miel.brainstorm.fr (Postfix) with ESMTP id C51311C737
for <spip-dev@rezo.net>; Wed, 27 Nov 2002 09:35:19 +0100 (CET)
Received: from no-log.org (smtp.no-log.org [80.67.172.8])
by no-log.org (Postfix) with SMTP id 1D31C5990
for <spip-dev@rezo.net>; Wed, 27 Nov 2002 09:34:13 +0100 (CET)
Received: from nice-1-a7-62-147-79-244.dial.proxad.net ([62.147.79.244])
(SquirrelMail authenticated user spada)
by mail.no-log.org with HTTP;
Wed, 27 Nov 2002 09:34:13 +0100 (CET)
Message-ID: <1042.62.147.79.244.1038386053.squirrel@mail.no-log.org>
@ Antoine Pitrou <antoine@rezo.net> :
Fil :
> Ce qui serait pas mal, c'est d'en faire une fonction php qui agisse en
> fonction de lire_meta('charset'). Ainsi nos amis i18n compléteront la chose
> au fur et à mesure.Je comprends pas, ça servirait à quoi ?
A faire que les backends passent sans problème d'un spip à l'autre,
indépendamment du charset des sites en question.
-- Fil
Ah ben si. Les 256 premiers caractères sont ISO-Latin 1 pile-poil.
Ce
qui n'empêche pas le « é », par exemple, de se retrouver plus loin dans
le codage au bon moment. Mais ils ont fait ça justement pour que ISO-
Latin 1 serve de base et passe quasiment sans problème.
Ben essaie de changer "iso-8859-1" en "utf-8" sur un site où les
accents ne sont pas codés en entités HTML, et tu verras bien....
Bonjour,
le codage au bon moment. Mais ils ont fait ça justement pour que ISO-
Latin 1 serve de base et passe quasiment sans problème.Ben essaie de changer "iso-8859-1" en "utf-8" sur un site où les
accents ne sont pas codés en entités HTML, et tu verras bien....
Je parlais -- je n'ai pas été assez clair -- des positions : de 1 à 255, ce sont les même caractères. Ensuite, la représentation binaire peut être différente. Ce qui, dans notre conversation (mais ai-je bien suivi ?), fait qu'un passage d'ISO Latin 1 à Unicode ne demande aucune table de traduction mais une représentation binaire différente.
Gilles.
> > est-ce que quelqu'un a sous la main une fonction de conversion de
> > caractères isolatin -> { (numéro unicode du caractère) ?
Bon, c'est dans le CVS : le backend est généré en unicode (par exemple
"généré en unicode"), il suffira d'étendre la fonction au fur
et à mesure des charsets qu'on rencontrera.
Question : faut-il retranscrire le maximum d'éléments dans le charset du
site si on sait faire (en gros, si le charset du site qui lit le backend est
iso-8859-1, faut-il qu'il retranscrive le é en 'é' dans sa base ?
Si on le fait, on est sûrs d'avoir une compatibilité maxi avec l'existant,
et peut-être moins de soucis par rapport au moteur de recherche... je ne
sais pas.
-- Fil
Heu, la fonction va faire combien de lignes exactement au bout
du compte ?
Je trouve ça vraiment inutile, et ça risque de faire chier les
webmestres qui vont se retrouver avec des { dans leurs sites
syndiqués (et s'ils veulent les afficher en texte brut ?).
Et comme tu dis, ça va faire foirer le moteur de recherche.
D'autant que le charset XML est là pour indiquer au site destination
de faire la conversation. C'est idiot que ce soit le site source
qui s'y colle.
D'autant que le charset XML est là pour indiquer au site destination
de faire la conversation.
Heu, bon, il peut faire la conversion aussi.
> Bon, c'est dans le CVS : le backend est généré en unicode (par exemple
> "généré en unicode"), il suffira d'étendre la fonction au fur
> et à mesure des charsets qu'on rencontrera.Heu, la fonction va faire combien de lignes exactement au bout
du compte ?
Je sais pas, autant qu'il faudra.
Je trouve ça vraiment inutile, et ça risque de faire chier les
webmestres qui vont se retrouver avec des { dans leurs sites
syndiqués (et s'ils veulent les afficher en texte brut ?).
As-tu une idée qui fonctionne pour syndiquer des sites utf-8 dans des spip
iso-latin, et inversement ? Et comment fais-tu si on ajoute des charsets ?
Je n'ai pas trouvé de solution autre que celle-ci.
Et comme tu dis, ça va faire foirer le moteur de recherche.
Pour ça, il suffit de reconvertir en charset local à la lecture.
D'autant que le charset XML est là pour indiquer au site destination
de faire la conversation. C'est idiot que ce soit le site source
qui s'y colle.
Tu proposes donc qu'un site ne soit syndicable que si son charset est connu?
Pour moi il est plus intelligent de faire le contraire: le site source doit
parler de manière intelligible, et il sera compris par tous.
Cela dit, on peut décider d'être impérialistes, et d'imposer isolatin comme
charset standard. Du coup, cela implique que la fonction sache convertir
utf8 en isolatin, puis progressivement windows-1252, etc., au fur et à
mesure qu'on ajoute des langues et que spip est utilisé pour autre chose que
des langues isolatines; cela implqiue aussi que spip, quand il lit un
backend, le passe dans son charset (n'y touche pas s'il est lui-même en
isolatin, et transforme en é s'il est dans un autre charset).
Bref, quel que soit le standard retenu ("isolatin + entités unicode pour le
reste" ou "entités-unicode 7bit"), on a besoin de cette fonction. Seul truc,
si on prend l'option "isolatin", on a la compatibilité avec l'existant, au
prix d'un peu de perte de "pureté". Si on négocie proprement la mention du
charset, ça devrait aller quand même...
Commentaires ?
( euh, quelqu'un a suivi jusqu'ici ? ;-] )
-- Fil
Pour ça, il suffit de reconvertir en charset local à la lecture.
Ca fait une grosse usine à gaz. Ca m'étonnerait que toutes les
conversions soient aussi simples que iso-latin -> unicode.
Tout ça alors que la plupart des sites ne vont syndiquer que des
sites de la même langue, donc du même charset.
Pour moi il est plus intelligent de faire le contraire: le site source doit
parler de manière intelligible, et il sera compris par tous.
Idéalement, "parler de manière intelligible", c'est utiliser un
jeu de caractères approprié et le spécifier dans l'en-tête XML.
Le jeu de caractères en question peut être UTF-8
On peut aussi faire deux backend, un backend.php3 normal et un
backend_international par exemple. La plupart des gens n'auront
utilité que du premier, et le deuxième peut avoir des échappements
spéciaux Ca permet d'éviter les mauvaises surprises.
Imagine quelqu'un qui fait un portail de sites à l'aide de backend
SPIP, et qui envoie une newsletter hebdomadaire : en balançant
tout d'un coup des entités numériques dans les backend SPIP, on
lui détruit son site. (bien sûr il peut ensuite programmer les
fonctions de conversion à la main...)
Idéalement, "parler de manière intelligible", c'est utiliser un
jeu de caractères approprié et le spécifier dans l'en-tête XML.
Le jeu de caractères en question peut être UTF-8On peut aussi faire deux backend, un backend.php3 normal et un
backend_international par exemple. La plupart des gens n'auront
utilité que du premier, et le deuxième peut avoir des échappements
spéciauxCa permet d'éviter les mauvaises surprises.
Imagine quelqu'un qui fait un portail de sites à l'aide de backend
SPIP, et qui envoie une newsletter hebdomadaire : en balançant
tout d'un coup des entités numériques dans les backend SPIP, on
lui détruit son site. (bien sûr il peut ensuite programmer les
fonctions de conversion à la main...)
Je suis d'accord avec une partie de l'argumentation. Mais a priori, si on
prend l'option "isolatin + le reste en entités", on ne casse rien dans
l'existant. Il faut donc passer le filtre que j'ai fait à la lecture du
backend, et si le charset local n'est pas isolatin. OK ?
(Si on ne fait rien, ça ne marchera pas, et si on fait deux backends bonjour
l'usine à gaz pour les utilisateurs.)
-- Fil
Je suis d'accord avec une partie de l'argumentation. Mais a priori, si on
prend l'option "isolatin + le reste en entités", on ne casse rien dans
l'existant. Il faut donc passer le filtre que j'ai fait à la lecture du
backend, et si le charset local n'est pas isolatin. OK ?
Je trouve ça plus propre sans entités (surtout que tu as ajouté
le meta charset précisément pour ne plus avoir d'entités...).
Enfin, si tu veux. Mais bon courage pour les conversions...
> Je suis d'accord avec une partie de l'argumentation. Mais a priori, si on
> prend l'option "isolatin + le reste en entités", on ne casse rien dans
> l'existant. Il faut donc passer le filtre que j'ai fait à la lecture du
> backend, et si le charset local n'est pas isolatin. OK ?Je trouve ça plus propre sans entités (surtout que tu as ajouté
le meta charset précisément pour ne plus avoir d'entités...).
Non, j'ai ajouté le meta charset partout pour que les pages s'affichent bien
dans le navigateur ; mais pour le backend le problème est différent.
Enfin, si tu veux. Mais bon courage pour les conversions...
Ouip
-- Fil
Merci pour la référence ! Je serais assez partant pour :
1) décoder dans le charset local de toutes façons.
2) éventuellement, encoder l'iso-8859-1 en entités (comme c'est dans le cvs
actuel)
3) de toutes façons encoder en &#nnn; tout ce qui n'est pas iso-latin.
J'envoie dans le cvs une fonction qui décode les &#nnn; en isolatin. Ca
répond à la moitié de la question.
@ Yves Pratter <ypr@alex.fr> :
Pour le charset du backend, je pense qu'il ne faut pas réinventer la roue :
il faut suivre les specs de RSS 1.0 :
RDF Site Summary (RSS) 1.0--
Encoding
While RSS 0.9 supported only ASCII encoding, RSS 1.0 assumes UTF-8.
Using US-ASCII (i.e. encoding all characters over 127 as &#nnnis
conformant with UTF-8 (and ISO-8859-1, HTTP's default header encoding).
--De plus l'utilisation de parseurs XML ne me semble pas un luxe.
Ces outils fonctionnent en interne en unicode et se chargent des
transformations courantes (utf-8, iso8859-1, ...) en entrée/sortie.
(pour de l'import, il existe la bibliothèque iconc - et sa version en ligne
de commande - qui convertit la plupart des jeux de caractères et qui
fonctionne bien sûr en interne en unicode.Enfin la version 4.1 de MySQL devrai supporter les tris avec unicode.
Peut-être que le portage multibase permettrait de contourner ce problème :
Firebird (alias interbase) et PostgreSQL supportent unicode. Peut-être
d'autres bases opensources le font aussi.
Firebird download | SourceForge.net
http://www.postgresql.org/idocs/index.php?multibyte.html
Là j'a pas suivi, mais si tu sais par quoi remplacer les deux fonctions
suivantes, n'hésite pas !!
// transforme une chaine en entites unicode 
// a completer pour d'autres charsets...
function entites_unicode($chaine) {
switch(lire_meta('charset')) {
case '':
case 'iso-8859-1':
while ($i = ord(substr($chaine,$p++)))
if ($i>127)
$s .= "&#$i;";
else
$s .= chr($i);
return $s;
default:
return $chaine;
}
}
// transforme les entites unicode  dans le charset courant
// (iso-8859-1 seulement pour l'instant) ; a completer pour d'autres charsets...
function unicode2charset($chaine) {
switch(lire_meta('charset')) {
case '':
case 'iso-8859-1':
while (ereg('&#([0-9]+);', $chaine, $regs) AND !$vu[$regs[1]]) {
$vu[$regs[1]] = true;
if ($regs[1] < 256)
$chaine = ereg_replace($regs[0], chr($regs[1]), $chaine);
}
break;
default:
break;
}
return $chaine;
}
-- Fil
Merci pour la référence ! Je serais assez partant pour :
1) décoder dans le charset local de toutes façons.
2) éventuellement, encoder l'iso-8859-1 en entités (comme c'est dans le cvs
actuel)3) de toutes façons encoder en &#nnn; tout ce qui n'est pas iso-latin.
J'envoie dans le cvs une fonction qui décode les &#nnn; en isolatin. Ca
répond à la moitié de la question.
Moui, la moitié la moins utile ;))))
Pour le cyrillique y a ça :
http://czyborra.com/charsets/cyrillic.html
> J'envoie dans le cvs une fonction qui décode les &#nnn; en isolatin. Ca
> répond à la moitié de la question.
En gros, si j'ai un spip sous le charset X (cyrilique, disons), que je veux
pouvoir syndiquer sous un spip isolatin. Je ne peux pas envoyer mes titres
tels quels, car les caractères 8 bits passeraient directement pour de
l'isolatin, et donneraient des â et des ö. Donc je dois utiliser un filtre
du type charset_to_unicode. Si on met ce filtre en standard dans les distrib
de spip, les backend standard seront bien formés, et pourront s'upgrader
avec la fonctoin charset_to_unicode().
Par contre, si dans mon spip X je tape un article titré en caractères
latins, ceux-ci seront stockés sous forme é => dans ma base isolatin,
il faut que je les remette en "natif". D'où la moulinette.
Je t'accorde que tout ça ne sert à rien à partir du moment où, dans les
faits, ces deux moulinettes ne connaissent que isolatin. Mais c'est un
framework.
Pour le cyrillique y a ça :
The Cyrillic Charset Soup
Rien compris
-- Fil