2010-07-20 9 views
4

Ainsi, j'ai eu quelques problèmes en essayant de venir de Latin1 bases de données encodées, tables aussi bien que des colonnes, et maintenant que tout est finalement en UTF-8 , Je n'arrive pas à mettre à jour une ligne dans une colonne. J'essaie de remplacer un "e" par un e avec aigu (é). Mais il me donne ceci:Les caractères spéciaux ne fonctionneront pas dans MySQL (UTF-8)

erreur 1366 (HY000): Valeur de chaîne incorrecte: '\ x82m ...' pour la colonne 'Nom' à la ligne 1

lors de l'exécution de cette:

UPDATE access SET Name='ém' WHERE id="2";

Toutes les bases de données me donne ce lors de l'exécution de la commande d'état (à l'exception de la partie current database bien sûr):


Connection id:   1 
Current database:  access 
Current user:   [email protected] 
SSL:     Not in use 
Using delimiter:  ; 
Server version:   5.1.47-community MySQL Community Server (GPL) 
Protocol version:  10 
Connection:    localhost via TCP/IP 
Server characterset: utf8 
Db  characterset: utf8 
Client characterset: utf8 
Conn. characterset: utf8 
TCP port:    3306 
Uptime:     20 min 16 sec 

Threads: 1 Questions: 110 Slow queries: 0 Opens: 18 Flush tables: 1 Open tables: 11 Queries per second avg: 0.90 

Et exécutant la commande cmd chcp me donne 850. Oh, et à quelques points que je suis ceci:

erreur 1300 (HY000): non valide chaîne de caractères UTF8: 'ém' WHERE id = "2"

Je l'ai cherché partout une solution , mais je n'arrivais pas à trouver quoi que ce soit, et comme j'ai toujours eu de bonnes réponses sur Stackoverflow, j'ai pensé que je demanderais ici.

Merci pour toute aide!

+0

Quel client vous utilisez pour exécuter vos requêtes sur MySQL? –

+0

J'utilise le client de ligne de commande. – Nisto

Répondre

3

This thread, quoique un peu vieux, semble aboutir à la conclusion que cmd.exe et le client mysql ne gèrent pas correctement l'encodage UTF-8 (le blame étant plus axé sur cmd.exe).

La lecture en SQL à partir d'un fichier est recommandée, tout comme l'utilisation d'un autre client - ou d'une version d'UNIX. :)

+1

Eh bien, cela répond à la question. Je l'ai couru à partir d'un fichier, et cela a fonctionné. Cependant, les requêtes envoyées à partir du code PHP sur mon site seront-elles unicode? J'ai également défini les jeux de caractères dans Apache et PHP sur UTF-8. Oh, et y at-il une autre option que je peux utiliser au lieu d'importer le code d'un fichier? – Nisto

+0

Content de l'entendre, Nisto. En ce qui concerne les autres options - une interface MySQL décente serait un bon investissement si vous souhaitez exécuter des requêtes UTF-8 ad hoc - vous pourriez probablement ajouter quelque chose dans VS.Net si vous avez une expérience de programmation. J'espère que Apache/PHP fonctionnera bien - que vous les ayez configurés ou avec quelques réglages - si UTF-8 ne fonctionne pas avec ces derniers alors quelque chose ne va pas dans le monde! –

+0

Oui! Je n'ai jamais su qu'une telle chose existait, mais j'ai juste trouvé 'HeidiSQL' et j'adore ça. Haha, les lignes de montage sont devenues beaucoup plus rapides aussi. Merci pour votre réponse! – Nisto

0

Lorsque vous saisissez des éléments sur la ligne de commande, les chaînes sont dans le jeu de caractères utilisé par le terminal. Pourquoi le client mysql ne traduit pas cela avant de l'envoyer à la base de données me laisse toujours perplexe, mais ce n'est pas le cas. Vous envoyez probablement latin1 à la base de données.

Vous pouvez enregistrer votre SQL de mise à jour dans un fichier texte, assurez vous ce fichier texte est UTF-8, et exécuter quelque chose comme type myfile.txt | mysql db_name

+0

Je regarde cela dans Windows. 'cmd.exe' fait des suppositions quand il s'agit de canaliser des informations. Je pense que mysql --database = db_name --execute "SOURCE myfile.txt" 'est probablement plus sûr. Il y a une mention de ceci quelque part dans la documentation mais je n'arrive pas à la trouver pour le moment. –

+0

Oh, et le client mysql transcodera pour vous si le jeu de caractères du client et le jeu de caractères du serveur diffèrent. Le code est enterré dans "client/sql_string.cc" si vous êtes intéressé. –

0

Eh bien ... 0x82 est e-aiguë dans la page de code 850. Ce serait 0xE9 dans ISO-8859-1 ce qui en fait quelque chose comme 0xD0 0xB4 en UTF-8. Je ne sais pas s'il existe un bon moyen d'obtenir une fenêtre DOS pour gérer correctement l'entrée UTF-8. Voici une alternative si vous utilisez le client en ligne de commande. Vous pouvez définir le caractère client réglé pour correspondre quel que soit votre page de code local est et laissez vous prendre soin de la bibliothèque mysql du transcoder:

c:\> mysql --default-character-set=cp850 
mysql> \s 
-------------- 
mysql Ver 14.14 Distrib 5.1.34, for apple-darwin9.6.0 (i386) using readline 5.2 

Connection id:   17 
Current database: 
Current user:   [email protected] 
SSL:     Not in use 
Current pager:   stdout 
Using outfile:   '' 
Using delimiter:  ; 
Server version:  5.1.34-log Source distribution 
Protocol version:  10 
Connection:   localhost via TCP/IP 
Server characterset: ucs2 
Db  characterset: ucs2 
Client characterset: cp850 
Conn. characterset: cp850 
TCP port:    3306 
Uptime:    19 days 8 hours 37 min 55 sec 

Threads: 2 Questions: 248 Slow queries: 0 Opens: 71 Flush tables: 1 Open tables: 64 Queries per second avg: 0.0 
-------------- 

Je sais que cela fonctionne pour la combinaison de latin1 dans une fenêtre et utf8 dans une autre fenêtre sur mon MacBook. J'ai également vérifié qu'un ALTER TABLE ... CONVERT TO CHARACTER SET ucs2 a fait la bonne chose.

4

La solution est de définir les variables de connexion à n'importe quel codepage que votre installation de windows utilise (pas latin1 comme ce que beaucoup de pages recommandent - le codage de caractères de cmd.exe n'est pas latin1).

Dans mon cas, la page de code est 850:

mysql> SET NAMES cp850;

Voici un exemple avec la connexion en UTF-8:

mysql> show variables like '%char%'; 
+--------------------------+---------------------------------+ 
| Variable_name   | Value       | 
+--------------------------+---------------------------------+ 
| character_set_client  | utf8       | 
| character_set_connection | utf8       | 
| character_set_database | utf8       | 
| character_set_filesystem | binary       | 
| character_set_results | utf8       | 
| character_set_server  | utf8       | 
| character_set_system  | utf8       | 
| character_sets_dir  | C:\xampp\mysql\share\charsets\ | 
+--------------------------+---------------------------------+ 
8 rows in set (0.00 sec) 

C'est ce qui arrive aux caractères accentués:

mysql> select nom from assignatura where nom like '%prob%'; 
+---------------------------------------+ 
| nom         | 
+---------------------------------------+ 
| Probabilitat i Processos Estocàstics | 
| Probabilitat i Processos Estocàstics | 
+---------------------------------------+ 
2 rows in set (0.03 sec) 

Notez les parasites caractère juste avant le á. Aussi l'accent est dans la mauvaise direction, il devrait être à.

Après l'exécution SET NAMES cp850;:

mysql> show variables like '%char%'; 
+--------------------------+--------------------------------+ 
| Variable_name   | Value       | 
+--------------------------+--------------------------------+ 
| character_set_client  | cp850       | 
| character_set_connection | cp850       | 
| character_set_database | utf8       | 
| character_set_filesystem | binary       | 
| character_set_results | cp850       | 
| character_set_server  | utf8       | 
| character_set_system  | utf8       | 
| character_sets_dir  | C:\xampp\mysql\share\charsets\ | 
+--------------------------+--------------------------------+ 
8 rows in set (0.00 sec) 

Nous obtenons enfin le caractère accentué correct:

mysql> select nom from assignatura where nom like '%prob%'; 
+--------------------------------------+ 
| nom         | 
+--------------------------------------+ 
| Probabilitat i Processos Estocàstics | 
| Probabilitat i Processos Estocàstics | 
+--------------------------------------+ 
2 rows in set (0.00 sec) 
Questions connexes