osCommerce France : Accueil Forum Portail osCommerce France Réponses aux questions Foire aux contributions

Bienvenue invité ( Connexion | Inscription )

 
Reply to this topicStart new topic
> oscommerce-*-FR-w3c-*-UTF-8, Déjà converti pour votre plaisir
cleo
posté 4 Jul 2009, 17:47
Message #1


Ceinture verte OSC
Icône de groupe

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, SPPLUS,Step By Step 1.8, Order Editor 2.6.3, Google Analytics, Dynamic Sitemap 2.0, OSC-Expeditor, Recover Cart Sales, Links Manager 1.15 + Ultimate SEO mod, PayBox3.0, PayBox Echéances, TVA Intracomm 5.1

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.
Go to the top of the page
 
Rik2009
posté 4 Jul 2009, 20:56
Message #2


Ceinture orange+ OSC
Icône de groupe

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
Go to the top of the page
 
cleo
posté 6 Jul 2009, 13:46
Message #3


Ceinture verte OSC
Icône de groupe

Groupe : Membres
Messages : 649
Inscrit : 13-September 05
Lieu : Paris
Membre no 7102



Citation (Rik2009 @ 4 Jul 2009, 22:56) *
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 :

  1. les caractères dans les fichiers, ex. fichiers de langues comme includes/languages/french/nouvellepage.php ou bien de nouvelles variables
  2. l'insértion des caractères dans la base de données et création de tables

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, SPPLUS,Step By Step 1.8, Order Editor 2.6.3, Google Analytics, Dynamic Sitemap 2.0, OSC-Expeditor, Recover Cart Sales, Links Manager 1.15 + Ultimate SEO mod, PayBox3.0, PayBox Echéances, TVA Intracomm 5.1

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.
Go to the top of the page
 
Gnidhal
posté 6 Jul 2009, 17:41
Message #4


5eme dan OSC
Icône de groupe

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)
Go to the top of the page
 
Rik2009
posté 6 Jul 2009, 19:07
Message #5


Ceinture orange+ OSC
Icône de groupe

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
Go to the top of the page
 
cleo
posté 6 Jul 2009, 20:43
Message #6


Ceinture verte OSC
Icône de groupe

Groupe : Membres
Messages : 649
Inscrit : 13-September 05
Lieu : Paris
Membre no 7102



Merci Gnidhal wub.gif en effet c'est ma première contribe.
Citation (Gnidhal @ 6 Jul 2009, 19:41) *
... 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, SPPLUS,Step By Step 1.8, Order Editor 2.6.3, Google Analytics, Dynamic Sitemap 2.0, OSC-Expeditor, Recover Cart Sales, Links Manager 1.15 + Ultimate SEO mod, PayBox3.0, PayBox Echéances, TVA Intracomm 5.1

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.
Go to the top of the page
 
nospam94
posté 31 Mar 2011, 06:47
Message #7


Ceinture jaune OSC
Icône de groupe

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
Go to the top of the page
 
brouillard
posté 3 Apr 2011, 10:07
Message #8


Ceinture orange+ OSC
Icône de groupe

Groupe : Membres
Messages : 301
Inscrit : 9-December 09
Membre no 26687



Citation (nospam94 @ 31 Mar 2011, 06:47) *
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.
Go to the top of the page
 
brouillard
posté 3 Apr 2011, 10:40
Message #9


Ceinture orange+ OSC
Icône de groupe

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 huh.gif

Alors que la longueur est de 2 : echo strlen('éé');

Ce message a été modifié par brouillard - 3 Apr 2011, 10:42.
Go to the top of the page
 
nospam94
posté 3 Apr 2011, 23:37
Message #10


Ceinture jaune OSC
Icône de groupe

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-cool.gif. 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-cool.gif 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 smile.gif

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 smile.gif

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
Go to the top of the page
 
nospam94
posté 6 Apr 2011, 23:32
Message #11


Ceinture jaune OSC
Icône de groupe

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
Go to the top of the page
 
equisol
posté 25 Aug 2014, 13:50
Message #12


Ceinture jaune+ OSC
Icône de groupe

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 smile.gif



--------------------
Goo69
Go to the top of the page
 
Bonbec
posté 26 Aug 2014, 14:27
Message #13


Ceinture marron OSC
Icône de groupe

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
Go to the top of the page
 
equisol
posté 27 Aug 2014, 19:57
Message #14


Ceinture jaune+ OSC
Icône de groupe

Groupe : Membres
Messages : 124
Inscrit : 7-November 07
Lieu : Lyon
Membre no 19668



Citation (Bonbec @ 26 Aug 2014, 14:27) *
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
Go to the top of the page
 
Bonbec
posté 27 Aug 2014, 22:34
Message #15


Ceinture marron OSC
Icône de groupe

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
Go to the top of the page
 
equisol
posté 28 Aug 2014, 08:07
Message #16


Ceinture jaune+ OSC
Icône de groupe

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
Go to the top of the page
 

Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



RSS 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)