web-dev-qa-db-fra.com

Problème de NodeJS avec utf8_general_ci

J'ai un site Web avec un système de chat. Ce système de chat a une table "messages" et l'une des colonnes est "messagetext" définie sur utf8_general_ci (MySQL). Dans mon site Web, j'utilise php pour interroger la base de données. Les résultats sont corrects.

Dans mon application, j'utilise NodeJS comme backend mais les résultats sont comme ça: "Î ± σδΠ± σδ". Il y a des mots grecs stockés dans cette colonne.

J'ai essayé iconv-lite, iconv, utf8, décoder Json.

Ma pensée, dans le site Web, il obtient la valeur "Î ± σδΠ± σÎ" de la colonne et du décodage vers utf8, c'est comment puis-je voir les bons résultats. MAIS dans l'application, cela ne se produit pas, les résultats sont la valeur au lieu du mot réel.

Que puis-je faire?

(extrait du commentaire)

CREATE TABLE messages (
    id int(11) NOT NULL AUTO_INCREMENT, 
    sender int(11) NOT NULL, 
    reciever int(11) NOT NULL, 
    seen varchar(3) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 'no', 
    datetime datetime NOT NULL, 
    messagetext text NOT NULL, 
    userseen varchar(3) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 'no', 
    PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=94 DEFAULT CHARSET=utf8
mysqlqueryjson
3
Bill

node.js a besoin de quelque chose comme ça pour commencer:

var connection = mysql.createConnection({ ... , charset : 'utf8'});

Ouais, ασδασδ me semble grec. Ce que vous avez, c'est "Mojibake". Voir https://stackoverflow.com/questions/38363566/trouble-with-utf8-characters-what-i-see-is-not-what-i-stored pour une discussion sur les causes de Mojibake.

N'utilisez aucune forme d'encodage/décodage/conv - cela ne fait qu'aggraver le problème. Si ce lien ne vous aide pas, fournissez les détails supplémentaires demandés.

Voir aussi https://www.npmjs.com/package/utf8

Le formulaire doit mentionner utf-8:

<form method="post" action="/your/url/" accept-charset="UTF-8">

Une analyse...

'Κ' (Kappa grec) est le 2 octets, hex 'CE9A', dans utf8. 'Κ' en latin1 est hexadécimal 'CE9A' (2 octets) 'Κ', s'il est converti en utf8 est hexadécimal 'C38E C5A1' 'ÃŽÅ¡' est celui qui ressemble à interprété comme latin1.

Remarque: ce dernier hex est ce que vous montrez dans votre commentaire.

Donc, vous semblez avoir un "double encodage".

SELECT CONVERT(BINARY(CONVERT(CONVERT(BINARY(CONVERT('ÃŽÅ¡' USING latin1)) USING utf8mb4) USING latin1)) USING utf8mb4);  --> 'Κ'

Ce qui manque, c'est où "latin1" se produit dans le flux des données.

1
Rick James