Problème format UTF-8 vs ISO-8859-1 Options

[polo]

Bonjour à tous,
Tous le monde dit que l'utf8 est plus pro, ok je veux bien le croire mais j'ai un peux de mal à mettre cela en conformité avec ma base de données, en fait si j'ai bien compris si ont opte pour TOUT UTF8, nous somme obligé de convertir nous même les symbole, par exemple un é = é (en iso html) etc....

voir ce site:

http://www.phpsources.org/caracteres-iso.htm

Hors si je met en iso-8859-1, sur ma base de données, j'appel un chat un chat , é = é etc... ce qui pour moi est bien plus simple, plus besoin de convertir en iso html...

Je met ce ci dans french.php et je convertit mes fichiers php en iso-8859-1 Latin 1

Code

define('CHARSET', 'iso-8859-1');

J'entend dire que UTF8, c'est mieux mais à en croire mon expérience, c'est pas évident.... ensuite c'est vrai que tous le monde n'est pas obligé de faire des import CSV.

De plus , le moteur de recherche ne fonctionnais plus correctement avec ces fameux caractères en iso html, j'ai donc mis mon ficheirs CSV en conformité (j'ai viré iso html), et le moteur trouve les produits intégrant des "é", "à".
Je me suis planté quelques part ??? si vous avez une idée pour garder l'UTF8 sans avoir besoin de convertir à chaque fois, je suis preneur..

@+

[Gnidhal]

Avec UTF-8 tu n'a pas besoin de coder tes caractères en HTML!
Il existe toute une littérature en ligne à propos des normes de codages de caractères :
ASCII 127 caractères donc pas d'accent, les accents doivent être en entité html
ISO-8859, 255 caractères donc 191 lettres codables restreint par langue, ça va pour la France mais même pas tout à fait. 8859-1 n'a pas l'euro € et d'autres caractères comme ceux qui font l'objet de ce post
La norme 8859-15 a tenté de remédier à cela, mais elle n'est pas reconnu pour les BDD qui ne connaissent que Latin et ça n'avance pas à grand chose

UTF-8 codé sur 2, 3 ou 4 octets n'a plus de limites car sur 4 octets on a plus de 4 milliards de caractères possibles.
et même en version de base à 2 octets les 65536 caractères donnent bien assez de possibilités pour nous les occidentaux toutes langues confondues et je crois même que les alphabets comme le cyrillique, l’hébreu, l'arabe et le mandarin pourraient s'en contenter

Mais UTF-8 a un impératif : c'est que TOUT ton site soit en UTF-8! du format des scripts en passant par la bdd et le charset déclaré dans la page.
Alors souvent on déclare sa BDD et le charset de page mais on oublie le format des scripts donc on a des accents qui passent et d'autres pas.
Alors revois les références en ligne sur les codage de caractères et jette tes entités html &Machin;

[polo]

Oui c'est ce que j'essai de faire, mais je dois me planter sur quelques chose, je pense avoir tout essayé:

1/ Déjà ma boutique fraichement installé (OSC2.1.3) est en UTF8 (du moin les fichiers, script sauvé en "Unicode 5.1 UTF-8" sous Dream Weaver..), c'est le réglage par default.

2/ Dans le french.php j'ai mis ceci:

Code

define('CHARSET', 'utf-8');

3/ J'ai mis ma base, du moin ma TABLE product_name (pour faire mes test) en interclassment "UTF8-Swedish_ci"

4/ J'ai fait un export CSV "Tableau Open Office" d'une autre boutique (qui elle, en est Latin 1) mais j'ai remis tous en CSV "UTF8" dans l'application "Open Office", pour l'importation sur la nouvelle boutique (sans entité HTML pour les accents), le fichier CSV à été sauvé en Unicode UTF-8.

5/ Dans l'admin categorie.php est en UTF8, french.php aussi.. j'ai même forcé la main avec 2 .haccess dans /admin et /catalog avec la ligne:

Code

AddDefaultCharset UTF-8

RESULTAT: Les accents sont remplacé par des symboles du genre : ���

J'ai sans doute oublié quelque chose, si tu as une idée, je suis preneur.

PS: sur le point 3, peut être aurais-je du mettre en UTF-8 unicode pour la BDD ?

[Gnidhal]

d'après ce que tu dis, tu utilises un import/export depuis csv vers ta bdd,
comment procèdes-tu ?
Si tu utilises EasyPopulate, ce script est-il en utf8 et ne procède-t-il pas à une conversion de caractères ?
Pourquoi n'élimines-tu pas cet intermédiaire en passant directement par un fichier sql généré par phpmyadmin ?

[polo]

Mon importation/export ce fait justement via phpmyadmin, en réglant l'importation en utf-8.

Donc pour toi cela devrais focntionner ? ou pas ? est ce que le BOM ? as une influence ?

Ce message a été modifié par polo - 2 Feb 2012, 22:06.

[Gnidhal]

Oui le BOM peut avoir une influence et rendre le fichier illisible par phpmyadmin. D'ailleurs DreamWeaver enregistre par défaut les fichier avec le BOM, ce qui rend par exemple un script php illisible sauf par un éditeur de texte.
En effet, la séquence <?php qui est censée débuter le fichier est précédée d'un code UTF qui précise le type de format...
En principe dans phpmyadmin tu n'as pas d'autre chose à faire que d'exporter en sql format de fichier utf8 et ré-importer de l'autre coté ce même fichier dans ta table en ne prenant que les données.
Si tu prends la structure la collation des tables va se trouvé réinjectée comme dans l'original.
La manipulation de ton fichier par un outil de traitement de texte comme OpenOffice peut créer des perturbations de format.
Si tu veux faire des modifs utilise plutôt le format sql que tu ouvres dans un éditeur de texte comme Notepad++ ou PsPad qui savent gérer le format de fichier en UTF.
Je n'ai pas d'autre solution que de faire des essais mais en éliminant le plus possible d'intermédiaires.

[polo]

Pour le BOM, c'est une option à cocher, d'ailleur si je la coche le fichiers est illisible par le navigateur, j'ai donc laissé "décoché"

Si je pouvais faire de l'import SQL, je l'aurais fait (même si la base sql fait plus de 8 mo), mais le problème, c'est que les 2 sites sont trop différnet, pas le même nombre de colonne dans les tables (osc2.2 -> OSC 2.1.3)

Donc , si j'ai bien compris il n'y à pas vraiement de solution simple et efficace.

[polo]

Comme tu semble me dire que c'est l'importation SQL qui fait tout, si je m'amuse à vider la table en question, une fois vidé je l'exporte en SQL, je la supprime et la réimporte en SQL UTF8, ensuite j'applique les données via mon fichier CSV, cela pourrait focntionner ??

Je pense pas mais bon, je vais essayer.

15 minure plus tard.... j'ai donc vidé la table, en mettant tout en utf8 unicode_ci, enfin juste ma table "product description", tous semble niquel dans l'admin, si je modifie un produit avec des é, il s'enregistre bien "é" dans la base... et l'admin affiche correctement les "é" en "é".

Par contre , coté front office, j'ai toujours les "é" en "�"... je sais pas pourquoi, seul le front office bug.

Après 30 minutes de recherche, je décide de remplacer "nl2br" par "htmlentities" pour product_name
J'ai donc remplacer ceci:

Code

$nom = nl2br($product_info['products_name']);

par

Code

$nom = htmlentities($product_info['products_name']);

htmlentities = Convertit tous les caractères éligibles en entités HTML, il faut donc utiliser htmlentities pour supprimer les entité httml, pourtant, dans le titre, c'est juste du texte. .. à l'inverse de product_description, qui lui dois posseder des entité html, car j'edite les descriptifs avec l'editeur CKeditor.

Ce message a été modifié par polo - 3 Feb 2012, 01:04.

[Gnidhal]

Si c'est bon en admin mais pas en boutique c'est que tu as un problème de script et pas de bdd.
Donc l'un de tes scripts est encore enregistré en ISO dans les pages de la boutique.
Si tu fais un htmlentities sur le titre (nom du propduit) et que tes accents s'affichent bien, c'est que ta page products_info est codée en ISO ou que le charset de page n'est pas défini correctement
Par ailleurs, si tu fais un html_entities, seul l'affichage est modifié à la volé, donc les données en bdd sont sans entité html :
un é est un é dans le champ de la base.
Concernant fck_editor tu as la possibilité de lui dire d'enregistrer les données avec les entité html ou directement en accentués, regarde la config de ck_editor et les posts sur ce sujet :
http://www.oscommerce-fr.info/forum/index....st&p=356443
http://www.oscommerce-fr.info/forum/index....st&p=342300
http://www.oscommerce-fr.info/forum/index....st&p=360694
http://www.oscommerce-fr.info/forum/index....st&p=344145

[polo]

Bon, la j'y comprend plus rien la, je pensais que dans l'admin que c'était ok, apparemment non, si je modifie un titre directement sur le backoffice, genre "pince à crabe", dans la table il s'enregistre "pince à crabe" dans le backoffice cela s'affiche "pince à crabe", si je vais dans phpmy admin pour modifier en direct et remettre "pince à crabe", dans le backoffice , j'ai "pince � crabe".

Je comprend pas pourquoi il y autant de différence, entre le backoffice, phpmyadmin...

Dans phpmyadmin, l'interclasement est "utf8_unicode_ci" pourtant, de plus il n'est plus question d'import / export CSV, car j'enregistre durectement de phpmyadmin ou de mon backoffice..

Alors c'est un soucis de BDD, je suppose. ? non ? tout est en interclassement "utf8_unicode_ci", du moin ma table "product_description" et les colonnes à l'intérieur.

Ce message a été modifié par polo - 3 Feb 2012, 10:47.

[Gnidhal]

Tes scripts ne sont pas utf8 !

[polo]

Oui car si j'affiche le code de ma page product_info.php, j'ai dans le code source ceci:

Code

<meta http-equiv="Content-Language" content="text/html; charset=iso-8859-1" />

Pourtant mon fichier product_info.php, french/product_info.php et french.php est en UTF8, je sais pas quel autre fichiers pourrait venir perturber cette page.

[polo]

Bon, j'ai trouvé j'avais dans template_top un :

Code

<meta http-equiv="Content-Language" content="text/html; charset=iso-8859-1" />

Maintenant ma page boutique est en UTF8, je vais refaire mes tests avec l'admin.


Dans l'admin ma page est bien codé UTF8 (du moin catégorie), le code source me donne ceci:

Code

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

MAis quand j'écrit un "à" dans le backoffice, l'enregistrement dans la base est "Ã", je pense que c'est au moment de l'enregistrement... directement dans la requetes SQL.... enfin je ne voi pas d'autre explications.

Ce message a été modifié par polo - 3 Feb 2012, 11:43.

[Gnidhal]

Ok et tes scripts de fonctions qui ont la charge d'écrire dans la bdd sont utf8 aussi ?

[polo]

Les pages du genre:

includes/function/html_output.php
includes/function/general.php

??

Je vois pas très bien ce que j'aurais pu changer dans ces pages, en tous les cas, elles sont sauvé en UTF8.

Je vais voir mon fichier categorie.php pour voir si elle n'appele pas un script mal codé ...

PS: Bon j'ai vérifié l'encodage des pages de phpmyadmin, ont sais jamais, c'est bien du UTF8, c'est à l'enregistrement que çà bug.

Ce message a été modifié par polo - 3 Feb 2012, 13:47.

[Gnidhal]

includes/functions/database.php ?

[polo]

J'ai revu tous mes fichiers , j'ai tous en UTF-8 .


pour le database.php aussi, pour le contenu de ce fichiers, je sais pas si je dois modifier quelques chose. ?

J'avais trouvé ceci:

http://www.oscommerce.com/community/contri...ch,utf-8+encode

ICI

*** On line ~16, find ***

Code

if (USE_PCONNECT == 'true') {
      $$link = mysql_pconnect($server, $username, $password);
    } else {
      $$link = mysql_connect($server, $username, $password);
    }

*** After that, add ***

Code

    
  // BOF: [TiM's osC Solutions] ISO-8859-1/UTF-8 dual support
    switch (strtolower(CHARSET)) {
      case 'utf-8':
        mysql_query("set character set utf-8", $$link);
        break;
      case 'iso-8859-1':
        mysql_query("set character set latin1", $$link);
        break;
    }
  // EOF: [TiM's osC Solutions] ISO-8859-1/UTF-8 dual support

Mais çà ne résoud rien.... je vais essayer, de réinstaller une OSC 2.1.3 d'origine pour voir comment s'effectue les enregistrements, si çà tombe , c'est normal ??

Ce message a été modifié par polo - 4 Feb 2012, 02:19.

[Gnidhal]

Je ne peux guère t'aider d'avantage sur ce coup.
La méthode est là : utf-8 de bout en bout
Reste à voir ta config et comment sont configurés les scripts de base phpmyadmin
La dernière fois que j'ai galéré là dessus c'était à cause d'un format de script.
La récup des données en bdd est assez lourde car elles sont codées 2 fois : 1 fois par le script en écriture, une fois par le script en lecture. Donc on s'y perd un peu.
La méthode radicale que j'ai utilisé (car j'en avais marre de chercher) était de récupérer les données en sql, dans lesquels on trouvait des caractères mal encodés puis de faire un recherche/remplace avec un éditeur de texte. Pas très orthodoxe, mais efficace si tu prends soin que ton éditeur de texte enregistre dans le bon format.
Perso je ne connais pas DreamWeaver et j'utilise des outils freeware (psPad et Notepad++) plus spartiates mais aussi plus cohérents avec ce type de fonctions.

[polo]

Oui, moi aussi je galère, je cherche mais ne trouve pas de solution, la seul solution "propre" est d'utiliser tous en ISO 8859-1 mais la j'aurais peut être des soucis avec les pages en anglais etc...

Sinon, je fais comme toi, je fais des recherches et remplacer mais dans OpenOffice et donc en CSV, pas en prenant la base SQL, cela fonctionne très bien, il faut juste faire attention à prendre les bon separateur, il faut que je me renseigne pour les enregistrements, savoir si sur une boutique de base enregistres en UTF8.

Si je laisse en l'état, donc en UTF8, il faut que je code mes "é" en "é", pas très classe mais bon, pas le choix.

Je ne pense pas que ce soit PHPmyadmin mais le backoffice.

J'ai installé PSPAD sur mon mac, pour voir ce que çà donne.. çà pourrait m'aider, en même temps j'ai "Text Edit" qui fait la même chose.

Ce message a été modifié par polo - 5 Feb 2012, 00:31.

[polo]

Tiens je viens de tester la supression des entité html sur CKeditor avec :

Code

config.entities = false;

çà fonctionne, est c'est quand même plus propre (en mode source ou non, mon "é" reste un "é" mais je suis confronté au même problème, "néon" deviens "Néon" sous phpmyadmin.

J'ai donc ajouté ce code dans database.php juste àprès la requete SQL:

Code

mysql_query("SET NAMES 'utf8'");

Depuis, dans le backoffice , quand je reviens sur la fiche produit, j'ai un joli "Néons"

Ce message a été modifié par polo - 5 Feb 2012, 01:51.

[Gnidhal]

Non, iso ne pose pas de problème avec les textes anglais qui n'ont pas d'accent ! d'ailleurs l'anglais se contente très bien du ASCII de base avec seulement 127 caractère
La seule limite génante de ISO-8859-1 ou -15 c'est qu'il faut changer de code de page selon la langue : entre le suédois et l'espagnol en passant par l'allemand le codage est différent du français (les caractères spéciaux dépassent largement les 191 dispos toutes langues confondues). UTF-8 évite cela et permet même d'ajouter l'arabe ou l'hébreu sans devoir changer de charset. Un sacré confort pour les sites multilangue.
Mais si tu as juste français/anglais l'ISO va très bien.

[polo]

Salut Gnidhal !


Je pense avoir résolu mon soucis d'enregistrement dans la base sql, il faut ajouter ce code !!!

Code

mysql_query("SET NAMES 'utf8'");

du coup j'ai l'enregistrement qui est en conformité avec ce que j'affiche dans le backoffice cela pourra peut être te servir.

Ce message a été modifié par polo - 5 Feb 2012, 13:21.

[polo]

Salut!

Bon, j'ai résolu ce problème , ok mais par contre mes emails de commandes ne sont pas en unicode UTF-8, genre "Numéro de commande", le symbole "€" et comme ceci: "≠¬"

J'utilise "UHtmlEmails", tous les fichiers locaux etc... sont bien sauvé en utf8, je présume, qu'il faut la aussi forcer l'utf-8 ? non ?

Moi qui croyais que l'UTF8 était installé d'origine ??:

[Gnidhal]

presque sauf que tes mails sont en iso :
regarde dans le script des mails (dans /modules/) tu devrait trouver ce genre de ligne :
'<head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>'
tu peux normalement remplacer le charset par la constante du site ou le faire en dur

[polo]

Bah oui je sais bien, moi j'ai çà en dur:

Code

<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head>
<body style="margin: 0px; padding: 0px; background-color:#b152a9;">

Je vais essayer en iso alors.


Bon j'ai essayé en ISO, çà n'y change rien. , idem si j'utilise cette contribution:

http://www.oscommerce.com/community/contri...-8+dual+support



Ce message a été modifié par polo - 6 Feb 2012, 23:10.