这个主要原因其实和字符集有关，不同字符集下会不一样

　　历史原因的Oracle中

　　有人问我他遇到一个问题，就是醒目录入后有乱码的出现。而出现乱码的地方是维族的名字中间的 •。比如迪丽热巴·迪力木拉提 。

　　实验如下

　　注意1这条数据是用标准的点。而2这里的这个点其实是不标准的。不是字符集中的。写入可以写入。而3这条数据是我输入的英文输入法下的句号。

　　最后输出的结果是：

　　可以看出3条都是不一样的。而第二条直接是乱码。这就是开发同学反馈的问题。

　　那这三个分别是怎么来的？

　　对照编码表可以看到 46是句号，而63就是问号（因为无法识别，存储进来就有问题了）。

　　那么怎么解决呢？

　　转换读

　　对于已知的乱码符号进行转换

　　这种属于亡羊补牢的做法。我本人更加建议是在写入时候控制好。因为不能前面任意写入（注意这里是写入不是输入），输入要统一。之前有一个系统输入企业名称。

　　有的是 XX（中国）有的是XX(中国)最终在数据库中为了找得到，就是要把全角半角的都去查，把给整个字段上套上函数。无论等号左边还是右边。这样的结果就是索引失效，全表扫描。

　　转换写

　　其实录入时候你可以运行他自由输入，但是写入时候要程序转换为统一的。我之前做公安系统的时候就是页面输入后，点击保存的时候，全部转换成统一的全角格式。（其实只要统一一种约定俗成就行）例如这样：

　　而以上的问题在UTF8这上没有出现。拿一个MySQL的数据库实验。

　　最后小结：要么是选好字符集。要么是写入时候统一处理。

　　对于历史数据可以执行一次数据清洗。最好不要带着各种不同格式，在查询时候去转换。

　　所有的工作做在前面的工序中。而不是最后一道工序撑起所有的漏洞。