Forum : Version future / Passer REvolution 13 en UTF8 - NPDS - Gestion de Contenu et de Communauté Open Source

MODULES

Pour étendre les nombreuses fonctionnalités disponibles de base - modules.npds.org est à votre disposition.

Des modules complémentaires, une communauté de développeurs active, des forums pour vos questions ... NPDS est aussi une plateforme de développement !
STYLES

Vous cherchez des thèmes graphiques pour votre portail ou votre communauté : styles.npds.org est à votre disposition.

Des thèmes du plus simple au plus sophistiqué. Des thèmes facilement modifiables et toujours en Open-Source - Laissez simplement parler votre imagination !
BIBLES

La documentation indispensable pour personnaliser et exploiter toute la puissante de NPDS est à votre disposition sur bible.npds.org.

Vous pouvez participer à l'effort de documentation - rien de plus simple : contactez un membre de la Team de développement et nous vous ouvrirons un compte sur le Wiki !

Au delà de la gestion de contenu 'classique', NPDS met en oeuvre un ensemble de fonctions spécifiquement dédiées à la gestion de Communauté et de groupes de travail collaboratif.
Il s'agit d'un Content & Community Management System (CCMS) robuste, sécurisé, complet, performant et parlant vraiment français.

Gérez votre Communauté d'utilisateurs, vos groupes de travail collaboratif, publiez, gérez et organisez votre contenu grâce aux puissants outils disponibles de base.

Multi langues (Français, Anglais, Allemand, Espagnol, Chinois)
Respect des standards : UTF8, XHTML, CSS, ...
Système de blocs avancés
Installation et administration complète et centralisée
Editeur HTML intégré
Gestionnaire de fichier en ligne
Gestion des groupes de membres
Ecriture collaborative de documents (PAD)
Forums évolués
Mini-sites (pour les membres et les groupes de travail)
Chat temp réel
Système de News et de rubriques complet (édition, révision, publication)
...

Gratuit et libre (Open-Source), développé en PHP, NPDS est personnalisable grâce à de nombreux thèmes et modules et ne requiert que quelques compétences de base.

NPDS Workplace - groupe de travail collaboratif

NPDS WorkSpace - tous l'univers du travail collaboratif.

Autres infos

Plan du site

Catégories

Anciens articles

Articles plus anciens

Activité du Site

Pages vues depuis Mai 2001 : 104 165 763

Nb. de Membres : 8 693
Nb. d'Articles : 1 690
Nb. de Forums : 25
Nb. de Sujets : 8
Nb. de Critiques : 92

Top 10 Statistiques

Modéré par : developpeur jpb Jireck
Index du Forum » » Version future » » Passer REvolution 13 en UTF8
2 pages [ 1 \| 2 ]

Auteur Passer REvolution 13 en UTF8

916

Posté : 10-05-2020 09:38

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


INSERT INTO `topics` (`topicid`, `topicname`, `topic image`, `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, ''),
< br />(7, 'temoignages', 'temoignage.gif', 'Témoignages', 0,&nb sp;'');

En mettant Notepad en encodage ANSI j'obtiens :


INSERT INTO `topics` (`topicid`, `topicname`, `topic image`, `topictext`, `counter`, `topicadmin`) VALUES

(1, 'actualites', 'actualites.gif', 'ActualitÃ©s', 0,&nbs p;''),

(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,&n bsp;'');

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.

www

2791

Posté : 11-05-2020 10:26

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 !!

www

113

Posté : 11-05-2020 12:15

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 ***

, 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'.

916

Posté : 11-05-2020 13:14

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?

Message édité par : fliaigre / 11-05-2020 17:11

www

2791

Posté : 12-05-2020 09:18

hélas tu dois remplacer les caractères par leur équivalent en hieroglyphes

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

www

916

Posté : 12-05-2020 14:35

OK.

Et ensuite pour intégrer les données aux tables de Rev16 dans les tables modifiées?

www

2791

Posté : 12-05-2020 15:18

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 ....) ??

www

916

Posté : 14-05-2020 12:05

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




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 '000 0-00-00 00:00:00',

  `al_uid` int(11) NOT NULL DEFAULT '0',
< br />  `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 '100 0-01-01 00:00:00',

  `al_uid` int(11) NOT NULL DEFAULT '0',
< br />  `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

www

8502

Jireck

Posté : 14-05-2020 15:55

c'est coool on suis ton aventure de post en post.

Bravo
ta base est grosse ?

916

Posté : 14-05-2020 18:38

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.

www

8502

Jireck

Posté : 15-05-2020 12:28

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é.

2791

Posté : 15-05-2020 13:14

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

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");

www

113

Posté : 15-05-2020 13:32

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 +

8502

Jireck

Posté : 15-05-2020 19:27

mysqli_set_charset($dblink,"utf8mb4"); ?

2791

Posté : 15-05-2020 21:21

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

www

Aller à la page : [ 1 | 2 ]

Temps : 0.0233 seconde(s)