Langue
🎨 Skin viewer
Les plus téléchargés
- 1 npds_galerie498
- 2 npds_agenda482
- 3 Programmes de Technologie 1985 MEN ...438
- 4 86-Car426
- 5 npds_annonces 418
- 6 photosize418
- 7 npds_glossaire406
- 8 npds_encapsuleur397
- 9 bootstrap.png360
- 10 superhero340
Index du forum »» Road map développement »» [Résolu] - Conversion BdD => UTF8
[Résolu] - Conversion BdD => UTF8#1370
2Contributeur(s)
2 Modérateur(s)
bartok
Je préfère poster séparément ici pour ne rien polluer : Conversion de la BdD en UTF8 : j'y perds un peu mon Latin...
Je viens de constater que le contenu des tables dans la version WS16.1 libérée est toujours encodé en ISO 8859-1, que ce soit pour les données issues de Tiny (entités html) ou pour celles provenant d'un input comme le titre du bloc Activité du site.
Question : pourquoi ?
Il me semble l'avoir déjà posée mais je ne me souviens plus de la réponse.
A noter que ça ne perturbe en rien le décodage y compris dans les versions 7 de php (i.e. chez OVH)
La mixité est même supportée ; Exemple :
On ouvre le bloc « Activité du bloc » encodé en Latin-1, puis on revalide le bloc sans rien modifier : le « é » est ré-encodé en UTF8
Je viens de constater que le contenu des tables dans la version WS16.1 libérée est toujours encodé en ISO 8859-1, que ce soit pour les données issues de Tiny (entités html) ou pour celles provenant d'un input comme le titre du bloc Activité du site.
Question : pourquoi ?
Il me semble l'avoir déjà posée mais je ne me souviens plus de la réponse.
A noter que ça ne perturbe en rien le décodage y compris dans les versions 7 de php (i.e. chez OVH)
La mixité est même supportée ; Exemple :
On ouvre le bloc « Activité du bloc » encodé en Latin-1, puis on revalide le bloc sans rien modifier : le « é » est ré-encodé en UTF8
jpb
oui c'est justement parce que au fur à mesure on a perdu notre latin (1 iso) que l'on doit finir l'implémentation du support utf8
dans une 16.1 (avec les metatags en utf8) tous les inputs envoient des caractères encodé en utf8 MAIS comme le dialogue entre php et mysql est lui en latin (ce qui n'est plus le cas pour une 16.2!) on se retrouve donc dans la base avec des caractères utf8 représenté en latin (en quelque sorte déguisés en latin 1
)
pour tiny on peut passer notre chemin il envoie du html DONC que des caractères ascii ....
et ceci est aussi valable pour une 13 en utf8 ! ....
tu peux consulter le fichier v16 uf8.txt qui se trouve dans le gestionnaire de fichier du groupe 2
..... c'est pas encore très pédagogique (lol) c'est le fichier dans lequel j'essai de mettre à jour les éléments du process leur cause et leur explication et sur lequel je me base pour faire évoluer le process son implémentation et sa documentation .....
dans une 16.1 (avec les metatags en utf8) tous les inputs envoient des caractères encodé en utf8 MAIS comme le dialogue entre php et mysql est lui en latin (ce qui n'est plus le cas pour une 16.2!) on se retrouve donc dans la base avec des caractères utf8 représenté en latin (en quelque sorte déguisés en latin 1
)
pour tiny on peut passer notre chemin il envoie du html DONC que des caractères ascii ....
et ceci est aussi valable pour une 13 en utf8 ! ....
pour comprendre : le cas du é
é
en utf8 ==> 195 169 0xC3A9 ==> é
é == é
réinterprété en latin 1 (par mysql)
en latin1 ==> 195 0x00C3 ==> Ã
en latin1 ==> 169 0x00A9 ==> ©
é == étu peux consulter le fichier v16 uf8.txt qui se trouve dans le gestionnaire de fichier du groupe 2
..... c'est pas encore très pédagogique (lol) c'est le fichier dans lequel j'essai de mettre à jour les éléments du process leur cause et leur explication et sur lequel je me base pour faire évoluer le process son implémentation et sa documentation .....
L'eau goutte à goutte finit toujours par percer la pierre...
Message édité par : jpb / 29-06-2020 11:00
bartok
Merci pour ça.
En fait, ma vraie question, la voilà: puisque ça marche (et cohabite) comme ça, faut-il absolument migrer la BdD et si oui, pourquoi?
Donc en 16.2 la BdD sera forcément "repeinte" en UTF8?
En fait, ma vraie question, la voilà: puisque ça marche (et cohabite) comme ça, faut-il absolument migrer la BdD et si oui, pourquoi?
Donc en 16.2 la BdD sera forcément "repeinte" en UTF8?
Message édité par : bartok / 29-06-2020 11:18
jpb
oui ca fonctionne (et depuis longtemps et pas que sur npds )
...
mais avouons que c'est tordu et vraiment obscur (même pour des bricoleurs avertis) ! (et n'a aucun avantage ...si ce n'est d'avoir compenser notre lacune d'implémentation du support d'utf8) ...
Voir et comprendre, dans les fichiers sql, dans phpmyadmin dans le code, un é, un émoji, un caractère chinois grec hindi ou autres ... tels qu'ils sont est quand même "plus mieux" lisible humainement que leur représentation équivalente en une suite de hiéroglyphes ....
donc pour la cohérence et la compréhension
il faut absolument migrer ....
et pour une 16.2 oui car la finalisation du support utf8 (ne permet donc plus d'utiliser les données déguisées ! ) donc la migration et la mise bas des déguisement est obligatoire ...
...
mais avouons que c'est tordu et vraiment obscur (même pour des bricoleurs avertis) ! (et n'a aucun avantage ...si ce n'est d'avoir compenser notre lacune d'implémentation du support d'utf8) ...
Voir et comprendre, dans les fichiers sql, dans phpmyadmin dans le code, un é, un émoji, un caractère chinois grec hindi ou autres ... tels qu'ils sont est quand même "plus mieux" lisible humainement que leur représentation équivalente en une suite de hiéroglyphes ....
donc pour la cohérence et la compréhension
il faut absolument migrer ....
et pour une 16.2 oui car la finalisation du support utf8 (ne permet donc plus d'utiliser les données déguisées ! ) donc la migration et la mise bas des déguisement est obligatoire ...
L'eau goutte à goutte finit toujours par percer la pierre...
