Quelle est la différence entre utf8_unicode_ci et utf8_general_ci dans MySQL ?

Le contenu de cet article porte sur quelle est la différence entre utf8_unicode_ci et utf8_general_ci dans Mysql ? Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

Quelle est la différence entre utf8_general_ci et utf8_unicode_ci dans Mysql ? Dans les langages de programmation, l'Unicode est généralement utilisé pour traiter les caractères chinois afin d'éviter les caractères tronqués. Ainsi, dans MySQL, pourquoi tout le monde utilise-t-il utf8_general_ci au lieu de utf8_unicode_ci ?

Après l'avoir utilisé pendant si longtemps, j'ai découvert que je ne connaissais même pas la différence entre utf_bin et utf_general_ci. .
ci n'est pas sensible à la casse, c'est-à-dire "insensible à la casse", a et A seront traités de la même manière dans le jugement des caractères ;
bin est binaire, a et A seront traités différemment
Par exemple, si vous exécutez :
SELECT * FROM table WHERE txt = 'a'
Alors vous ne trouverez pas la ligne avec txt = 'A' dans utf8_bin, mais utf8_general_ci le peut.
utf8_general_ci n'est pas sensible à la casse. Vous l'utiliserez lors de l'enregistrement de votre nom d'utilisateur et de votre adresse e-mail.
utf8_general_cs est sensible à la casse. Si vous l'utilisez pour le nom d'utilisateur et l'e-mail, cela aura des conséquences néfastes.
utf8_bin : chaque chaîne est compilée et stockée avec des données binaires. Il est sensible à la casse et peut stocker du contenu binaire

1. Description officielle du document
Ce qui suit est un extrait du manuel chinois Mysql 5.1 sur utf8_unicode_ci et utf8_general_ci :

Actuellement, la règle de classement utf8_unicode_ci ne prend en charge que partiellement l'algorithme de règle de classement Unicode. Certains caractères ne sont toujours pas pris en charge. De plus, les jetons combinés ne sont pas entièrement pris en charge. Cela concerne principalement certaines langues minoritaires au Vietnam et en Russie, telles que : l'Oudmourte, le Tatar, le Bachkir et le Mari.

La principale caractéristique de utf8_unicode_ci est de prendre en charge l'expansion, c'est-à-dire lorsqu'une lettre est considérée comme égale à d'autres combinaisons de lettres. Par exemple, « ß » équivaut à « ss » en allemand et dans d’autres langues.

utf8_general_ci est une règle de classement héritée et ne prend pas en charge les extensions. Il n'est capable que de comparaisons caractère par caractère. Cela signifie que les comparaisons effectuées par le classement utf8_general_ci sont rapides, mais moins précises que celles utilisant le classement utf8_unicode_ci).

Par exemple, en utilisant les deux règles de classement utf8_general_ci et utf8_unicode_ci, les comparaisons suivantes sont égales :
Ä = A
Ö = O
Ü = U

L'un des les deux règles de classement La différence est que pour utf8_general_ci l'équation suivante est vraie :
ß = s

Cependant, pour utf8_unicode_ci l'équation suivante est vraie :
ß = ss

pour un langage Les règles de classement du jeu de caractères utf8 spécifiques à la langue sont appliquées uniquement lorsque le tri à l'aide de utf8_unicode_ci ne fonctionne pas correctement. Par exemple, pour l'allemand et le français, utf8_unicode_ci fonctionne très bien, il n'est donc pas nécessaire de créer des règles de classement utf8 spéciales pour ces deux langues.

utf8_general_ci fonctionne également avec l'allemand et le français, sauf que 'ß' est égal à 's', pas 'ss'. Si votre application peut accepter cela, vous devez utiliser utf8_general_ci car c'est rapide. Sinon, utilisez utf8_unicode_ci car c'est plus précis.

Si vous souhaitez utiliser l'encodage gb2312, il est recommandé d'utiliser latin1 comme jeu de caractères par défaut de la table de données, afin de pouvoir insérer directement des données dans l'outil de ligne de commande en chinois et les afficher directement. N'utilisez pas gb2312 ou gbk et d'autres jeux de caractères. Si vous vous inquiétez du tri des requêtes et d'autres problèmes, vous pouvez utiliser des contraintes d'attributs binaires, telles que :

create table my_table ( name varchar(20) binary not null default '')type=myisam default charset latin1;

2. Bref résumé
utf8_unicode_ci et utf8_general_ci pour le chinois et l'anglais Il n'y a pas de réelle différence.
utf8_general_ci est rapide en relecture, mais légèrement moins précis.
utf8_unicode_ci a une grande précision, mais la vitesse de vérification est légèrement plus lente.

Si votre candidature est en allemand, français ou russe, veillez à utiliser utf8_unicode_ci. Généralement, il suffit d'utiliser utf8_general_ci, et aucun problème n'a été trouvé jusqu'à présent. . .

3. Résumé détaillé

1 Pour une langue, ce n'est que lorsque le tri utf8_unicode_ci n'est pas bien effectué que la relecture du jeu de caractères utf8 lié à la langue spécifique sera effectuée. règle exécutée. Par exemple, pour l'allemand et le français, utf8_unicode_ci fonctionne très bien, il n'est donc pas nécessaire de créer des règles de classement utf8 spéciales pour ces deux langues.
2. utf8_general_ci est également applicable à l'allemand et au français, sauf que « ? » est égal à « s », et non à « ss ». Si votre application peut accepter cela, vous devez utiliser utf8_general_ci car c'est rapide. Sinon, utilisez utf8_unicode_ci car c'est plus précis.

Utilisez une phrase pour résumer le paragraphe ci-dessus : utf8_unicode_ci est plus précis et utf8_general_ci est plus rapide. Dans des circonstances normales, la précision de utf8_general_ci est suffisante pour notre utilisation. Après avoir lu de nombreux codes sources de programmes, j'ai découvert que la plupart d'entre eux utilisent également utf8_general_ci, donc lors de la création d'une nouvelle base de données, utf8_general_ci est généralement utilisé

4. Comment utiliser UTF8 dans MySQL5.0
Ajoutez les paramètres suivants dans my.cnf

[mysqld]
init_connect='SET NAMES utf8′
default-character-set=utf8
default-collation = utf8_general_ci

Exécutez la requête mysql> 🎜 >

character_set_client | utf8 
character_set_connection | utf8 
character_set_database | utf8 
character_set_results | utf8 
character_set_server | utf8 
character_set_system | utf8

À mon avis personnel, pour l'utilisation des bases de données, utf8 - général est suffisamment précis et présente des avantages en termes de vitesse par rapport à utf8 - unicode, vous pouvez donc l'utiliser en toute confiance

collation_connection | utf8_general_ci 
collation_database | utf8_general_ci 
collation_server | utf8_general_ci

附1：旧数据升级办法

以原来的字符集为latin1为例，升级成为utf8的字符集。原来的表: old_table (default charset=latin1)，新表：new_table(default charset=utf8)。

第一步：导出旧数据

mysqldump --default-character-set=latin1 -hlocalhost -uroot -B my_db --tables old_table > old.sql

第二步：转换编码(类似unix/linux环境下)

iconv -t utf-8 -f gb2312 -c old.sql > new.sql

或者可以去掉 -f 参数，让iconv自动判断原来的字符集

iconv -t utf-8 -c old.sql > new.sql

在这里，假定原来的数据默认是gb2312编码。

第三步：导入

修改old.sql，在插入/更新语句开始之前，增加一条sql语句： "SET NAMES utf8;"，保存。

mysql -hlocalhost -uroot my_db < new.sql

大功告成！！

附2：支持查看utf8字符集的MySQL客户端有
1.) MySQL-Front，据说这个项目已经被MySQL AB勒令停止了，不知为何，如果国内还有不少破解版可以下载（不代表我推荐使用破解版 :-P）。
2.) Navicat，另一款非常不错的MySQL客户端，汉化版刚出来，还邀请我试用过，总的来说还是不错的，不过也需要付费。
3.) PhpMyAdmin，开源的php项目，非常好。
4.) Linux下的终端工具（Linux terminal），把终端的字符集设置为utf8，连接到MySQL之后，执行 SET NAMES UTF8; 也能读写utf8数据了。

本篇文章到这里就已经全部结束了，更多其他精彩内容可以关注PHP中文网的MySQL视频教程栏目！

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!