我已经转储了我的小型MySQL表(手动进行缩小以定位问题)以在此处显示:
SET SQL_MODE ="NO_AUTO_VALUE_ON_ZERO";
SET time_zone ="+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
CREATE TABLE `symb` (
`smb` varchar(200) NOT NULL,
`trtmnt` varchar(200) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `symb` (`smb`, `trtmnt`) VALUES
('?', 'ty'),
('?', 'hr');
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
如果您在上面创建MySQL表并运行此查询
或与此(查询有所不同-请参见符号"?"与"?")
那么您可能会看到选择了两行,而不是我期望的那样。
再次强调一下,以上两个选择查询是不同的-符号"?"与"?"不同(两者都是西里尔文符号,此处不是拉丁字母"?")。
Collation chosen was utf8_general_ci
任何原因为何?和'?'被视为相同的符号,使其与众不同的正确方法是什么?我需要选择确切的行,而不是两行。
上面的查询已在phpMyAdmin和HeidiSQL中进行了测试,这意味着MySQL(排序规则?)问题,而不是用于运行查询的程序。
每个不同的符号应被视为一个不同的符号,并且表应区分大小写。上表有什么问题?结果,我无法为此行设置唯一键。
谢谢。
根据评论添加:
像" symb"一样,SHOW TABLE STATUS向您显示什么?
它显示了我:
Name symb
Engine InnoDB
Version 10
Row_format Compact
Rows 2
Avg_row_length 8192
Data_length 16384
Max_data_length 0
Index_length 0
Data_free 0
Auto_increment NULL
Create_time 22.05.16 12:11
Update_time NULL
Check_time NULL
Collation utf8_general_ci
Checksum NULL
Create_options
Comment
SHOW TABLE STATUS LIKE symb向您显示什么?
在每列中制作utf8_general_ci
@TimBiegeleisen,我已在问题末尾附上我的表格结果,将问题的答案发布了。 谢谢。
另一个问题:在插入有问题的两条记录之前,此表是否已被UTF-8编码?
@TimBiegeleisen不确定您对这个问题的回答...您是不是如上所述在CREATE TABLE symb中表示这段代码CHARSET = utf8? 然后我猜答案是肯定的-请在上面的创建表中查看utf8。 这个对吗? 谢谢。
这就是您选择的排序规则的工作方式。您可以在此处查看更多信息:https://stackoverflow.com/a/1036459/4099089
谢谢你的链接。 我对,建议的表格应该是utf8_unicode_ci吗? 我是否应该在不转换现有表的情况下创建COMPLETELY新表? 两个问题的建议答案是否都是? 谢谢。
米莎? ,Ive遵循了您的建议-从utf8_unicode_ci开始。 有问题吗? 与? 解决。 出现了另一个类似的问题-相同的问题? 与г。 任何想法如何解决? 谢谢。
对不起,但我不知道。 我会查看其他归类,并尝试在线检查是否有关于您的语言的最佳归类的建议。
@Haradzieniec您是否解决了一个问题? vsг?
因为您的SELECT语句返回了两个记录,所以看来您的数据已被错误地编码为UTF-8。因此,仅将smb列的编码从Latin1更改为UTF-8是行不通的。一种选择是将数据库转储为二进制文件,然后将其重新导入为UTF-8:
mysqldump --add-drop-table your_database | replace CHARSET=latin1 CHARSET=utf8 |
iconv -f latin1 -t utf8 | mysql your_database
在此处和此处阅读以获取更多信息。
你要哪个?
D197 1111=x0457 [?] L CYRILLIC SMALL LETTER YI
C3AF 239=x00EF [?] L LATIN SMALL LETTER I WITH DIAERESIS
如果执行SELECT col, HEX(col) ...,则对于正确存储的YI或i-umlaut,应该得到D197或C3AF。这是判断它是否正确存储为utf8(或utf8mb4)的最佳方法。
它们看起来相同,但是区别对待。所有utf8 / utf8mb4归类将所有西里尔字母排在所有拉丁字母之后。
"最佳""常规"整理是utf8mb4_unicode_520_ci。 (如果不需要中文或表情符号,可以使用utf8而不是utf8mb4。)
这是我对西欧字符在各种utf8 / utf8mb4归类中的比较方式的总结。例如,在所有其他l值之后,utf8_spanish2_ci是唯一将ll视为"单独字符"的代码。 utf8_latvian_ci将?和?作为单独的字母处理。等等。
SHOW TABLE STATUS显示表的默认值;您需要查看SHOW CREATE TABLE以查看是否有任何列覆盖该默认值。
非常感谢您的帖子。 我选择了utf8_bin,对于我的情况来说,这似乎是可以接受的解决方案。
我已通过以下方式解决了此问题:
1)将表排序规则更改为utf8mb4_unicode_520_ci
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci
这使您可以在乌克兰字母中插入除?以外的所有字母。
这也使您可以按照预期的方式对字母进行排序。
2)将列排序规则更改为utf8mb4_bin
ALTER TABLE table_name MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
这可以让您插入吗?字符。
*此方法的唯一缺点是排序时必须使用
SELECT * FROM table_name ORDER BY column_name COLLATE utf8mb4_unicode_520_ci ASC
但是仍然无法对DESC进行排序