oscommerce-*-FR-w3c-*-UTF-8, Déjà converti pour votre plaisir |
Bienvenue invité ( Connexion | Inscription )
oscommerce-*-FR-w3c-*-UTF-8, Déjà converti pour votre plaisir |
4 Jul 2009, 17:47
Message
#1
|
|
Ceinture verte OSC Groupe : Membres Messages : 649 Inscrit : 13-September 05 Lieu : Paris Membre no 7102 |
Bonjour,
Voici une version utf-8 de notre version française . (Actuallement osCommerce MS2 RC1 FR validée W3C v3, téléchargé le 2 juillet 2009. ) Les changements sont : 1. Tous les fichiers y inclus oscommerce.sql ont été passes par iconv en utf-8. 2. Le charset dans les fichiers langues a été mis à UTF-8. 3. Dans install/templates/main_page.php, le meta http-equiv charset est changé à UTF-8 4. La base de données exemple à importer (oscommerce.sql) après passage par iconv a en plus une nouvelle ligne Code SET NAMES utf8; Ses tables sont créées avec Code ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci 5. La fonction tep_db_connect() dans includes/functions/database.php et admin/includes/functions/database.php a une nouvelle ligne : Code mysql_query("SET NAMES 'UTF8'"); 6. Les biloutes ne se trouvent plus en Bretagne. c.f. Historique -------------------- ms2fr, Header Tags 2.5.5b, Order logging before payment, Better PayPal Description perso, Free shipping per product, Must agree to terms, Country State Selector, World Zones, Visible countries, Store Pick Up, plusieurs modules de livraison,Personal Invoice Number, 'On the Fly' Auto Thumbnailer using GD Library, More_Pics_6 for 2.2 ms2, Ultimate SEO URLs 2-2.1d/e (ouf maintenant il fait ce que je veux),Virement Bancaire, Estimated Shipping 1.5, xml_guide,
local : ubuntu 9.04 sur un netbook latitude 2100 remote : IcoOpenBSD 4.x, server : IcodiaSecureHttpd, MySQL 4.1.x, php : 5.2.8 You never get a second chance to make a first impression. |
|
4 Jul 2009, 20:56
Message
#2
|
|
Ceinture orange+ OSC Groupe : Membres Messages : 331 Inscrit : 3-March 09 Lieu : Paris Membre no 24686 |
Bonjour,
Alors voila je viens de commencer une nouvelle boutique en repartant de zéro, j'ai donc commencer à installer quelque contrib mais rien insurmontable à recommencer. Je sais très bien à quoi sert l'encodage UTF-8 et qu'elle sont c'est avantage mais une petite question trotte dans ma tête. Si je recommence tout avec la version en UTF-8 et que j'install une contrib qui elle n'est pas UTF-8 (et y en à énormément) est ce que je devrais seulement changer le charset ou d'autre chose en plus du charset dans le code de la contrib? Je vais donner un exemple mais je previens c'est dans le sens inverse: j'ai oscommerce rc1 en iso-8859-1 j'ai voulu installer la contrib one page checkout qui elle est en UTF-8 et donc quand j'arrive sur la page de checkout de la contrib les caractères avec des accens de mes boxes s'affiche avec des carré vu que le site est en iso-8859-1 et la contrib en UTF-8 j'ai donc essayé de changer UTF-8 par iso-8859-1 mais sa ne suffit pas il y à surement d'autre chose à convertir dans le code pour que tout devienne compatible. Donc est ce que j'aurrais le même soucis quand je serai en UTF-8 avec des contrib prévu en iso-8850-1 ? J'espère être assez clair. Ce message a été modifié par Rik2009 - 4 Jul 2009, 21:06. -------------------- osCommerce MS2 RC1FRW3C + Pacth RC2aFRW3C (pour mon nouveau site) pour l'autre osCommerce MS2 RC1FRW3C
|
|
6 Jul 2009, 13:46
Message
#3
|
|
Ceinture verte OSC Groupe : Membres Messages : 649 Inscrit : 13-September 05 Lieu : Paris Membre no 7102 |
Si je recommence tout avec la version en UTF-8 et que j'install une contrib qui elle n'est pas UTF-8 (et y en à énormément) est ce que je devrais seulement changer le charset ou d'autre chose en plus du charset dans le code de la contrib? Bonjour, Je ne suis pas experte mais je regarderais ces choses :
Le premier peut être converti avec iconv (*nix). Pour le deuxième, si c'est un import de fichier .sql, ce fichier peut être convertir également avec iconv et puis l'ajout de SET NAMES et spécifications pour une nouvelle table comme marqué ci-dessus doit faire l'affaire je pense. Par ailleurs il y a la suggestion de specifier le charset et collation pour chaque nouvelle variable de type caractère. Je ne l'ai pas ajouté pour chacune des dans le oscommerce.sql dans ma contribe le pensant rédondant avec set names mais je ne suis pas sûr pour toutes les installs de toutes les serveurs. Voir aussi : http://dev.mysql.com/doc/refman/5.0/en/cha...connection.html -c. Ce message a été modifié par cleo - 6 Jul 2009, 13:56. -------------------- ms2fr, Header Tags 2.5.5b, Order logging before payment, Better PayPal Description perso, Free shipping per product, Must agree to terms, Country State Selector, World Zones, Visible countries, Store Pick Up, plusieurs modules de livraison,Personal Invoice Number, 'On the Fly' Auto Thumbnailer using GD Library, More_Pics_6 for 2.2 ms2, Ultimate SEO URLs 2-2.1d/e (ouf maintenant il fait ce que je veux),Virement Bancaire, Estimated Shipping 1.5, xml_guide,
local : ubuntu 9.04 sur un netbook latitude 2100 remote : IcoOpenBSD 4.x, server : IcodiaSecureHttpd, MySQL 4.1.x, php : 5.2.8 You never get a second chance to make a first impression. |
|
6 Jul 2009, 17:41
Message
#4
|
|
5eme dan OSC Groupe : Administrateur Messages : 9221 Inscrit : 4-March 03 Lieu : Pau Membre no 927 |
Good job Cleo! Bravo!
bon je ne sais pas si c'est indispensable pour le français uniquement, mais le format UTF-8 sera indispensable pour du bilingue avec des caractères exotiques (japonais, cyrillique, thaï...) en ce qui concerne l'ajout de contributions, il suffit de veiller à ce que les nouveaux fichiers soient enregistrés en UTF-8 par ton éditeur de code et que les nouvelles tables soeint crées avec le bon charset. Sinon pour les modifs il n'y a en principe pas de problème. Pour info, il n'est pas nécessaire qu'un script soit en UTF-8 s'il n'a rien à afficher. Si son rôle est juste de calculer et qu'il ne manipule pas de chaines de caractères... il peut bien être en latin, ISO-8859-1 ou en windows-1250... ça marche sans problème. -------------------- Tout d'abord : - Ni Hotline ni Service Après Vente, ces forums sont un lieu d'échange. BIEN POSER SA QUESTION (généralités)
Les "Informations Importantes" que vous devez ABSOLUMENT avoir lues : Règlement, Bien poser sa question dans ces forums et Bien utiliser les Forums. Les raccourcis pour gagner du temps : la FAQ, les PDF de la Doc (MS2-fr): PDF-V1 et PDF-V2, le moteur de Recherche sur les forums , la Liste des Contributions de Corbin. ----------------------------- Quelques sites de référence --------------------------- PHP: Le site du Zéro et PHP Débutant avec la DOC en français -- HTML: Self HTML - WebProgrammation -- CSS: OpenWeb - AlsaCréations - CSS/Edge -- Autres ressources: - XajaX - highslide js Les bons outils : EasyPHP - WAMP-5 - - Notepad++ - Firefox et son extension WebDeveloper Le gène idéal c'est le gène original. Le génie des halles est un Génie des Alpages qui tente d'être à la page. (Merci f'murrr pour les cours de philosophie de chien) |
|
6 Jul 2009, 19:07
Message
#5
|
|
Ceinture orange+ OSC Groupe : Membres Messages : 331 Inscrit : 3-March 09 Lieu : Paris Membre no 24686 |
Merci à vous deux pour les détails
-------------------- osCommerce MS2 RC1FRW3C + Pacth RC2aFRW3C (pour mon nouveau site) pour l'autre osCommerce MS2 RC1FRW3C
|
|
6 Jul 2009, 20:43
Message
#6
|
|
Ceinture verte OSC Groupe : Membres Messages : 649 Inscrit : 13-September 05 Lieu : Paris Membre no 7102 |
Merci Gnidhal en effet c'est ma première contribe.
... mais le format UTF-8 sera indispensable pour du bilingue avec des caractères exotiques (japonais, cyrillique, thaï...) Oui c'était une demande d'un future client souhaitant une boutique japonais/français/anglais/allemand qui a provoqué ma recherche. Ce message a été modifié par cleo - 6 Jul 2009, 22:01. -------------------- ms2fr, Header Tags 2.5.5b, Order logging before payment, Better PayPal Description perso, Free shipping per product, Must agree to terms, Country State Selector, World Zones, Visible countries, Store Pick Up, plusieurs modules de livraison,Personal Invoice Number, 'On the Fly' Auto Thumbnailer using GD Library, More_Pics_6 for 2.2 ms2, Ultimate SEO URLs 2-2.1d/e (ouf maintenant il fait ce que je veux),Virement Bancaire, Estimated Shipping 1.5, xml_guide,
local : ubuntu 9.04 sur un netbook latitude 2100 remote : IcoOpenBSD 4.x, server : IcodiaSecureHttpd, MySQL 4.1.x, php : 5.2.8 You never get a second chance to make a first impression. |
|
31 Mar 2011, 06:47
Message
#7
|
|
Ceinture jaune OSC Groupe : Membres Messages : 67 Inscrit : 29-August 07 Lieu : 94550 Membre no 18841 |
L'initiative est bonne mais dangereuse. Le passage UTF8 est bcp plus complexe, enfin demande un peu plus de rigueur. Il faut remplacer toutes les fonctions string qui ne sont pas compatibles avec utf8 (toutes ou presque) exemple : trim, strlen.... par les fonctions compatibles (les mb_strings) ainsi que par l’écriture de clones non prévu dans la version php actuelle. Sans cela, votre os fonctionne en apparence mais en apparence seulement et il faut s'attendre à de nombreux bugs.
-------------------- NO_PUB
|
|
3 Apr 2011, 10:07
Message
#8
|
|
Ceinture orange+ OSC Groupe : Membres Messages : 301 Inscrit : 9-December 09 Membre no 26687 |
L'initiative est bonne mais dangereuse. Le passage UTF8 est bcp plus complexe, enfin demande un peu plus de rigueur. Il faut remplacer toutes les fonctions string qui ne sont pas compatibles avec utf8 (toutes ou presque) exemple : trim, strlen.... par les fonctions compatibles (les mb_strings) ainsi que par l'écriture de clones non prévu dans la version php actuelle. Sans cela, votre os fonctionne en apparence mais en apparence seulement et il faut s'attendre à de nombreux bugs. source : http://electron-libre.fassnet.net/utf8.php Citation Imaginons que l'on veuille connaître la longueur de cette chaîne : 'éé'. Basiquement un langage comptera le nombre de bits que contient cette chaîne. Une fonction dédié à cette tâche trouvera 16 bits, soit deux octets, soit deux caractères en ce qui concerne l'ISO. En revanche cette même fonction trouvera 32 bits sur un encodage UTF-8, donc renverra une valeur de 4 caractères si elle croit avoir affaire à de l'ISO...tel est le problème. Donc, pour coder en UTF-8, il faut que PHP & Co sachent à qui ils ont affaire ! Le test avant/après sera Code echo strlen ('éé');
Ce message a été modifié par brouillard - 3 Apr 2011, 10:17. |
|
3 Apr 2011, 10:40
Message
#9
|
|
Ceinture orange+ OSC Groupe : Membres Messages : 301 Inscrit : 9-December 09 Membre no 26687 |
Je viens de faire le test sur la V2.3 et ça me renvoi 4
Alors que la longueur est de 2 : echo strlen('éé'); Ce message a été modifié par brouillard - 3 Apr 2011, 10:42. |
|
3 Apr 2011, 23:37
Message
#10
|
|
Ceinture jaune OSC Groupe : Membres Messages : 67 Inscrit : 29-August 07 Lieu : 94550 Membre no 18841 |
je viens de terminer ma conversion utf-8, mon oscommerce était vraiment très fortement modifié. Impossible de repartir d'un truc tout fait.
J'en profite pour faire un retour d’expérience, ce qui pourra surement dépanner quelqu'un. Situation : PHP en version 5 n'est pas encore véritablement à l'aise avec l'utf8, ce n'est pas son encodage natif. Il semble que php 6 le sera. En attendant php 5 dispose de fonction permettant tout de même de dépatouiller le truc. Constat : Ça marche nickel et ça fait plaisir car cela va me simplifier la vie pour les développement futur. Pour le moment, je n'ai pas converti ma base et elle reste donc fidèle aux spécifications d'origine d'une MS2 avec bcp de tables en latin. Je finaliserai surement un jour mais ce n'est pas un problème puisque mysql dispose de mécanisme pour traduire les entrées sorties depuis et vers la base : Les directives comme mysql_query("SET CHARACTER SET 'utf8'", $$link);...... Code function tep_db_connect($server = DB_SERVER, $username = DB_SERVER_USERNAME, $password = DB_SERVER_PASSWORD, $database = DB_DATABASE, $link = 'db_link') { global $$link; if (USE_PCONNECT == 'true') { $$link = mysql_pconnect($server, $username, $password); } else { $$link = mysql_connect($server, $username, $password); } if ($$link) mysql_select_db($database); // // Set character set to UTF-8 // mysql_query("SET CHARACTER SET 'utf8'", $$link); mysql_query("SET NAMES utf8", $$link); mysql_query("SET CHARACTER_SET_CLIENT=utf8", $$link); mysql_query("SET CHARACTER_SET_RESULTS=utf8", $$link); return $$link; } Donc comme mes tables sont encore en partie iso, je demande a mysql de lire des données (iso, binaire, utf8 peu importe) et de me les renvoyer de l'utf-8. Dans l'autre sens, pour écrire, je donne à mysql des données utf-8, a lui de les convertir dans le format adéquat. Voila, c'est réglé pour les accès base de donnée. Il faut veiller bien-sur a ce que toutes les connexions a la base soit définies de la sorte. J'ai fait le choix de tout basculer en utf-8 donc la partie admin également. Il faudra donc modifier les fonctions de catalog/includes/database.php et de catalog/admin/includes/database.php. Ensuite, vous pouvez avoir des modules qui n'utilisent pas les connexions definies dans ces deux fichiers, c'est le cas par exemple de la contrib SEO Ultimate qui redéfini la connexion à la base dans le fichier seo.class.php (fonction ConnectDB()), dans ce cas il faudra egalement apporter les modifications mysql_query("SET CHARACTER SET 'utf8'", $$link);....... Astuce vitale : pour voir qui établi une connexion a la base, faite une recherche de "mysql_connect" ou "mysql_pconnect" et voyez s'il est opportun de modifier.... C'en est fini pour les accès BDD. Maintenant que la BDD recoit et envoi de l'utf-8, il faut s'assurer que la page qui en fait la demande soit en mesure d’interpréter l'utf-8. Pour cela, il suffit que cette page parle utf-8. Lorsque Oscommerce affiche une page (ex ma_page.php), elle est toujours rattachée à une langue (french ...). Le texte (les phrases pas le code) est enregistré dans le répertoire de la langue en cours. ex : catalog/includes/languages/french/le_texte_specifique_de_ma_page.php. Ainsi, quond on consulte ma_page.php, php inclus les textes de la langue depuis les fichiers catalog/includes/languages/french/le_texte_specifique_de_ma_page.php et catalog/includes/languages/french/french.php. le fichier catalog/includes/languages/french/french.php est un fichier global chargé pour toutes les pages, l'autre est le texte spécifique pour la page (parfois la page se contente du global). Si notre code est propre (c'est a dire qu'il n'y a pas de texte définit dans les fichiers de code, que tous les textes à afficher sont définis dans les fichiers langues), alors tous les fichiers code sont aussi bien iso que utf-8 car les caractères sont commun aux 2. (nos fichiers code devrait être propre mais bon ....). Si vous avez du texte dans vos codes alors il est nécessaire de convertir vos fichiers code au format utf-8 (sans BOM c'est très important sinon pb de header already sent) ou alors de rendre votre code propre (multilingue) en transférant les textes vers des fichiers langue. Code //dans le fichier code par exemple echo MON_TEXTE; //dans le fichier langue define(MON_TEXTE, 'ceci est le texte à afficher dans la langue sélectionnée'); Ensuite, pour le passage à utf-8, il faut convertir tous les fichiers de langues en utf-8. Il y a des outils pour cela genre iconv.exe mais cela peut être dangereux.... iconv vous demandera de définir l'encodage d'origine (iso8859-1 / iso8859-2...) et d'indiquer l'encodage souhaité (utf-. Le problème c'est que si un des fichiers était déjà en utf-8 alors le résultat sera catastrophique ... iconv ne vérifie pas de lui même l'encodage réel du fichier.... J'ai préféré la méthode pspad tout à la main (je suis sous windows et j'avais pas d'outils plus avancé....). En gros j'ouvre le fichier, je sélectionne le nouvel encodage (utf- et j'enregistre. J'en profite en passant pour virer les &eacut; î ... devenus disgracieux... (pas obligatoire) j'ai fait de même pour mes fichiers de code car je suis pas à l'abris d'avoir codé crade (texte dans code voila ! ma base talk utf-8, mes fichiers sources aussi. Maintenant, pour le fichier de sortie (la page affichée), il va falloir indiquer que le contenu est utf-8 ca se fait par ex avec <meta http-equiv="Content-type" content="text/html; charset=UTF-8"/> dans le code de chaque page, on a : Code <meta http-equiv="Content-Type" content="text/html; charset=<?php echo CHARSET; ?>" /> Autrement dit pour la page, l'encodage, le charset est défini par une "constante" CHARSET. cette constante trouve sa valeur dans le fichier langue global (ex french.php) il suffit donc pour parler utf-8 dans une page de définir le charset à utf-8 dans le fichier langue french.php Code @setlocale(LC_TIME, 'fr_FR.UTF8'); // warning ! not UTF-8 with dash '-' mb_internal_encoding("UTF-8"); //attention possible pb serveur windows multithread...effet de bord pour autres scripts // charset for web pages and emails define('CHARSET', 'utf-8'); dans le code ci dessus, on a modifié également @setlocale(LC_TIME....) et mb_internal_encoding("UTF-8") (j'y reviendrai par la suite) Donc maintenant normalement, nos pages parlent utf-8 car elles reçoivent du texte utf-8 et des valeurs de BDD en utf-8. En gros vous avez un système fonctionnel en apparence car vos textes accentués s'affichent correctement... Mais malheureusement, votre site ne "calcule" pas "utf-8"... il utilise de nombreuses fonctions de traitement de chaîne de caractère qui ne sont pas compatibles avec l'utf-8. comme indiqué par brouillard ci dessus, dans une page encodée utf-8, strlen('éé') renvoi 4 pas 2 ce qui est faux...donc votre site calcul n'importe quoi et il y a péril pour la validité des infos / commandes... PS : si vous êtes en utf-8 mais n'utilisez pas ou peu d'accents, les bugs seront rares voir absents.. en effet strlen('ee') renvoi bien 2 dans ce cas...mais je vois pas l’intérêt de passer en utf-8 si c'est pour pas mettre d'accent.... Il est donc nécessaire de remplacer tous les appels de fonctions qui sont non compatibles par des fonctions compatibles. La plupart des fonctions existent grâce a la bibliothèque mb_string. ainsi l’équivalent de strlen($string) pour utf-8 est mb_strlen($string,'utf-8'); comme on a indiqué dans french : Code mb_internal_encoding("UTF-8"); on ne sera pas obligé de préciser a chaque fois l'encodage 'utf-8';on pourra donc remplacer strlen($string) par mb_strlen($string); on fera de même avec strpos -> mb_strpos, substr -> mb_substr ....... bref pas mal de code à corriger.... et a analyser / comprendre pour être certain de faire bien ... Pour le coup, c'est un travail de titan si cela doit être fait "à la main", en lisant chaque fichier.. j'ai essayé avec psad de faire du search / replace en volume mais on ne peut faire d'expression régulière donc trop restreint et trop dangereux... en effet je peux lui dire trouve tous les strlen et remplace par mb_strlen mais si j'avais déjà des mb_strlen (d'une contrib plus moderne) alors ils deviennent mb_mb_strlen.... j'ai cherché l'outils et j'ai trouvé TextCrawler..... très bien, gratuit et super efficace (et fiable) j'ai donc fait des search / replace avec expression régulière ex : (mb_|)strstr(\(| \() pour le search et mb_strstr( pour remplace. et ainsi de suite avec les fonctions strpos, substr.... je conseille d'activer l'option sauvegarde du fichier d'origine en .bak (copie secours) et de tester le site entre 2 salves de modification (tester profondément), de bien vérifier avant de cliquer sur replace que la chaîne cherchée et la chaîne à écrire sont correctes (et sensées). Moi je fais d'abord un find, je regarde rapidement les lignes à modifier (toutes) et je lance le replace. a l'issue, le code est quasi 100% fonctionnel avec la conversion de ces fonctions de base. pour les autres, il faut traiter au cas par cas, cela dépend de votre code (contrib / développement perso). voilà pour les grandes lignes. Le plus long pour moi a été de comprendre ce p*tain d'utf-8 et tous les pièges qui en découlaient mais ça forme dit on... J'oubliai, il existe les fonctions utf8_encode et utf8_decode pour convertir une chaîne en iso vers du utf-8 et vice versa. Ça peut sembler pratique mais si on en a besoin, c'est qu'il y a un problème de conception à mon avis... ou alors cas très particulier. Au départ je pensais résoudre le truc avec ces 2 fonctions...a condition de connaitre parfaitement l'encodage du $string encodé/décodé, je déconseille l'utilisation à outrance de celles ci.....la solution est ailleurs. Pour ma part, tout est fonctionnel, j'utilise SEO ULTIMATE, j'autorise les accents même dans les url de redirection / rewriting, les champs de recherche, je génère du pdf et du xls et pourtant j'utilise 0 fois utf8_encode et 2 fois utf8_decode pour le cas très particulier où l'encodage utf-8 des accents url_encodés est différent de l'encodage utf-8 coté code source...: différence de codification d'un é utf8_encodé (%C3%A9) et un é url_encodé (%E9) J'oubliai, faites des sauvegardes.... Conclusion : ca m'a permis de nettoyer mon code, de retirer certaines verrues / pseudo hack trouvés par ci par là pour corriger certains bugs (seo par exemple) donc je me sent plus serein, fatigué mais plus serein pour la suite voir topic http://www.oscommerce-fr.info/forum/index....showtopic=48245 par exemple pour seo et utf-8 Ce message a été modifié par nospam94 - 3 Apr 2011, 23:47. -------------------- NO_PUB
|
|
6 Apr 2011, 23:32
Message
#11
|
|
Ceinture jaune OSC Groupe : Membres Messages : 67 Inscrit : 29-August 07 Lieu : 94550 Membre no 18841 |
Attention, dans le cas d'une conversion en utf-8, il ne faut pas modifier la classe mime.php. les fonctions strlen, substr et preg_split doivent rester en l’état, pas devenir mb_strlen, mb_substr ou preg_split avec commutateur u.... sinon plus moyen de recevoir un mail des accents..... j'en ai fait les frais...
-------------------- NO_PUB
|
|
25 Aug 2014, 13:50
Message
#12
|
|
Ceinture jaune+ OSC Groupe : Membres Messages : 124 Inscrit : 7-November 07 Lieu : Lyon Membre no 19668 |
Bonjour,
Je suis en train de basculer ma MS2.2 en UTF-8 en suivant tous les conseils précédents (un GRAND MERCI pour tous ces détails !!!) : -> modification de languages/french.php -> conversion de tous les fichiers en utf-8 (un par un) -> modification de la balise meta du <head> -> remplacement des fonctions non compatibles utf-8 (strlen, strpos, substr et trim en insérant dans l'application_top.php la librairie mbfunctions dont parle ce topic A cet instant, Code echo strlen('éé'); me renvoie 2, et ça ca fait plaisir !Cependant, bien que la BDD ait été passée en UTF-8 en faisant les modifications suivantes : -> SET NAMES utf8 -> CHARSET=utf8 -> COLLATE utf8_unicode_ci il subsiste encore des caractères accentués non convertis (qui affiche �) pour des chaînes de caractères provenant de la BDD. Voici à quoi ressemble la BDD pour la partie qui nous intéresse : Code -- -- Structure de la table `topics_description` -- CREATE TABLE IF NOT EXISTS `topics_description` ( `topics_id` int(11) NOT NULL DEFAULT '0', `language_id` int(11) NOT NULL DEFAULT '1', `topics_name` varchar(64) NOT NULL, PRIMARY KEY (`topics_id`,`language_id`), KEY `idx_topics_name` (`topics_name`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; -- -- Contenu de la table `topics_description` -- INSERT INTO `topics_description` (`topics_id`, `language_id`, `topics_name`) VALUES (1, 1, 'Accueil'), (10, 1, 'Contact'), (9, 1, 'La boîte à souvenirs'), (3, 1, 'La nature'), (2, 1, 'Le village'), (4, 1, 'Les acteurs'), (8, 1, 'Les hébergements'), (6, 1, 'Les loisirs'), (5, 1, 'Les produits'), (7, 1, 'Les randonnées'), (11, 1, 'Mentions légales et crédits'); et côté html, le résultat de la requête (pour les chaînes accentuées) : Les randonn�es, Les h�bergements, La bo�te � souvenirs. Auriez-vous un ultime conseil pour se débarrasser de ces fichus caractères ? Merci pour votre aide -------------------- Goo69
|
|
26 Aug 2014, 14:27
Message
#13
|
|
Ceinture marron OSC Groupe : Modérateurs Messages : 1543 Inscrit : 30-May 06 Lieu : Vichy (03) Membre no 10583 |
Bonjour,
As-tu pensé à sauvegarder toutes tes pages en UTF8 SANS BOM ? -------------------- Config 1 en live : Osc 2.2 très fortement modifié ... UTF-8 et Php 5.4.
Contribs installées : down_for_maintenance_v 2.3 | Estimated Shipping v1.5 | imprint_1_3_5 | low_stock_report_v2.04 | visible_countries_1.2b | Products Tabs | shoppingCart_cleanup_v1.01.0 | + trop de bidouilles persos pas très OsCommerce (erreurs de jeunesse) Config 2 en local avec UwAmp : Osc Phoenix |
|
27 Aug 2014, 19:57
Message
#14
|
|
Ceinture jaune+ OSC Groupe : Membres Messages : 124 Inscrit : 7-November 07 Lieu : Lyon Membre no 19668 |
As-tu pensé à sauvegarder toutes tes pages en UTF8 SANS BOM ? Pour être sûr de ne pas avoir fait d'impaire, j'ai repris ce jour tous les fichiers avec Notepad et confirme que toutes les pages ont été converties. Question : la fonction tep_date_long pose des problèmes d'affichage sur les mois accentués. Où trouve t-on les mois en français ?? Merci !! -------------------- Goo69
|
|
27 Aug 2014, 22:34
Message
#15
|
|
Ceinture marron OSC Groupe : Modérateurs Messages : 1543 Inscrit : 30-May 06 Lieu : Vichy (03) Membre no 10583 |
Re,
Pour ta première question pour la lecture de ta BDD en UTF8, as-tu bien pensé à ajouter mysql_set_charset('utf8', $$link); dans ta fonction function tep_db_connect qui se trouve dans les 2 fichiers includes/functions/database.php et admin/includes/functions/database.php ? Code function tep_db_connect($server = DB_SERVER, $username = DB_SERVER_USERNAME, $password = DB_SERVER_PASSWORD, $database = DB_DATABASE, $link = 'db_link') { global $$link; if (USE_PCONNECT == 'true') { $$link = mysql_pconnect($server, $username, $password); mysql_set_charset('utf8', $$link); } else { $$link = mysql_connect($server, $username, $password); mysql_set_charset('utf8', $$link); } if ($$link) mysql_select_db($database); return $$link; } Pour ta 2ème question concernant les mois accentués, je n'ai pas réussi à modifier la fonction tep_date_long avec utf8_encode directement dans la fonction, aussi je place cette formule magique dans les ficheirs faisant appel à cette fonction tep_date_long comme ceci par exemple : Code ... utf8_encode(tep_date_long($latest_news['date_added'])) ... -------------------- Config 1 en live : Osc 2.2 très fortement modifié ... UTF-8 et Php 5.4.
Contribs installées : down_for_maintenance_v 2.3 | Estimated Shipping v1.5 | imprint_1_3_5 | low_stock_report_v2.04 | visible_countries_1.2b | Products Tabs | shoppingCart_cleanup_v1.01.0 | + trop de bidouilles persos pas très OsCommerce (erreurs de jeunesse) Config 2 en local avec UwAmp : Osc Phoenix |
|
28 Aug 2014, 08:07
Message
#16
|
|
Ceinture jaune+ OSC Groupe : Membres Messages : 124 Inscrit : 7-November 07 Lieu : Lyon Membre no 19668 |
BIG UP Bonbec !!
Un grand merci !! Tes réponses ont résolu tous les problèmes restants. Je n'avais pas vu le sujet qui aborde le complément de la fonction mysql_set_charset. Nickel également le complément utf8_encode de la fonction tep_long_date ! Concernant la BDD, 2 requêtes permettent de voir si elle est bien convertie : lancer SHOW VARIABLES LIKE 'character_set%'; et vérifier que le résultat donne ça : +--------------------------+---------------------------------+ | Variable_name | Value | +--------------------------+---------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/local/mysql/share/charsets/| +--------------------------+---------------------------------+ idem pour SHOW VARIABLES LIKE 'collation%'; De mon côté, sujet résolu ! Toutes les réponses étaient présentent dans le forum en fin de compte... Merci à tous les membres donc ^^ -------------------- Goo69
|
|
Version bas débit | Nous sommes le : 28th March 2024 - 11:45 |
Ce site est déclaré auprès de la commision Nationale de l'Informatique et des Libertés (déclaration n°: 1043896) |