FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 2015
-
16 avril 2007 à 13:34
Kdecherf
Messages postés96Date d'inscriptionmardi 9 janvier 2007StatutMembreDernière intervention18 avril 2007
-
24 juin 2008 à 00:07
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
Kdecherf
Messages postés96Date d'inscriptionmardi 9 janvier 2007StatutMembreDernière intervention18 avril 2007 24 juin 2008 à 00:07
Certes (PHP6) mais le passage ne sera pas pour demain ... ni après-demain.
De plus, je déconseille d'encoder les fichiers en UTF-8 BOM (UTF-8 avec signature) sinon vous allez avoir une belle surprise ;-)
verdy_p
Messages postés202Date d'inscriptionvendredi 27 janvier 2006StatutMembreDernière intervention29 janvier 2019 22 mai 2008 à 22:57
Attention, PHP va maintenant être en UTF-8 par défaut et ce ne sera plus configurable par une option. Le support des jeux 8 bits sur un octet est maintenant obsolète (le "Rubicon" est franchi), et ils ne seront plus supprotés que par des librairies optionnelles d'extensions non installées par défaut.
Il est grand temps de passer tous vos projets PHP à l'Unicode et oublier le pseudo jeu "ANSI" de Windows non portable (en fait une parmi plusieurs pages de code dont Windows-1252 uniquement en Europe occidentale et Amérique), et même l'ISO 8859-1 (insuffisant même pour le français)!
PHP ne fait que reprendre (enfin! c'était réclamé depuis près de 10 ans!) ce que font tous les autres moteurs de scripts pour client ou serveur (JSP, J#, C#, Javascript...) et toutes les normes et RFC actuelles.
djrobz
Messages postés4Date d'inscriptionsamedi 25 septembre 2004StatutMembreDernière intervention17 octobre 2007 18 avril 2007 à 13:42
Bonne idée !
Il m'est déjà arrivé ce genre de problème d'encodage lors d'un projet où il y a avait une base de données existante [destinée à un intranet] mais dont les données étaient encodées en UTF-16.
Le site et la nouvelle base résultante que je devais créer avaient pour contrainte technique d'être en UTF-8.
D'où les problèmes d'encodage que j'ai pu rencontrer!
Je pense que tu peux aller plus loin dans ta "Conversion universelle" des caractères, en modifiant ta fonction pour qu'elle soit compatible avec plus d'encodage au départ( voire tous! Pourquoi pas?), et pas uniquement les encodages de type ISO-8859-*
En ce moment, je n'ai pas trop le temps de me pencher sur la question mais peut-être la semaine prochaine je verais si il y a un moyen simple en partant ta source.
Kdecherf
Messages postés96Date d'inscriptionmardi 9 janvier 2007StatutMembreDernière intervention18 avril 2007 16 avril 2007 à 19:44
Merci pour l'optimisation :-P
Je la teste et je modifie la source ;-)
Et sinon, qu'est-ce que tu penses de la source ?
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 20153 16 avril 2007 à 13:34
<?php
// Version optimisée
function ConvertEntities($string, $quotes ENT_COMPAT, $slashesstriping TRUE, $nl2brshape = TRUE) {
if ( $slashesstriping )
$string = stripslashes($string);
// Contrôle le charset réel (UTF-8 -> ISO-8859-15)
$first = ( !preg_match('`é`i', mb_convert_encoding($string.'é', 'UTF-8', 'ISO-8859-15') ) ? 'UTF-8, ISO-8859-15' : 'ISO-8859-15, UTF-8';
// Teste s'il y a besoin d'une transformation (Optimisation)
if ( !mb_check_encoding($string,'ASCII') )
$string = htmlentities($string, $quotes, mb_detect_encoding($string,$first) );
// Convertit les \r\n
return ( $nl2brshape ) ? nl2br($string) : strtr($string,chr(10).chr(13),'');
24 juin 2008 à 00:07
De plus, je déconseille d'encoder les fichiers en UTF-8 BOM (UTF-8 avec signature) sinon vous allez avoir une belle surprise ;-)
22 mai 2008 à 22:57
Il est grand temps de passer tous vos projets PHP à l'Unicode et oublier le pseudo jeu "ANSI" de Windows non portable (en fait une parmi plusieurs pages de code dont Windows-1252 uniquement en Europe occidentale et Amérique), et même l'ISO 8859-1 (insuffisant même pour le français)!
PHP ne fait que reprendre (enfin! c'était réclamé depuis près de 10 ans!) ce que font tous les autres moteurs de scripts pour client ou serveur (JSP, J#, C#, Javascript...) et toutes les normes et RFC actuelles.
18 avril 2007 à 13:42
Il m'est déjà arrivé ce genre de problème d'encodage lors d'un projet où il y a avait une base de données existante [destinée à un intranet] mais dont les données étaient encodées en UTF-16.
Le site et la nouvelle base résultante que je devais créer avaient pour contrainte technique d'être en UTF-8.
D'où les problèmes d'encodage que j'ai pu rencontrer!
Je pense que tu peux aller plus loin dans ta "Conversion universelle" des caractères, en modifiant ta fonction pour qu'elle soit compatible avec plus d'encodage au départ( voire tous! Pourquoi pas?), et pas uniquement les encodages de type ISO-8859-*
En ce moment, je n'ai pas trop le temps de me pencher sur la question mais peut-être la semaine prochaine je verais si il y a un moyen simple en partant ta source.
16 avril 2007 à 19:44
Je la teste et je modifie la source ;-)
Et sinon, qu'est-ce que tu penses de la source ?
16 avril 2007 à 13:34
// Version optimisée
function ConvertEntities($string, $quotes ENT_COMPAT, $slashesstriping TRUE, $nl2brshape = TRUE) {
if ( $slashesstriping )
$string = stripslashes($string);
// Contrôle le charset réel (UTF-8 -> ISO-8859-15)
$first = ( !preg_match('`é`i', mb_convert_encoding($string.'é', 'UTF-8', 'ISO-8859-15') ) ? 'UTF-8, ISO-8859-15' : 'ISO-8859-15, UTF-8';
// Teste s'il y a besoin d'une transformation (Optimisation)
if ( !mb_check_encoding($string,'ASCII') )
$string = htmlentities($string, $quotes, mb_detect_encoding($string,$first) );
// Convertit les \r\n
return ( $nl2brshape ) ? nl2br($string) : strtr($string,chr(10).chr(13),'');
}
?>