CONVERSION UNIVERSELLE DE CARACTÈRES

FhX Messages postés 2350 Date d'inscription mercredi 13 octobre 2004 Statut Membre Dernière intervention 18 avril 2015 - 16 avril 2007 à 13:34
Kdecherf Messages postés 96 Date d'inscription mardi 9 janvier 2007 Statut Membre Dernière intervention 18 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.

https://codes-sources.commentcamarche.net/source/42236-conversion-universelle-de-caracteres

Kdecherf Messages postés 96 Date d'inscription mardi 9 janvier 2007 Statut Membre Dernière intervention 18 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és 202 Date d'inscription vendredi 27 janvier 2006 Statut Membre Dernière intervention 29 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és 4 Date d'inscription samedi 25 septembre 2004 Statut Membre Dernière intervention 17 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és 96 Date d'inscription mardi 9 janvier 2007 Statut Membre Dernière intervention 18 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és 2350 Date d'inscription mercredi 13 octobre 2004 Statut Membre Dernière intervention 18 avril 2015 3
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),'');

}
?>
Rejoignez-nous