Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Applications Applications Emacs Problème d'encodage des résultats de requêtes envoyées à ma base MySQL.

Problème d'encodage des résultats de requêtes envoyées à ma base MySQL.

3 réponses
Avatar
valrik
Bonjour à tous,
Bon, je me suis imposé un objectif moins ambitieux en revenant au b.a.ba
des manipulations de ma base MySQL à partir de mon client Emacs... J'ai
nommé le mode SQL.
C'est un shell rudimentaire, mais dans l'ensemble, cela fonctionne bien
: je me connecte, même à distance, je peux faire des requêtes, etc...
Seul problème, c'est que les caractères accentués sont mal affichés. Par
exemple, les "é" sont affichés "é". Voici un extrait d'un résultat :

| 4 | Mail |
| 20 | Modification des droits |
| 33 | Multimédia |
| 13 | Pointeur / référence |

Cela me fiche un sacré bazare dans mes colonnes !

J'ai essayé pas mal de manipulations, mais rien n'y fait.

Quand je tape C-h C RET, j'ai :
Coding system for saving this buffer:
Not set locally, use the default.
Default coding system (for new files):
U -- utf-8-unix (alias: mule-utf-8-unix)

Coding system for keyboard input:
U -- utf-8-unix (alias: mule-utf-8-unix)

Coding system for terminal output:
U -- utf-8 (alias: mule-utf-8)

Coding system for inter-client cut and paste:
nil
Coding systems for process I/O:
encoding input to the process: U -- utf-8-unix (alias: mule-utf-8-unix)

decoding output from the process: U -- utf-8-unix (alias: mule-utf-8-unix)

Defaults for subprocess I/O:
decoding: U -- utf-8-unix (alias: mule-utf-8-unix)

encoding: U -- utf-8-unix (alias: mule-utf-8-unix)


Priority order for recognizing coding systems when reading files:
1. utf-8 (alias: mule-utf-8)
2. iso-2022-7bit
3. iso-latin-1 (alias: iso-8859-1 latin-1)
4. iso-2022-7bit-lock (alias: iso-2022-int-1)
5. iso-2022-8bit-ss2
6. emacs-mule
7. raw-text
8. iso-2022-jp (alias: junet)
9. in-is13194-devanagari (alias: devanagari)
10. chinese-iso-8bit (alias: cn-gb-2312 euc-china euc-cn cn-gb gb2312)
11. utf-8-auto
12. utf-8-with-signature
13. utf-16
14. utf-16be-with-signature (alias: utf-16-be)
15. utf-16le-with-signature (alias: utf-16-le)
16. utf-16be
17. utf-16le
18. japanese-shift-jis (alias: shift_jis sjis)
19. chinese-big5 (alias: big5 cn-big5 cp950)
20. undecided

Other coding systems cannot be distinguished automatically
from these, and therefore cannot be recognized automatically
with the present coding system priorities.

Particular coding systems specified for certain file names:

OPERATION TARGET PATTERN CODING SYSTEM(s)
--------- -------------- ----------------
File I/O "\\'control\\'" deb-view-control-coding
"/debian/\\([a-z0-9.+-]+\\.\\)?changelog\\'"
.....
.....
.....
"\\.\\(tex\\|ltx\\|dtx\\|drv\\)\\'"
latexenc-find-file-coding-system
"" (undecided)
Process I/O nothing specified
Network I/O nothing specified

Je précise également que mes tables sont aussi encodées en utf-8.
Signaler un problème avec ce contenu

3 réponses

Supprimer
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
Avatar
valrik
Bon, je me suis emmêlé les crayons avec l'encodage. Encore ! :-(
En fait, tout les accents sont affichés sous la forme "xxx", où x est
un chiffre. Par exemple, "é" est remplacé par "351".
Avatar
valrik
J'ai un peu avancé grâce à la documentation d'Emacs. Dans le chapitre de
l'internationalisation, j'ai trouvé une commande qui permet de convert ir
le flux d'entrée d'un sous processus en un autre encodage pour sa
sortie.
Il s'agit de C-x RET p input-coding RET output-coding RET. Et comme je
me doutais qu'il y avait un problème avec l'ancien encodage latin-1
(351 à la place d'un "é" est typique), j'ai essayé :
C-x RET p latin-1 RET utf-8 RET
Et là, miracle ! tout s'affiche correctement. Avec un bémol toute fois,
les requêtes avec des accents dans les chaînes à rechercher retournent
systématiquement un résultat nul.

En fouillant dans le documentation MySQL, je suis en mesure d'afficher
les variables du serveur :
mysql> show variables like 'char%' ;
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

mysql>

Effectivement, si mes tables de cette base sont bien en utf-8, mon
serveur me répond en latin1, d'où le problème. A remarquer q ue d'autres
bases ne sont pas en utf-8.

A un moment donné, j'ai tenté de configurer mon serveur en utf-8. Tout
est passé en utf-8, sauf character_set_database et
character_set_filesystem qui sont restées identiques. C'est normal pour
character_set_filesystem, mais pas pour character_set_database qui
aurait dû passer en utf-8. Dans ce cas, sans intervention particulià ¨re,
les accents des résultats de requêtes s'affichent correctement.

Par contre,un phénomène bizarre se produit : à chaque accent affiché, la
colonne de droite se décale d'un caractère vers la gauche!

Y a-t-il moyen de savoir exactement ce que le serveur envoie à Emacs ?
Une sorte de débugueur d'encodage, parce que là, je nage complà ¨tement.
:-(
Avatar
valrik
valrik writes:

Et là, miracle ! tout s'affiche correctement. Avec un bémol tou tefois,
les requêtes avec des accents dans les chaînes à recherche r retournent
systématiquement un résultat nul.


Tiens, je viens de résoudre mon problème :-)
Il suffit de taper C-x RET p latin-1 RET latin-1 RET, ce qui est logique
puisque le serveur "écoute" et "cause" en latin-1.

Reste l'utf-8 tout de même.