UTF-8
Dernière modification : -
// 2007/08/01 09:26 / 64.208.49.61
// 2007/08/04 01:39 / 86.220.199.82
Depuis la version 2.20, TigerWiki fonctionne en UTF-8. Pour ma part mon système y était déjà.
Avant toute chose, lire cette vulgarisation des [concepts de base|http://www.haypocalc.com/wiki/D%C3%A9mystifier_Unicode] table de [translation|http://jeppesn.dk/utf-8.html]
Loin d'être un spécialiste en encodage de caractères, j'ai quand même relevé lors de mes tests quelques points qui peuvent poser problème AMHA.
!! Problèmes
* [htmlentities|http://www.php.net/manual/fr/function.htmlentities.php] qui est utilisé en début de formatage
Il faut lui préciser l'encodage des caractères en entrée. C'est donc dépendant du charset de la page.
Ce qui donnerait pour un système utf-8 (ligne 200 de la 2.21)
{{$CONTENT = htmlentities($CONTENT,ENT_COMPAT,"UTF-8");}}
* [html_entity_decode|http://www.php.net/manual/fr/function.html-entity-decode.php] en fin de formatage
Même punition que ci-dessus mais cette fois en fonction du charset que l'on veut présenter dans notre page (ligne 258 de la 2.21)
{{$CONTENT = html_entity_decode($CONTENT,ENT_COMPAT,"UTF-8");}}
'''Mais''' le support de l'utf-8 n'est présent qu'a partir de php 5 malheureusement loin d'être disponible partout :(
Du coup j'ai carrément commenté la ligne et cela ne semble pas poser de problème. Les caractères restent encodés en entités html (é).
* [utf8_encode|http://www.php.net/manual/fr/function.utf8-encode.php] utilisé pour convertir en utf-8 les pages saisies
Le problème de cette fonction est qu'elle converti de ISO-8859-1 en UTF-8.
Hors quand la page est déjà en UTF-8, le navigateur envoi (ou devrait) les données en UTF-8 les caractères sont alors doublement encodés.
Peut-être que [mb_convert_encoding|http://www.php.net/manual/fr/function.mb-convert-encoding.php] serait plus adaptée
* même chose pour [utf8_decode|http://us.php.net/manual/fr/function.utf8-decode.php]
* Quid de la variable de config $CHARSET ?
si elle n'est utilisée que pour l'en-tête html, cela va poser des problèmes pour par exemple un fichier utf-8 converti vers de l'iso-8859-1 (par utf8_decode) et présenté comme de l'utf-8
!! Propositions
Après quelques tests, voici mes propositions préliminaires. Comme je ne comprends pas encore très bien, il y a sans-doute des erreurs. L'idée principale est d'utiliser le module php ''mbstring''
Positionner l'ordre de détection ainsi pour gérer ces deux charsets :
{{mb_detect_order(array("UTF-8","ISO-8859-1"));}}
Pour l'Edit d'une page, détecter le charset de l'entrée et convertir en utf-8 avant d'enregistrer le fichier :
{{mb_convert_encoding($_POST['content'],"UTF-8",mb_detect_encoding($_POST['content']))}}
Pour l'affichage d'une page, lire le fichier (en utf-8 donc) et convertir vers le charset demandé ($CHARSET)
{{$CONTENT = mb_convert_encoding($CONTENT,$CHARSET,"UTF-8");}}
on peut même détecter le charset du fichier lu. cela devrait permettre de conserver des pages en ISO-8859
{{$CONTENT = mb_convert_encoding($CONTENT,$CHARSET,mb_detect_encoding($CONTENT));}}
Pour positionner la [surcharge de mbstring|http://www.php.net/manual/fr/ref.mbstring.php#mbstring.overload] on peut utiliser :
* mbstring.func_overload dans php.ini
* directement dans le code avec ''ini_set()''
!! Questions à creuser
* Quid des autres charsets que UTF-8 et ISO-8859-*
* Est-ce que les fonctions de traitement de chaines utilisées sont compatibles UTF-8
** ''mbstring'' propose des équivalents, mais est-ce que les besoins sont couverts --> à vérifier dans le code
** que dire des traitements par expression régulières ''preg_*'' --> semble compatible
* Quelle valeur utiliser pour mbstring.func_overload
!! Test
Pour essayer de comprendre un peu tout cela, j'ai fait un petit script qui utilise le module ''mbstring''.
Voir [test_charset|sources/?file=test_charset/index.php5]
Voir [test_charset|sources/?file=test_charset/index.php5]
TOC
// 2007/08/04 01:39 / 86.220.199.82
Depuis la version 2.20, TigerWiki fonctionne en UTF-8. Pour ma part mon système y était déjà.
Avant toute chose, lire cette vulgarisation des [concepts de base|http://www.haypocalc.com/wiki/D%C3%A9mystifier_Unicode] table de [translation|http://jeppesn.dk/utf-8.html]
Loin d'être un spécialiste en encodage de caractères, j'ai quand même relevé lors de mes tests quelques points qui peuvent poser problème AMHA.
!! Problèmes
* [htmlentities|http://www.php.net/manual/fr/function.htmlentities.php] qui est utilisé en début de formatage
Il faut lui préciser l'encodage des caractères en entrée. C'est donc dépendant du charset de la page.
Ce qui donnerait pour un système utf-8 (ligne 200 de la 2.21)
{{$CONTENT = htmlentities($CONTENT,ENT_COMPAT,"UTF-8");}}
* [html_entity_decode|http://www.php.net/manual/fr/function.html-entity-decode.php] en fin de formatage
Même punition que ci-dessus mais cette fois en fonction du charset que l'on veut présenter dans notre page (ligne 258 de la 2.21)
{{$CONTENT = html_entity_decode($CONTENT,ENT_COMPAT,"UTF-8");}}
'''Mais''' le support de l'utf-8 n'est présent qu'a partir de php 5 malheureusement loin d'être disponible partout :(
Du coup j'ai carrément commenté la ligne et cela ne semble pas poser de problème. Les caractères restent encodés en entités html (é).
* [utf8_encode|http://www.php.net/manual/fr/function.utf8-encode.php] utilisé pour convertir en utf-8 les pages saisies
Le problème de cette fonction est qu'elle converti de ISO-8859-1 en UTF-8.
Hors quand la page est déjà en UTF-8, le navigateur envoi (ou devrait) les données en UTF-8 les caractères sont alors doublement encodés.
Peut-être que [mb_convert_encoding|http://www.php.net/manual/fr/function.mb-convert-encoding.php] serait plus adaptée
* même chose pour [utf8_decode|http://us.php.net/manual/fr/function.utf8-decode.php]
* Quid de la variable de config $CHARSET ?
si elle n'est utilisée que pour l'en-tête html, cela va poser des problèmes pour par exemple un fichier utf-8 converti vers de l'iso-8859-1 (par utf8_decode) et présenté comme de l'utf-8
!! Propositions
Après quelques tests, voici mes propositions préliminaires. Comme je ne comprends pas encore très bien, il y a sans-doute des erreurs. L'idée principale est d'utiliser le module php ''mbstring''
Positionner l'ordre de détection ainsi pour gérer ces deux charsets :
{{mb_detect_order(array("UTF-8","ISO-8859-1"));}}
Pour l'Edit d'une page, détecter le charset de l'entrée et convertir en utf-8 avant d'enregistrer le fichier :
{{mb_convert_encoding($_POST['content'],"UTF-8",mb_detect_encoding($_POST['content']))}}
Pour l'affichage d'une page, lire le fichier (en utf-8 donc) et convertir vers le charset demandé ($CHARSET)
{{$CONTENT = mb_convert_encoding($CONTENT,$CHARSET,"UTF-8");}}
on peut même détecter le charset du fichier lu. cela devrait permettre de conserver des pages en ISO-8859
{{$CONTENT = mb_convert_encoding($CONTENT,$CHARSET,mb_detect_encoding($CONTENT));}}
Pour positionner la [surcharge de mbstring|http://www.php.net/manual/fr/ref.mbstring.php#mbstring.overload] on peut utiliser :
* mbstring.func_overload dans php.ini
* directement dans le code avec ''ini_set()''
!! Questions à creuser
* Quid des autres charsets que UTF-8 et ISO-8859-*
* Est-ce que les fonctions de traitement de chaines utilisées sont compatibles UTF-8
** ''mbstring'' propose des équivalents, mais est-ce que les besoins sont couverts --> à vérifier dans le code
** que dire des traitements par expression régulières ''preg_*'' --> semble compatible
* Quelle valeur utiliser pour mbstring.func_overload
!! Test
Pour essayer de comprendre un peu tout cela, j'ai fait un petit script qui utilise le module ''mbstring''.
Voir [test_charset|sources/?file=test_charset/index.php5]
Voir [test_charset|sources/?file=test_charset/index.php5]
TOC