rvelices a écrit:

rub a écrit:

En fait pour résumé les différents charsets, nous avons:
  o HTML charset: encodage utilisé pour restituer les infos au niveau du browser
  o PHP charset: encodage utilisé pour les méthodes et les fichiers php
  o DB charset: encodage utilisé pour communiquer avec la base de données
  o MySQL Charset: encodage utilisé pour stoker les données
  o IPTC charset: encodage des photos

Exact, sauf que PHP charset doit etre toujours iso-8859-1, sauf les valeurs de $lang (pas les cles)

PHP charset dépends donc de l'installation de PHP, c'est à dire du provider?  (en chine,on n'aura pas du is0-8859-1, j'espère!)
Donc, cela veut que PWG_CHARSET corresong au HTML charset?

rvelices a écrit:

oui. il y a peut etre moyen de faire un upgrade automatique a utf-8 des tables et charset si par exemple toutes les langues des admins sont en iso-8859-1 et les tables MySql sont soit latin1, soit utf-8 ... Mais on peut faire cet upgrade automatique seulement pendant l'upgrade (apres l'encodage de la langue disparait de #user_infos.language)
Vous achetez ???

Vendu!

rvelices a écrit:

Ce qui m'embête c'est l'encodage du PHP charset en UTF8 ou IS0-8859-1.
Car, il va falloir suivant le cas ré-encoder les fichiers de traduction.

l'anglais est 'neutre', cad le meme encodage pour iso-8859-x ou utf-8. par consequent le repertoire anglais va se nommer en_GB
on peut livrer une pwg soit avec fr_FR.iso-8859-1, soit avec fr_FR.utf-8. ca va toujours marcher (tant que PWG_CHARSET est un des 2), mais ca sera + performant de livrer les 2.

Pourquoi, s'embêter à livrer 2 versions autant tout livrer en UTF8.
Et pas conséquent, générer en HTML que de l'UTF8.

rvelices a écrit:

Ce qui m'embête c'est l'encodage du PHP charset en UTF8 ou IS0-8859-1.
Car, il va falloir suivant le cas ré-encoder les fichiers de traduction.

l'anglais est 'neutre', cad le meme encodage pour iso-8859-x ou utf-8. par consequent le repertoire anglais va se nommer en_GB
on peut livrer une pwg soit avec fr_FR.iso-8859-1, soit avec fr_FR.utf-8. ca va toujours marcher (tant que PWG_CHARSET est un des 2), mais ca sera + performant de livrer les 2.

Par contre, pour le tables si on fait le upgrade auto en UTF8, il faut MySql > 4.1, c'est ca?

rvelices a écrit:

PS: Je ne suis étendu sur les IPTC , car je ne sais si on peut savoir le charset utilisé dans la photo, etc.
Ce qui est sur c'est les données IPTC doivent être ré-encodées dans le PHP charset, non?

pas PHP charset, mais PWG_CHARSET. qu'on mette la description d;une photo a partir d'un navigateur ou IPTC, ca doit generer exactement la meme requete.

Oui la même requête.

Mais cela implique aussi des conversions (IPTC en ISO-8859-1 si  l'IPTC peut être en UTF-8! C'est possible IPTC en UTF8)?.


Ca me chagrine cette histoire de PHP charset en ISO-8859-1.
Cela veut dire les opérations sur les chaînes de caractères se font en ISO-8859-1 et pas en UTF-8, c'est ca?
Ca pose pas de problèmes?

Cela veut dire aussi que si je veux une PWG en chinois chez Free, je ne pourrais avoir une galerie carré:
  o pas trop de soucis, au niveau des descriptions, commentaires, etc.
  o mais ca sera la cata avec les IPTC
  o et les fonctions de chaines, elles vont être OK?

rvelices a écrit:

rub a écrit:

Ca me chagrine cette histoire de PHP charset en ISO-8859-1.
Cela veut dire les opérations sur les chaînes de caractères se font en ISO-8859-1 et pas en UTF-8, c'est ca?
Ca pose pas de problèmes?

non, non ca n'a rien a voir... les valeurs que la base nous retourne sont stockes dans des variables. le contenu sera dans PWG_CHARSET, pas forcement iso-8859-1. moi je pensais que t'as defini php charset comme "encodage utilisé pour les méthodes et les fichiers php". donc pour moi ca veut juste dire qu'appart lang[...] on n'a pas le droit d'avoir d'accents dans le code php (comme c'etait le cas avec str2url).

Ha ok!

Pour moi, je voulais dire que PWG_CHARSET était le codage des variables/données dans PHP.
Le codage des fichier étant en ASCII-US/7-bits sauf pour le fichier de langues (php ou html).


Donc, vu qu'on va avoir un upgrade auto, autant dire que du début jusqu'à la fin, on utilise l'UFT-8. (Base de données, Php, fichiers de traductions, HTML)
Et on ne s'embete plus à mettre en paramètre des PWG_CHARSET ou DB_CHARSET.

Full UTF-8, moi, je suis pour à 300%

Upgrade + Full UTF-8 + UTF-8 obligatoire = un bon choix pour moi!

z0rglub a écrit:

J'approuve parfaitement l'avis de rub : on passe en full utf-8 partout, exit l'iso-8859-x.

rvelices: la base de ma galerie perso croit que les données sont en iso, mais c'est faux. Mais ce n'est pas vraiment important puisque je ne demande pas à MySQL de traiter mes chaînes de caractères, juste de les stocker, L'important c'est que PHP sache qu'il a envoyé les données en utf-8, que le charset HTML soit utf-8 pour que les formulaires envoient de l'utf-8 et que le navigateur comprenne qu'il faut afficher en utf-8.

oui mais si l'upgrade passe tout en utf-8 alors je vais appeler ALTER TABLE x CONVERT TO CHARACTER SET utf8 pour chacune des tables... et les accents de ta galerie partent en fumee... si ca t'embete pas, pour moi c'est bon ...

bon voila ce que je propose pour l'upgrade:
A. si MySql<4.1
  - pwg_charset 'iso-8859-1' !
B. MySql>=4.1
1. si la langue actuelle du webmaster est en iso-8859-1
   - pwg_charset 'utf-8' db_charset 'utf8'
   - toutes les tables sont directement converties en utf8
2. si la langue actuelle du webmaster est en utf-8
   - pwg_charset 'utf-8' db_charset 'utf8'
   - toutes les tables sont converties en BLOB et ensuite de BLOB a utf8
3. si la langue actuelle du webmaster est en iso-8859-2
   - pwg_charset 'utf-8' db_charset 'utf8'
   - toutes les tables sont converties en BLOB, ensuite de BLOB a latin2, ensuite de latin2 a utf8
4. autre cas - que dieu nous aide :-)
   - pwg_charset 'iso-8859-1' db_charset 'latin1'
   - je ne touche pas aux tables

d'accord ???

rvelices a écrit:

bon voila ce que je propose pour l'upgrade:
A. si MySql<4.1
  - pwg_charset 'iso-8859-1' !
B. MySql>=4.1
1. si la langue actuelle du webmaster est en iso-8859-1
   - pwg_charset 'utf-8' db_charset 'utf8'
   - toutes les tables sont directement converties en utf8
2. si la langue actuelle du webmaster est en utf-8
   - pwg_charset 'utf-8' db_charset 'utf8'
   - toutes les tables sont converties en BLOB et ensuite de BLOB a utf8
3. si la langue actuelle du webmaster est en iso-8859-2
   - pwg_charset 'utf-8' db_charset 'utf8'
   - toutes les tables sont converties en BLOB, ensuite de BLOB a latin2, ensuite de latin2 a utf8
4. autre cas - que dieu nous aide :-)
   - pwg_charset 'iso-8859-1' db_charset 'latin1'
   - je ne touche pas aux tables

d'accord ???

Ok pour moi sachant qu'on aura sûrement que le B comme l'a rappelé VDigital!

Je suis pressé de tester ca...

rvelices a écrit:

... et les accents de ta galerie partent en fumee... si ca t'embete pas, pour moi c'est bon ...

Pas de problème. Je savais ce que je faisais en bidouillant en utf-8. Je saurai bidouiller pour conserver l'intégrité de mes données.

Par contre, pour l'upgrade.php (pas l'upgrade_feed.php) on proposera 2 options : avec et sans conversion des données en base. La conversion étant par défaut et recommandée. Ca te va ?