Discussion :

[joefou]

Salut à tous !

J'avais un petit soucis d'encodage du texte sur certaines de mes instances. Je dispose d'une petite application qui entre autres, remplit un champ de type "Text". Lorsque je saisissais des caractères accentués, je me retrouvait dans les champs de la base avec des caractères inintelligibles lorsque je contrôlais par le biais de l'enterprise manager (le pb ne vient pas de l'appli, j'ai vérifié, ça fonctionne sur d'autres postes avec le même paramétrage régional).
Donc je souhaitais savoir si il était possible de connaitre le type d'encodage appliqué à la base (unicode, utf-8, etc...), si toutefois cela était possible

D'avance merci !

[f_bobo]

Salut,

Dans l'enterprise manager, un clic droit sur la base, propriété te donne toutes les infos de cette base. Dans le bas figure la collation style Latin1 ou autre.


Cordialement,

Florent

[joefou]

Merci f_bobo,

J'ai un truc du genre "French_CI_AS", mais c'est une dénomination propre à SqlServer je pense... Existe-t'il un tableau de corrélation entre ces indications de "classements" (collations) et des dénominations comme UTF-7, UTF-8, iso-8859-1, ou autres ? de cette façon il me serait possible de forcer le type de codage pour les applis externes (exe, pages php, etc...)
Je n'ai pas trouvé ça dans la doc...

[philodido]

Pas de réponse ... depuis le temps ... dommage ça m'intéressait aussi car j'ai le même problème. Si quelqu'un a la réponse n'hésitez surtout pas .

[SQLpro]

Dans un SGBDR on travaille au niveau logique et non pas au niveau physique. La notion de jeu de caractères n'est pas importante. C'est la notion de collation qui domine ainsi que la notion de type de données.
Par exemple le type char/varchar est en ASCII. Le type NCHAR/NVARCHAR est en UNICODE.
Pour le type ASCII, la collation va impliquer un jeu de caractères sous-jacent.
En résumé, la page de code est fonction de la collation... Si vous connaissez la collation, alors vous saurez quelle est la page de code.
Pour UNICODE, il n'y a pas de page de code !

http://technet.microsoft.com/fr-fr/l...QL.100%29.aspx

En particulier l'encodage des données en UTF 8 est une très mauvaise idée, car cela a un impact extrêmement négatif sur les performances.
C'est pourquoi SQL Server ne pratique pas ce type d'encodage !

A +

[philodido]

ok, merci de ta réponse à part que je me serais bien passé des : '!' car je trouve que ça fait donneur de leçon. De toute façon je pense que mon pb ne vient pas de la base.

[SQLpro]

Vous avez raison, c'est rarement un problème de SGBDR l'encodage. C'est souvent un problème liés aux différentes couches applicatives !

A +

[philodido]

ok ! encore merci !.
J'avais pas vu le "enseignant au cnam", donc le coté "!" donneur de leçons est tout à fait normal !

[SQLpro]

En fait c'est plus méchant que ça... Je me suis aperçu qu'il était préférable de jouer les Terminator que les héroïnes de la série Harlequin... On accorde plus d'attention aux gens qui cognent, qu'à ceux qui caressent !

A +

[philodido]

Certes je te comprend, mais peut être qu'il faut être un peu moins systématique.
Et ne pas cogner tout le monde d'entrée .

Sinon à part ça, problème résolue : il fallait configurer le pilote FreeDTS qui sert à se connecter sur sqlserver à partir du LAMP.
Dans etc/freedts/freedts.conf il faut rajouter : "client charset = ISO-8859-15"