小谈linux下文件头部<feff>问题

最新推荐文章于 2024-12-02 14:54:27 发布

转载最新推荐文章于 2024-12-02 14:54:27 发布 · 1k 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://juejin.im/post/5a9677a851882543de215fd0

本文讲述了作者在开发过程中遇到的编码问题，特别是UTF-8带BOM导致的布局错乱和功能崩溃。通过排查发现罪魁祸首是文件头部的<feff>标记，删除后恢复正常。文章还介绍了BOM的作用及其在不同系统中的表现。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

新年刚过，饱满的心态迎接2018，认真工作，提高效率。于是，两三天完成一个需求迭代，兴致勃勃的上线测试服务器，感觉以这样的速度开发的话，年底就可以月入百万，迎接白富美，走上......等等，jsp布局错乱什么鬼?部分功能崩溃什么鬼？于是有了今天的排错之旅。
由于在开发环境是正常的，部署到服务器后，功能部门不可用，把相关文件和svn对比，并没有用得出有效结果，于是锁定编码的问题，linux下vi相应的文件，头部多一个<feff>,冥冥之中，感觉这就是罪魁祸首，于是删除并且wq，奇迹般的就好了。
这里研究一下编码，对于UTF-8/16/32而言，它们名字中的8/16/32指的是编码单位是多少位的，也就是说，它们的编码单位分别是8/16/32位，换算成字节就是1/2/4字节，如果是多字节，就要牵扯到字节序，也即BOM。
这里介绍一下BOM（Byte Order Mark），Unicode字符，通常出现在文本的开头，用来标识字节序（Big/LittleEndian），除此以外还可以标识编码（UTF-8/16/32），如果出现在文本中间，则解释为zero width no-breakspace。
而对于utf16和utf32会用BOM（Byte Order Mark，为不可见字符）标识内部编码的字节序（Big/Litttle Endian），而utf8加不加BOM都可以，但是在windows系统下（nodepad++，记事本）保存文件编码为UTF-8会在文件头加上BOM，所以我们在读文件时会出现报错。在linux下用vim打开会看到<feff>，就是这个问题。
血与泪的教训，以后在写代码时一定注意不要用记事本等文件编辑代码了！！！

转载于:https://juejin.im/post/5a9677a851882543de215fd0