在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
这两天在做PHP上传CSV文件的时候,第一列第一个值总是在正则验证不过。例如第一列第一个值是“test_test1”,第一列第二个值是"test_test2",没有本质差别的两个值对于同一个正则却给出了两个结果。在很纠结的时候用var_dump打印了一下两个值。居然发现显示的结果“test_test1”长度13,而"test_test2"长度10。为什么会有这个差别,在网上找了一段材料。才明白是BOM头的问题
BOM —— Byte Order Mark,中文名译作“字节顺序标记”。在这里找到一段关于 BOM 的说明: 在UCS 编码中有一个叫做 "Zero Width No-Break Space" ,中文译名作“零宽无间断间隔” 的字符,它的编码是 FEFF。而 FFFE 在 UCS 中是不存在的字符,所以不应该出现在实际传输中。UCS 规范建议我们在传输字节流前,先传输字符 "Zero Width No-Break Space"。这样如果接收者收到 FEFF,就表明这个字节流是 Big-Endian 的;如果收到FFFE,就表明这个字节流是 Little- Endian 的。因此字符 "Zero Width No-Break Space" (“零宽无间断间隔”)又被称作 BOM。 UTF-8 不需要 BOM 来表明字节顺序,但可以用 BOM 来表明编码方式。字符 "Zero Width No-Break Space" 的 UTF-8 编码是 EF BB BF。所以如果接收者收到以 EF BB BF 开头的字节流,就知道这是 UTF-8编码了。Windows 就是使用 BOM 来标记文本文件的编码方式的。 字符U+FEFF如果出现在字节流的开头,则用来标识该字节流的字节序,是高位在前还是低位在前。如果它出现在字节流的中间,则表达零宽度非换行空格的意义,用户看起来就是一个空格。从Unicode3.2开始,U+FEFF只能出现在字节流的开头,只能用于标识字节序,就如它的名称——字节序标记——所表示的一样;除此以外的用法已被舍弃。取而代之的是,使用U+2060来表达零宽度无断空白。 类似WINDOWS自带的记事本等软件,在保存一个以UTF-8编码的文件时,会在文件开始的 地方插入三个不可见的字符(0xEF 0xBB 0xBF,即BOM)。它是一串隐藏的字符,用于让记事本等编辑器识别这个文件是否以UTF-8编码。对于一般的文件,这样并不会产生什么麻烦。但对于 PHP来说,BOM是个大麻烦。 PHP并不会忽略BOM,所以在读取、包含或者引用这些文件时,会把BOM作为该文件开头正文 的一部分。根据嵌入式语言的特点,这串字符将被直接执行(显示)出来。由此造成即使页面的 top padding 设置为0,也无法让整个网页紧贴浏览器顶部,因为在html一开头有这3个字符呢! 不同编码的字节顺序标记的表示
也就是说在这个CSV文件最开始的时候隐藏了三个不可见的字符(0xEF 0xBB 0xBF,即BOM),PHP不会隐藏这个BOM。所以出现了两个字符串不相等的状况。 所以上传文件时要去除BOM头。 解决办法:$s = trim($s, "\xef\xbb\xbf\xff\xfe"); "\xef\xbb\xbf\xff\xfe" 中
不知道说的明白不明白,不过遇到这个问题的人倒是可以先参考这个解决办法把问题解决了,然后在网上再找找相关资料。 |
2022-07-29
2022-08-30
2022-08-17
2022-11-06
2022-08-18
请发表评论