accès alternatif mysql

[Roumeg]

Bonjour,

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

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

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

[Roumeg]

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