眼见不肯定为实之MySQL中的不可见字符
目录
媒介
一、题目的由来
1、需求背景
2、数据表布局
二、定位题目
1、开端的题目
2、编码是否有题目
3、依然回到字符本身
三、深入字符本身
1、回归本质
2、数据库办理之道
3、代码层办理
四、总结
媒介
在开始今天的博客内容之前，正在看博客的您先来看看以下这两条sql，如果您刚好还有MySQL的环境。不妨先猜测一下它输出的内容，然后看看是否有什么区别？第一条sql如下：
select length('G30L3B01') as l1; 接着再来看另一条sql，sql脚本如下：
select length('G30L3B01') as l2; 各位不妨猜测一下，上面两条sql语句的执行结果l1和l2分别是多少？是不是在你的预料之中。 这里不卖关子了，相信执行过sql的朋侪肯定看到了结果。没有数据库客户端的朋侪来看我的执行结果。在给出结果之前，首先把底子环境介绍一下。这里的服务器用的的个人的Windows 7 专业版开发机，数据库服务用的是MySQL5.7，打开的查询服务窗口所在的数据库编码是UTF-8。
https://img-blog.csdnimg.cn/direct/1fc531b59e8e49a7b18742f726c813d4.png
上面这个结果有没有超出你的预想，这两个字符串“看”起来似乎是一模一样的。这里的“看”我打了引号，至于缘故原由，后面会讲到。本文即以上述场景为例，讲解在MySQL中，为什么会有这种“看”起来一致，但现实上不一样的题目，通过征象找本质，通过一步一步的排查，找到题目的根源，末了在寻根溯源后，找办理的办法；从应用代码编程的角度和底层数据库的角度来办理上述题目。如果您现在也碰到了这种“看”起来不正常的值，不妨一起交流一下。
一、题目的由来
首先依然要介绍一下上述题目的出现场景，以便于其它的朋侪在此情此景下，有更大的印象。因此本节首先将对题目的场景举行详细的描述。这里筹划从两个方面讲述，第一个方面是讲述需求背景，即在什么环境下作这个事。第二个是讲述数据背景，把相关的表设计也说明一下。
1、需求背景
事情发生的背景是如许的，客户要求我们做一个功能，他们会提供一个数据的Excel模板，然后我们需要将这些数据批量导入到数据库中。这个需求咋一看起来，是一个非常简朴的需求啊。读取Excel的依赖库，一大把。解析Excel的数据，然后批量插入到数据库中，对于MybatisPlus或者其它的ORM工具都是非常简朴的事。当时我们选择的是阿里巴巴开源的读取Excel的组件。感兴趣的朋侪可以本身上github搜索一下。然后也基于组件也已经将Excel没个表格都读取到了内存中，然后调用MP的批量插入方法，意外的是在举行批量插入的时间数据库报错了。下面还是将数据库的表先做一个介绍。
2、数据表布局
为了实现将数据导入到数据库中，根据面向对象的原则，我们将Excel表格中的每个单元格都设计成了一个字段，然后对字段的数据类型举行了设计，同时包罗数据长度。其中有一个项是输入数据的编码，然后用户是有编码规则的，每一个数据都有一个对应的编码规则。我们简朴的看了他们的编码规则，得知其长度大致为8位，因此我们在数据库中设计成了varchar(8)；这么设计实在是中规中矩的，非常合理。然而在上面的批量入库过程中就一直报对应的这个字段too long。这个非常看起来很奇怪，由于我们人工去“看”的时间，这个字符串的长度确实是8。于是陷入了沉思。
二、定位题目
既然在开发过程当中出现了题目，那么如何办理题目呢？在办理题目之前，首先要定位题目，只有准确的定位题目，才气对症下药，题目才气迎刃而解。因此本节将重点讲解怎么定位题目。
1、开端的题目
当看到上面题目的时间，第一感觉是懵的，刚开始都有点不敢相信本身的眼睛。由于肉眼根本“看”不出来这个字符串居然不是8位。最开始猜疑的是在字符串的前后大概存在空格，因此导致了其长度超出了8位。为此我们将数据举行去空，利用sql举行去空如下：
SELECT length('G30L3B01') AS VisibleLength,
length(replace('G30L3B01', '', '')) AS CleanLength; https://img-blog.csdnimg.cn/direct/0dfcfea49482497199bd6ec445ccce60.png
然后发现还是不对，经过替换后其长度还是11，说明还是超长了。
2、编码是否有题目
在举行空字符过滤之后还是没有办理题目。于是换了一个方向，想着有没有大概是字符集的题目。实在大家可以看看UTF-8的字符集规范，字符集虽然会有肯定的影响，但是这里存储的都是英文和数字，其长度均是尺度的1，因此不存在字符的题目。题目一下子没有了方向，不知道往哪个方面去排查。
3、依然回到字符本身
在第一次实验了空字符替换无果，又清除了字符编码的题目后，再一次将目光投入到字符本身。这一次的想法是，虽然空字符本文替换后，长度还是11，但是这并不说明其内容肯定是空格。有没有什么其它的东西在捣乱呢。偶然候找题目就是如许，反反复复。
三、深入字符本身
上面从几个方面分析了大概存在的题目，尤其是第三点，我们从最开的字符又回到了出发点。那么这次接纳什么分析思绪呢？本小节深入道来。
1、回归本质
为了来看看这个数据到底是什么？我们将字符串转为十六进制的字符串，通过比力原始字符串来看看区别。在MySQL中可以利用HEX(str)实现转换。相关的转换SQL如下所示：
SELECT HEX('G30L3B01') AS hex_representation,HEX('G30L3B01') as n2;
hex_representation n2
4733304C33423031 4733304C33EFBBBF423031 不知道眼尖的你发现了题目没有，上面这条SQL执行完之后发现，其目标字符串似乎不一样啊。后面的字符串，也就是有题目的字符串其长度真的超长了。下面仔细对比这两个字符串。
4733304C33 423031
4733304C33 EFBBBF 423031 为了方便展示，我把雷同的部门举行对比，我们发现，前面的字符经过十六进制的转换后，一共16个字节，8位。是符合我们的预期的，而下面的十六进制字符则多了6字节，一共22字节，记11位。这也就是为什么这两个字符串不一样的缘故原由。那么这个多出来的EFBBBF又是什么呢？由于这是转成了十六进制的表示，我们需要将其转为十进制。将十六进制转十进制，如果不想盘算的朋侪可以在网页中直接搜索：
https://img-blog.csdnimg.cn/direct/7705c84d079541f0ad92ee90300e7855.png
当然你也可以在MySQL中举行进制转换，转换方法如下：
-- CONVERT(CONV('EFBBBF', 16, 10), UNSIGNED) 是在mysql中实现将16进制转10进制数据
select length(char(15711167)),hex(char(15711167)),CONVERT(CONV('EFBBBF', 16, 10), UNSIGNED); 执行之后，可以看到：
length(char(15711167)) hex(char(15711167)) CONVERT(CONV('EFBBBF', 16, 10), UNSIGNED)
3 EFBBBF 15711167 到这里，为什么两个“看”起来一模一样的字符串，现实上不一样呢？根源就在这里，在字符串的中间位置插入了不可见字符。就是这不可见字符EFBBBF导致我们做数据插入时报too long。
2、数据库办理之道
在明确了以上的题目所在之后，我们就可以根据现实环境来举行调整。只要将这种不可见字符替换掉即可。实现的方式也很简朴，sql如下：
select length(REPLACE('G30L3B01', CHAR(15711167),''))t;
t
8 通过replace函数就实现了不可见字符EFBBBF的去除，如许再调用Insert语句，就不会报too long的题目。
3、代码层办理
除了在数据库层来办理题目，还可以在什么地方办理呢？在编码层办理是否可行。答案是肯定的。下面我们来详细介绍一下代码层的处理办法，以java语言为例。实在原理是一样的，都是要将不可见字符举行替换掉。
/*
* 字节数组转16进制字符串
*/
public static String bytesToHexString(byte[] bArr) {
if (bArr == null) {
return null;
}
StringBuffer sb = new StringBuffer(bArr.length);
String sTmp;
for (int i = 0; i < bArr.length; i++) {
sTmp = Integer.toHexString(0xFF & bArr);
if (sTmp.length() < 2)
sb.append(0);
sb.append(sTmp);
}
return sb.toString();
}
// 转化十六进制编码为字符串
public static String toStringHex(String s) {
byte[] baKeyword = new byte;
try {
for (int i = 0; i < baKeyword.length; i++) {
baKeyword = (byte) (0xff & Integer.parseInt(s.substring(i * 2, i * 2 + 2), 16));
}
s = new String(baKeyword, "utf-8");// UTF-16le:Not
} catch (Exception e1) {
e1.printStackTrace();
}
return s;
}
下面给出测试代码，您可以现实测试以下结果，看是否与我的预期一样：
public static void main(String[] args) {
System.out.println("G8014Z03".substring(0, 2));
System.out.println(bytesToHexString("G30L3B01".getBytes()).toUpperCase()); // 长
System.out.println(bytesToHexString("G30L3B01".getBytes()).toUpperCase()); // 短
System.out.println("G30L3B01".length()); // 长
System.out.println("G30L3B01".length()); // 短
System.out.println("进制转换======================================================");
System.out.println(toStringHex("4733304C33423031"));
System.out.println(toStringHex("4733304C33423031").length());
System.out.println(toStringHex("4733304C33EFBBBF423031"));
System.out.println(toStringHex("4733304C33EFBBBF423031").length());
System.out.println("================================================");
System.out.println(toStringHex("4733304C33EFBBBF423031".replaceAll("EFBBBF", "")));
System.out.println(toStringHex("4733304C33EFBBBF423031".replaceAll("EFBBBF", "")).length());
System.out.println("G30L3B01".equals("G30L3B01"));
System.out.println(toStringHex("4733304C33EFBBBF423031".replaceAll("EFBBBF", "")).equals("G30L3B01"));
} 在代码中利用上述代码也可以实现目标字符的替换，将不可见字符举行替换掉。欢迎在实践中举行测试利用。
四、总结
以上就是本文的主要内容，本文以数据库中不可见字符处理为例，讲解在MySQL中，为什么会有这种“看”起来一致，但现实上不一样的题目，通过征象找本质，通过一步一步的排查，找到题目的根源，末了在寻根溯源后，找到办理的办法；从应用代码编程的角度和底层数据库的角度来办理上述题目。
利用发起，如果您也有这方面的题目，尤其是从Excel或者其它的模板中导入数据的，很有大概会碰到这个题目。如果碰到看起来一致，但现实内容不一样的环境，可以试试看是不是碰到了不可见字符，本文即分享了一种在MySQL中的不可见字符的办理方案，同时分享了利用JAVA语言举行上述题目的办理。本文行文仓促，不免有不敷之处，欢迎各位专家朋侪在评论区批评指正，不慎感激。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]