|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité de passage
![]() Inscription : mars 2006 Messages : 12 ![]() |
Bonjour,
J'ai un problème avec les accents et les caractères spéciaux que j’extraie de l'AS400 via un pilote ODBC. J'ai l'impression qu'il faudrait que je change le CCSID (d'après ce que j'ai pu comprendre) mais je ne sais pas comment. Dans la configuration de mon pilote ODBC, la case "Conversion de données binaires (CCSID 65535) en texte" est coché. J'ai essayé de cocher la case "Remplacer la page de codes clients par : 1147" dans les options avancées, mais cela ne fonctionne pas. Merci pour vos conseils... Laurent |
|
|
00
|
|
|
#2 |
|
Invité de passage
![]() Inscription : mars 2006 Messages : 12 ![]() |
... je viens de trouver sur le net !
SELECT CAST(MBAXREP.AXHDTX AS CHARACTER(25) CCSID 1147) AS AXHDTX FROM AMFLIBX.MBAXREP AS MBAXREP ORDER BY MBAXREP.AXKBNB Ainsi, avec cette SQL, je récupère les accents et caractères spéciaux français. J'espère que cela pourra aider quelqu'un d'autre. Laurent |
|
|
00
|
|
|
#3 |
|
Membre confirmé
![]() Inscription : octobre 2006 Messages : 233 ![]() |
C'est étrange ton histoire. Je n'ai jamais eu ce problème.
Déjà il faut savoir dans quel CCSID ta table a été créée. 65535 sur le système veut dire pas de conversion. Mais ta table elle, a probablement un CCSID 297 ou 1147. Quelle version d'Series Access et quelle version de Service Pack ? Parce que faire des conversions directement dans le SQL, je trouve çà moyen... |
|
|
00
|
|
|
#4 |
|
Invité de passage
![]() Inscription : mars 2006 Messages : 12 ![]() |
Bonjour,
Merci pour tes commentaires. Alors la table en question (MBAXREP) a été créé dans le CCSID 65535 Ma version iSeries System i Access : Version 7 Edition 1 Niveau de modification 0 Mon service pack : Win 7 Professionnel Service Pack 1 J'avoue ne pas trop comprendre ces histoires de CCSID... Si la case "Conversion de données binaires (CCSID 65535) en texte" n'est pas coché alors tous les caractères deviennent illisible. Je suis preneur d'explications et autres solutions Merci Laurent |
|
|
00
|
|
|
#5 |
|
Membre chevronné
![]() Inscription : septembre 2008 Messages : 522 ![]() |
L'AS/400 code ses caractères en EBCDIC.
Mais selon la page de code (CCSID) les caractères ne sont pas codés avec les mêmes valeurs. Lorsque l'AS/400 affiche les données, il convertit les caractères pour les afficher normalement, sauf pour le CCSID 65535 qui signifie "Pas de conversion". Le PC fonctionne lui en ASCII. L'émulateur écran ou les programmes de transfert doivent donc convertir les pages de code plus convertir en ASCII. Exemple : Le blanc est codé x'40' en EBCDIC (dans tous les CCSID) mais x'20' en ASCII. Le "é" est codé x'C0' en page de code 297 (Francais) Il est codé x'51' en page de code 037 (USA/Canada) Supposons que un programme écrive un "é" américain dans une table avec CCSID 037 et que le programme iSeries Access est configuré CCSID 297 (Français) : Le code x'51' ("é" américain) devient x'C0' (CCSID 297) puis est converti en x'E9' ("é" en ASCII windows) Si la table est en CCSID 65535 : Le code x'51' ("é" américain) reste x'51' (65535=Ne pas convertir) puis est converti en x'7B' (x'51' ebcdic français = "{" = x'7B' sous windows. On a donc un "{" qui s'affiche. Si tu décoche "Convertir le CCSID 65535" : Le x'51' ("é" américain) reste x'51' (65535=Ne pas convertir) même sous windows (il affiche un Q) De même le blanc resterait en x'40' et afficherait des @ (x'40' en ASCII). Essaie de faire un CHGPF de ta table avec le paramètre CCSID correspondant à la page de code EBCDIC de tes caractères. Dans mon exemple, CHGPF matable CCSID(037) (dans l'exemple, on suppose un programme américain qui écrit dans ta table) Là tu devrais avoir tes caractères ! |
|
|
00
|
Copyright © 2000-2013 - www.developpez.com