NPDS : Gestion de contenu et de communauté
Content & Community Management System (CCMS) robuste, sécurisé, complet, performant, parlant vraiment français, libre (Open-Source) et gratuit.
40 visiteur(s) et 0 membre(s) en ligne.
Autres infos
Activité du Site
Pages vues depuis 25/05/2001 : 108 400 929
- Nb. de membres 8 693
- Nb. d'articles 1 695
- Nb. de forums 26
- Nb. de sujets 8
- Nb. de critiques 92
Index du forum »» Version future »» Passer REvolution 13 en UTF8
Nouveau sujet
Passer REvolution 13 en UTF8#26719Répondre
5Contributeur(s)
3 Modérateur(s)
fliaigre
J'ouvre un sujet pour faire part de mes misères.
Pour commencer je me suis mis sur une version de php PHP 5.6.17
Je pars sur une version REv13 installée en latin1 pour la passer en UTF8.
Pour commencer j'ai changé le charset dans metatag de latin à UTF8
J'ai créé une nouvelle base en utf8_general_ci puis les tables en interclassement utf8.
J'ai importé les données
Pour tout ce qui est créé pas de problème après pas de problème. Pour ce qui existait dans la base j'ai des � mais pas pour tout.
Par exemple dans une news, il y a le souci dans le titre mais pas dans le texte.
Un exemple la table topics contenait un sujet Actualités qui affichait donc Actualit�s.
Dans Notepad(encodage UTF8) j'ai affiché les données à enregistrer
En mettant Notepad en encodage ANSI j'obtiens :
En ajoutant cette seconde requête SQL dans la base je n'ai plus les �
Mais du coup je n'y comprends plus rien.
Où est l'erreur? Merci pour les claires explications.
Pour commencer je me suis mis sur une version de php PHP 5.6.17
Je pars sur une version REv13 installée en latin1 pour la passer en UTF8.
Pour commencer j'ai changé le charset dans metatag de latin à UTF8
J'ai créé une nouvelle base en utf8_general_ci puis les tables en interclassement utf8.
J'ai importé les données
Pour tout ce qui est créé pas de problème après pas de problème. Pour ce qui existait dans la base j'ai des � mais pas pour tout.
Par exemple dans une news, il y a le souci dans le titre mais pas dans le texte.
Un exemple la table topics contenait un sujet Actualités qui affichait donc Actualit�s.
Dans Notepad(encodage UTF8) j'ai affiché les données à enregistrer
INSERT INTO `topics` (`topicid`, `topicname`, `topicimage`, `topictext`, `counter`, `topicadmin`) VALUES
(1, 'actualites', 'actualites.gif', 'Actualités', 0, ''),
(2, 'social', 'social.gif', 'Social', 0, ''),
(3, 'formation', 'formation.gif', 'Formation', 0, ''),
(4, 'divers', 'divers.gif', 'Divers', 0, ''),
(5, 'evenements', 'evenement.gif', 'Evénements', 0, ''),
(6, 'reunions', 'reunion.gif', 'Réunions', 0, ''),
(7, 'temoignages', 'temoignage.gif', 'Témoignages', 0, '');
En mettant Notepad en encodage ANSI j'obtiens :
INSERT INTO `topics` (`topicid`, `topicname`, `topicimage`, `topictext`, `counter`, `topicadmin`) VALUES
(1, 'actualites', 'actualites.gif', 'Actualités', 0, ''),
(2, 'social', 'social.gif', 'Social', 0, ''),
(3, 'formation', 'formation.gif', 'Formation', 0, ''),
(4, 'divers', 'divers.gif', 'Divers', 0, ''),
(5, 'evenements', 'evenement.gif', 'Evénements', 0, ''),
(6, 'reunions', 'reunion.gif', 'Réunions', 0, ''),
(7, 'temoignages', 'temoignage.gif', 'Témoignages', 0, '');
En ajoutant cette seconde requête SQL dans la base je n'ai plus les �
Mais du coup je n'y comprends plus rien.
Où est l'erreur? Merci pour les claires explications.
jpb
explications claires .... pas facile :-? ....
on ne va pas rentrer dans de sombre données trop techniques mais je pense que ces éléments pourront aider à comprendre certaines choses ...
la différence que tu soulignes vient du fait que dans les news -si on utilise tiny - le texte est envoyé à la base avec des entités html (ce qui en gros supprime tous problème d'encodage)
il n'en est pas de même pour tous les autre inputs qui n'utilise pas tiny mce (ou autre éventuel mécanisme interne envoyant du html ...) par défaut il envoient à la base du text brut conformément à l'encodage choisi pour la page (dans le cas de npds : charset dans metatag)
ce sont donc toutes ces données provenant des ces entrées qui poseront quelques problèmes et qu'il faut donc convertir ! ...
Et donc pour compliquez les choses ce que tu soulignes à la fin de ton post
dans npds (ce qui à mon sens est encore une lacune à corriger) la connection entre php et la base (est celle par défaut donc en latin1) ce qui signifie par exemple : que lors de la communication entre php et mysql le é (encodé en utf8 par ta page) redevient dans la base é (qui est la représentation en ascii de ton é encodé en utf8 !) ce comportement est donc à considérer comme "normal" ..
NB : pour les corrections il ne faut se concentrer que sur le contenu des colonnes (champs) des tables de la base qui sont de type : char varchar text longtext mediumtext !!
on ne va pas rentrer dans de sombre données trop techniques mais je pense que ces éléments pourront aider à comprendre certaines choses ...
la différence que tu soulignes vient du fait que dans les news -si on utilise tiny - le texte est envoyé à la base avec des entités html (ce qui en gros supprime tous problème d'encodage)
il n'en est pas de même pour tous les autre inputs qui n'utilise pas tiny mce (ou autre éventuel mécanisme interne envoyant du html ...) par défaut il envoient à la base du text brut conformément à l'encodage choisi pour la page (dans le cas de npds : charset dans metatag)
ce sont donc toutes ces données provenant des ces entrées qui poseront quelques problèmes et qu'il faut donc convertir ! ...
Et donc pour compliquez les choses ce que tu soulignes à la fin de ton post
dans npds (ce qui à mon sens est encore une lacune à corriger) la connection entre php et la base (est celle par défaut donc en latin1) ce qui signifie par exemple : que lors de la communication entre php et mysql le é (encodé en utf8 par ta page) redevient dans la base é (qui est la représentation en ascii de ton é encodé en utf8 !) ce comportement est donc à considérer comme "normal" ..
NB : pour les corrections il ne faut se concentrer que sur le contenu des colonnes (champs) des tables de la base qui sont de type : char varchar text longtext mediumtext !!
Npdsteur
Hi,
J'avais du mal à trouver la bonne formulation... jpb a pu te répondre avec brio sur le "schmilblick" de la conversion UTF8 des tables de la DDbase NPDS.
Au début, cela peut apparaître comme *** :paf, mais ce comportement est normal sous la nouvelle mouture de NPDS. (On arrive à s'y faire rapidement, même pour un gars comme moi qui bricolait directement dans les champs de la data-base.
Bref, c'est normal 'en l’état'. ;-)
J'avais du mal à trouver la bonne formulation... jpb a pu te répondre avec brio sur le "schmilblick" de la conversion UTF8 des tables de la DDbase NPDS.
Au début, cela peut apparaître comme *** :paf, mais ce comportement est normal sous la nouvelle mouture de NPDS. (On arrive à s'y faire rapidement, même pour un gars comme moi qui bricolait directement dans les champs de la data-base.
Bref, c'est normal 'en l’état'. ;-)
fliaigre
OK merci à toi JB pour les explications.
Du coup si je charge la base dans notepad qu'est il préférable remplacer les é par é ou par
Par ailleurs, j'ai comparé la structure des tables entre une version rev16 et rev13, avec Winmerge, il y en a quelques unes en plus mais la plupart sont identiques si ce n'est qu'elles sont en UTF8 au lieu de latin1.
Du coup pour l'import des données comment faut-il procéder?
Du coup si je charge la base dans notepad qu'est il préférable remplacer les é par é ou par
é
Par ailleurs, j'ai comparé la structure des tables entre une version rev16 et rev13, avec Winmerge, il y en a quelques unes en plus mais la plupart sont identiques si ce n'est qu'elles sont en UTF8 au lieu de latin1.
Du coup pour l'import des données comment faut-il procéder?
Message édité par : fliaigre / 11-05-2020 17:11
jpb
hélas tu dois remplacer les caractères par leur équivalent en hieroglyphes :-P
par exemple les é par é etc ...etc...
ou par des entités html ce qui est une alternative (qui à mon sens devrait être le standard ...) mais on aurait a nouveau des données (correctes mais hétérogènes) dès que le site refonctionne puisque les input sans tiny envoient (malheureusement pour la conformité du html) du texte brut ...
par exemple les é par é etc ...etc...
ou par des entités html ce qui est une alternative (qui à mon sens devrait être le standard ...) mais on aurait a nouveau des données (correctes mais hétérogènes) dès que le site refonctionne puisque les input sans tiny envoient (malheureusement pour la conformité du html) du texte brut ...
Message édité par : jpb / 12-05-2020 09:26
jpb
tu fait d'abord ta conversion dans une 13 comme tu as commencé puis tu exporte tes données et les intègres dans une bd de 16 ....
sinon il faut se coltiner toute les modification (différences entre une bd 13 et une bd 16 ....) ??
sinon il faut se coltiner toute les modification (différences entre une bd 13 et une bd 16 ....) ??
fliaigre
Mission accomplie.
Rev13 entièrement en utf8 ce qui lui permet de fonctionner avec PHP 5.6.
Récupération des fichiers par FTP.
Récupération de la base avec phpmyadmin sur la base d'une installation Webserver64 paramétrée en php 5.6 coté client et paramétrage Wampserver(Rev13 ne fonctionne pas en php 7).
Création localement d'une base vide en UTF8_general_ci avec phpmyadmin
Avec Notepad ++ modification du fichier sql.(Il est sauvegardé en UTF8)
Création des tables :
Exemple pour illustrer
Devient
Modification du charset, modification du format de date. C'est assez simple avec la fonction rechercher/remplacer de Notepad. Il faut penser aux COLLATE qui sont en latin1_german1_ci à remplacer par utf8_general_ci.
Globalement faire une recherche sur latin1.
Concernant les données.
Si, comme moi elle sont sauvegardées en UTF8 Notepad l'indique dans le Menu Encodage.
Il faut que les caractères accentués deviennent des é pour é. On l'obtient en indiquant à Notepad un encodage en ANSI.
Il suffit ensuite d'alimenter les tables par copié/collé avec INSERT INTO
Il peut être nécessaire de le faire en plusieurs fois en fonction de la taille de la table.
Au final on obtient une base encodée en UTF8.
Il faut ensuite passer le CHARSET à UTF8 dans Metatags depuis l'administration.
Ce n'est pas encore complètement terminé. Il peut rester quelques traces de caractères accentués comme dans config.php ou dans des fichiers de thèmes. Mais il suffit de les modifier dans Notepad de se mettre en encodage UTF8 et de remplacer les quelques caractères inappropriés par les bons.
Je pense n'avoir rien oublié, je laisse les pros modifier le cas échéant.
Maintenant, l'étape suivante c'est muter vers Rev16
Rev13 entièrement en utf8 ce qui lui permet de fonctionner avec PHP 5.6.
Récupération des fichiers par FTP.
Récupération de la base avec phpmyadmin sur la base d'une installation Webserver64 paramétrée en php 5.6 coté client et paramétrage Wampserver(Rev13 ne fonctionne pas en php 7).
Création localement d'une base vide en UTF8_general_ci avec phpmyadmin
Avec Notepad ++ modification du fichier sql.(Il est sauvegardé en UTF8)
Création des tables :
Exemple pour illustrer
DROP TABLE IF EXISTS `appli_log`;
CREATE TABLE IF NOT EXISTS `appli_log` (
`al_id` int(11) NOT NULL DEFAULT '0',
`al_name` varchar(255) DEFAULT NULL,
`al_subid` int(11) NOT NULL DEFAULT '0',
`al_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`al_uid` int(11) NOT NULL DEFAULT '0',
`al_data` text,
`al_ip` varchar(19) NOT NULL DEFAULT '',
`al_hostname` varchar(255) DEFAULT NULL,
KEY `al_id` (`al_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
Devient
DROP TABLE IF EXISTS `appli_log`;
CREATE TABLE IF NOT EXISTS `appli_log` (
`al_id` int(11) NOT NULL DEFAULT '0',
`al_name` varchar(255) DEFAULT NULL,
`al_subid` int(11) NOT NULL DEFAULT '0',
`al_date` datetime NOT NULL DEFAULT '1000-01-01 00:00:00',
`al_uid` int(11) NOT NULL DEFAULT '0',
`al_data` text,
`al_ip` varchar(19) NOT NULL DEFAULT '',
`al_hostname` varchar(255) DEFAULT NULL,
KEY `al_id` (`al_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Modification du charset, modification du format de date. C'est assez simple avec la fonction rechercher/remplacer de Notepad. Il faut penser aux COLLATE qui sont en latin1_german1_ci à remplacer par utf8_general_ci.
Globalement faire une recherche sur latin1.
Concernant les données.
Si, comme moi elle sont sauvegardées en UTF8 Notepad l'indique dans le Menu Encodage.
Il faut que les caractères accentués deviennent des é pour é. On l'obtient en indiquant à Notepad un encodage en ANSI.
Il suffit ensuite d'alimenter les tables par copié/collé avec INSERT INTO
Il peut être nécessaire de le faire en plusieurs fois en fonction de la taille de la table.
Au final on obtient une base encodée en UTF8.
Il faut ensuite passer le CHARSET à UTF8 dans Metatags depuis l'administration.
Ce n'est pas encore complètement terminé. Il peut rester quelques traces de caractères accentués comme dans config.php ou dans des fichiers de thèmes. Mais il suffit de les modifier dans Notepad de se mettre en encodage UTF8 et de remplacer les quelques caractères inappropriés par les bons.
Je pense n'avoir rien oublié, je laisse les pros modifier le cas échéant.
Maintenant, l'étape suivante c'est muter vers Rev16
fliaigre
Bonjour Jireck,
Non celle-ci est petite. Elle fait 2.5Mo.
Je me fais la main.
L'autre elle fait 100 fois plus. Mais pour moi comme pour d'autres c'est surtout les tables liées au forum qui pèsent. On verra ça après. ;-)
Non celle-ci est petite. Elle fait 2.5Mo.
Je me fais la main.
L'autre elle fait 100 fois plus. Mais pour moi comme pour d'autres c'est surtout les tables liées au forum qui pèsent. On verra ça après. ;-)
Jireck
c'est la même chose de mon coté.
Va falloir s'y pencher. une mecanique de transformation à la main etant complexe et non aisé.
Va falloir s'y pencher. une mecanique de transformation à la main etant complexe et non aisé.
jpb
il y a une alternative
c'est de modifier définitivement l'encodage de la connection entre php et mysql j'ai fait un test sur le labo ca fonctionne bien semble t'il ...
mais je ne sais pas si je le met dans la 16.1 ou pas ... quel est votre avis ?
cette modif supprimerait l'étape fastidieuse des hieroglyphe :-D et finaliserait le support utf8 de npds et rendrait les choses beaucoup plus cohérentes (de ce fait on abandonnerai définitivement le support iso)...
le process serait donc d'exporter les données de mysql de les transformer en utf8 dans vos éditeurs de text et de réimporter (dans les nouvelles table d'une 16 ...) ou dans votre 13 customisé.....
=> bien sûr cette modif amènerait aussi le nécessité de retransformer les bd des sites qui sont déjà en 16 ...
Voici la modif dans le mainfile...
c'est de modifier définitivement l'encodage de la connection entre php et mysql j'ai fait un test sur le labo ca fonctionne bien semble t'il ...
mais je ne sais pas si je le met dans la 16.1 ou pas ... quel est votre avis ?
cette modif supprimerait l'étape fastidieuse des hieroglyphe :-D et finaliserait le support utf8 de npds et rendrait les choses beaucoup plus cohérentes (de ce fait on abandonnerai définitivement le support iso)...
le process serait donc d'exporter les données de mysql de les transformer en utf8 dans vos éditeurs de text et de réimporter (dans les nouvelles table d'une 16 ...) ou dans votre 13 customisé.....
=> bien sûr cette modif amènerait aussi le nécessité de retransformer les bd des sites qui sont déjà en 16 ...
Voici la modif dans le mainfile...
$dblink=Mysql_Connexion();
// finalisation du support complet utf8
if ($mysql_i==1)
mysqli_set_charset($dblink,"utf8");
else
mysql_set_charset($dblink,"utf8");
Oui, j'ai perçu ton alternative hier soir (comme celui de son impact) :-?
=> bien sûr cette modif amènerait aussi le nécessité de retransformer les bd des sites qui sont déjà en 16 ...
Malgré le boulot que cela risque de m’apporter (déjà en 16), je pense effectivement qu'il est utile d'apporter cette cohérence. Qui on l'imagine bien pour les Webmasters en herbe, peut vite être fastidieux (voire devenir totalement réfractaire) ;-)
Bref ! => moi je suis pour +
jpb
oui pourquoi pas ...
cela nécessite a minima mysql 5.5.3
celà permettrait en plus de presque tous les languages d'utiliser de manière transparente les emoji es caractères matématique et autres obscurités très peu utilisés enfin bref la totale de l'unicode ....
cependant ce n'est pas une opération anodine dans la base puisque que l'on passerait sur un stockage à 4 byte pour un caractère
conséquence de nombreuse modif dans le code et dans la structure de la table
donc je dirai qu'on pourrai le faire en deux étape d'abord en utf8 pour la 16.1 et la prochaine en utf8mb4 ?? car sinon cela risque de retarder la 16.1 qui est prête ...
cela nécessite a minima mysql 5.5.3
celà permettrait en plus de presque tous les languages d'utiliser de manière transparente les emoji es caractères matématique et autres obscurités très peu utilisés enfin bref la totale de l'unicode ....
cependant ce n'est pas une opération anodine dans la base puisque que l'on passerait sur un stockage à 4 byte pour un caractère
conséquence de nombreuse modif dans le code et dans la structure de la table
donc je dirai qu'on pourrai le faire en deux étape d'abord en utf8 pour la 16.1 et la prochaine en utf8mb4 ?? car sinon cela risque de retarder la 16.1 qui est prête ...
fliaigre
Bonjour,
Je suis en train de transférer les données sur une base Dune.
Je vous ferai un rapport complet des difficultés que j'ai eu avec quelques tables, mais j'ai une question concernant les users(C'est finalement la plus compliquée, en raison de la suppression des champs icq, aim, yim et msnm). Peut être m'y suis je mal pris.
Dans Dune il est imposé un format de mot de passe sécurisé. Du coup les mots de passe déjà dans la base ne sont plus acceptés. C'est un vrai problème sur un site existant avec des milliers d'utilisateurs.
Comment contourner ce problème?
Je suis en train de transférer les données sur une base Dune.
Je vous ferai un rapport complet des difficultés que j'ai eu avec quelques tables, mais j'ai une question concernant les users(C'est finalement la plus compliquée, en raison de la suppression des champs icq, aim, yim et msnm). Peut être m'y suis je mal pris.
Dans Dune il est imposé un format de mot de passe sécurisé. Du coup les mots de passe déjà dans la base ne sont plus acceptés. C'est un vrai problème sur un site existant avec des milliers d'utilisateurs.
Comment contourner ce problème?
bartok
Citation : Npdsteur
Oui, j'ai perçu ton alternative hier soir (comme celui de son impact) :-?
=> bien sûr cette modif amènerait aussi le nécessité de retransformer les bd des sites qui sont déjà en 16 ...
Malgré le boulot que cela risque de m’apporter (déjà en 16), je pense effectivement qu'il est utile d'apporter cette cohérence. Qui on l'imagine bien pour les Webmasters en herbe, peut vite être fastidieux (voire devenir totalement réfractaire) ;-)
Bref ! => moi je suis pour +
Oui, j'ai perçu ton alternative hier soir (comme celui de son impact) :-?
=> bien sûr cette modif amènerait aussi le nécessité de retransformer les bd des sites qui sont déjà en 16 ...
Malgré le boulot que cela risque de m’apporter (déjà en 16), je pense effectivement qu'il est utile d'apporter cette cohérence. Qui on l'imagine bien pour les Webmasters en herbe, peut vite être fastidieux (voire devenir totalement réfractaire) ;-)
Bref ! => moi je suis pour +
+1 :=!
Message édité par : bartok / 16-05-2020 10:58
fliaigre
Bon au final j'ai trouvé une solution moins lourde pour l'import.
J'ai créé la table user avec le même format que pour rev13, pui j'ai supprimé les champs surnuméraires et modifié le champ user theme en le passant de INT(3) à VARCHAR(255) de manière à être conforme à Rev16.
Reste le problème des mots de passe.
J'ai créé la table user avec le même format que pour rev13, pui j'ai supprimé les champs surnuméraires et modifié le champ user theme en le passant de INT(3) à VARCHAR(255) de manière à être conforme à Rev16.
Reste le problème des mots de passe.
jpb
comprends pas le probleme avec le mots de passes (y'a que si l'utilisateur ou l'admin change son mot de passe qu'il devra se conformer aux nouvelles contraintes non ?) dans les logins il n'y a pas de controle ?...si ?
Message édité par : jpb / 16-05-2020 11:43