je ne sais pas si j'ai une chance de trouver une réponse à ce sujet sur
les accès aternatifs
Je n'utilise QUE ça depuis toujours.
Tous mes progs Windev, tous mes sites WEBDEV sont basés là dessus avec
des bases mysql
Là il se trouve que je dois gérer du polonais, du cz, du hu ...
bref des caractères avec des accents j'te dis pas
donc j'ai du passer le jeu de caractère en utf8_unicode_ci (au ieu du
utf8_general_ci)
Le pb c'est que le sqlcol travaille avec de l'asciiz string et ces
accents bizarres sont restitués avec des ?
J'ai essayé de changer la classe en unicode, mais là = caractères
chinois
Avez vous une solution.
Merci de vos réponses.
---
Cet email a fait l'objet d'une analyse antivirus par AVG.
http://www.avg.com
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Côme
Bonjour Alors pour commencer ne pas confondre le charset et la collation, le charset gère l'encodage du caractère, la collation gère les règles de tri pour tel type d'encodage. Pour de l'utf8 avec MySql on peut utiliser l'ancien charset utf8 (sur 1 à 3 octets seulement, donc un truc à la sauce MySQl !) mais les caractères unicode au delà du code 0xFFFD ne sont pas pris en compte ou le nouveau utf8mb4 (sur 1 à 4 octets comme le standard unicode) qui lui gère bien tous les caractères unicodes. Avec le charset utf8 (et non utf8mb4) on peut ensuite choisir entre la collation utf8_general_ci et la collation utf8_unicode_ci. La première est plus rapide à l'usage (vitesse du tri) mais ne gère pas forcément de manière parfaite tous les tris dans toutes les langues. La deuxième gère correctement tous les tris dans toutes les langues mais au détriment d'une performance moindre (on peut perdre jusqu'à 10 % en vitesse selon certains benchmark sur des requêtes avec LIKE par exemple). Pour le charset utf8mb4 il y a d'autres collations proposées selon la version d'unicode visée: utf8mb4_unicode_520_ci, utf8mb4_0900_ai_ci ... Par ailleurs changer le charset d'une table ne convertie pas les données dans la table... Il y a des instructions spécifiques pour cela. Du coup on peut se retrouver dans une situation ou mysql "croit" que la telle table contient des données en utf8 alors que ce n'est pas le cas. Lorsqu'en plus un serveur web intervient (site en php par exemple) on peut se retrouver avec des problèmes de double encodage si tout n'est pas cohérent entre le charset déclaré pour se connecter à la base MYSQL,le charset déclaré de la table, le charset déclaré pour la page html et la réalité de l'encodage des données dans la table... J'espère que ceci va t'aider à y voir plus clair. Pour ton souci d'accès natif avec MySQL je n'y ai pas encore été confronté mais comme toi j'utilisais jusqu'ici l'encodage "utf8" et la collation "utf8_general_ci". J'espère que ton souci est lié à la non conversion des données dans ta table et non à un vrai souci côté PCSoft. A suivre... Côme, Clairinfo.
Bonjour
Alors pour commencer ne pas confondre le charset et la collation, le
charset gère l'encodage du caractère, la collation gère les règles de
tri pour tel type d'encodage.
Pour de l'utf8 avec MySql on peut utiliser l'ancien charset utf8 (sur 1
à 3 octets seulement, donc un truc à la sauce MySQl !) mais les
caractères unicode au delà du code 0xFFFD ne sont pas pris en compte ou
le nouveau utf8mb4 (sur 1 à 4 octets comme le standard unicode) qui lui
gère bien tous les caractères unicodes.
Avec le charset utf8 (et non utf8mb4) on peut ensuite choisir entre la
collation utf8_general_ci et la collation utf8_unicode_ci. La première
est plus rapide à l'usage (vitesse du tri) mais ne gère pas forcément de
manière parfaite tous les tris dans toutes les langues. La deuxième gère
correctement tous les tris dans toutes les langues mais au détriment
d'une performance moindre (on peut perdre jusqu'à 10 % en vitesse selon
certains benchmark sur des requêtes avec LIKE par exemple).
Pour le charset utf8mb4 il y a d'autres collations proposées selon la
version d'unicode visée: utf8mb4_unicode_520_ci, utf8mb4_0900_ai_ci ...
Par ailleurs changer le charset d'une table ne convertie pas les données
dans la table... Il y a des instructions spécifiques pour cela.
Du coup on peut se retrouver dans une situation ou mysql "croit" que la
telle table contient des données en utf8 alors que ce n'est pas le cas.
Lorsqu'en plus un serveur web intervient (site en php par exemple) on
peut se retrouver avec des problèmes de double encodage si tout n'est
pas cohérent entre le charset déclaré pour se connecter à la base
MYSQL,le charset déclaré de la table, le charset déclaré pour la page
html et la réalité de l'encodage des données dans la table...
J'espère que ceci va t'aider à y voir plus clair.
Pour ton souci d'accès natif avec MySQL je n'y ai pas encore été
confronté mais comme toi j'utilisais jusqu'ici l'encodage "utf8" et la
collation "utf8_general_ci". J'espère que ton souci est lié à la non
conversion des données dans ta table et non à un vrai souci côté PCSoft.
Bonjour Alors pour commencer ne pas confondre le charset et la collation, le charset gère l'encodage du caractère, la collation gère les règles de tri pour tel type d'encodage. Pour de l'utf8 avec MySql on peut utiliser l'ancien charset utf8 (sur 1 à 3 octets seulement, donc un truc à la sauce MySQl !) mais les caractères unicode au delà du code 0xFFFD ne sont pas pris en compte ou le nouveau utf8mb4 (sur 1 à 4 octets comme le standard unicode) qui lui gère bien tous les caractères unicodes. Avec le charset utf8 (et non utf8mb4) on peut ensuite choisir entre la collation utf8_general_ci et la collation utf8_unicode_ci. La première est plus rapide à l'usage (vitesse du tri) mais ne gère pas forcément de manière parfaite tous les tris dans toutes les langues. La deuxième gère correctement tous les tris dans toutes les langues mais au détriment d'une performance moindre (on peut perdre jusqu'à 10 % en vitesse selon certains benchmark sur des requêtes avec LIKE par exemple). Pour le charset utf8mb4 il y a d'autres collations proposées selon la version d'unicode visée: utf8mb4_unicode_520_ci, utf8mb4_0900_ai_ci ... Par ailleurs changer le charset d'une table ne convertie pas les données dans la table... Il y a des instructions spécifiques pour cela. Du coup on peut se retrouver dans une situation ou mysql "croit" que la telle table contient des données en utf8 alors que ce n'est pas le cas. Lorsqu'en plus un serveur web intervient (site en php par exemple) on peut se retrouver avec des problèmes de double encodage si tout n'est pas cohérent entre le charset déclaré pour se connecter à la base MYSQL,le charset déclaré de la table, le charset déclaré pour la page html et la réalité de l'encodage des données dans la table... J'espère que ceci va t'aider à y voir plus clair. Pour ton souci d'accès natif avec MySQL je n'y ai pas encore été confronté mais comme toi j'utilisais jusqu'ici l'encodage "utf8" et la collation "utf8_general_ci". J'espère que ton souci est lié à la non conversion des données dans ta table et non à un vrai souci côté PCSoft. A suivre... Côme, Clairinfo.
Côme
Bon apparemment j'ai tout compris de travers si ton souci porte en fait sur les accès "alternatifs" et non les accès "natifs", arf ! Bon l'explication sur les encodages MySql pourra peut-être servir à quelqu'un... Côme, Clairinfo.
Bon apparemment j'ai tout compris de travers si ton souci porte en fait
sur les accès "alternatifs" et non les accès "natifs", arf !
Bon l'explication sur les encodages MySql pourra peut-être servir à
quelqu'un...
Bon apparemment j'ai tout compris de travers si ton souci porte en fait sur les accès "alternatifs" et non les accès "natifs", arf ! Bon l'explication sur les encodages MySql pourra peut-être servir à quelqu'un... Côme, Clairinfo.
Roumeg
Côme a exprimé avec précision :
Bon apparemment j'ai tout compris de travers si ton souci porte en fait sur les accès "alternatifs" et non les accès "natifs", arf ! Bon l'explication sur les encodages MySql pourra peut-être servir à quelqu'un... Côme, Clairinfo. --- Cet email a fait l'objet d'une analyse antivirus par AVG. http://www.avg.com
merci de ta réponse en fait avec les accès alternatifs ça ne peut pas le faire il faudrait modifier le code C car les chaines sont déclarées en ASCIIZ avec l'accès de pcsoft je m'en suis sorti mais à savoir aussi que les fns xls de pcsoft ne gèrent pas ces caractères
Côme a exprimé avec précision :
Bon apparemment j'ai tout compris de travers si ton souci porte en fait sur
les accès "alternatifs" et non les accès "natifs", arf !
Bon l'explication sur les encodages MySql pourra peut-être servir à
quelqu'un...
Côme, Clairinfo.
---
Cet email a fait l'objet d'une analyse antivirus par AVG.
http://www.avg.com
merci de ta réponse
en fait avec les accès alternatifs ça ne peut pas le faire
il faudrait modifier le code C
car les chaines sont déclarées en ASCIIZ
avec l'accès de pcsoft je m'en suis sorti
mais à savoir aussi que les fns xls de pcsoft ne gèrent pas ces
caractères
Bon apparemment j'ai tout compris de travers si ton souci porte en fait sur les accès "alternatifs" et non les accès "natifs", arf ! Bon l'explication sur les encodages MySql pourra peut-être servir à quelqu'un... Côme, Clairinfo. --- Cet email a fait l'objet d'une analyse antivirus par AVG. http://www.avg.com
merci de ta réponse en fait avec les accès alternatifs ça ne peut pas le faire il faudrait modifier le code C car les chaines sont déclarées en ASCIIZ avec l'accès de pcsoft je m'en suis sorti mais à savoir aussi que les fns xls de pcsoft ne gèrent pas ces caractères
