最近在做数据的搬运工,将Oracle中的数据搬运到ES中,方案很成熟了,使用Logstash的jdbc-input执行SQL,然后将结果输出到ES中。这么简单的问题,在测试环境中测试也一帆风顺,可一上生产环境傻眼了,始终报“ORA-00911 invalid character”的错误。
困扰了好几天,测试环境一直没问题,生产环境不管用多么简单的SQL都出同样的问题。最后,认真看了一下日志,突然发现 feff
是什么鬼?
有了这个线索,百度了一下,原来是文件的BOM头,忽然想起来SQL文件是在Windows下用记事本保存为UTF-8格式的。在Linux下重新创建了一个空白文件,将SQL语句拷贝过去,再执行就没问题了。
只能说,尽量还是不要用记事本啊~~
如何查看文件是否含有BOM头
file 命令
在Linux下,可以简单的使用file命令来查看文件是否含有BOM头。
[root@bj1eccap01 ~]# file test.txt
test.txt: UTF-8 Unicode (with BOM) text, with no line terminators
awk 命令
[root@bj1eccap01 ~]# hexdump test2.txt
0000000 bbef 48bf 6c65 6f6c 5720 726f 646c bcef
0000010 0d81 000a
0000013
[root@bj1eccap01 ~]# find . -type f -print0 | xargs -0r awk '/^\xEF\xBB\xBF/ {print FILENAME} {nextfile}'
./test2.txt
删除BOM头
sed 命令
[root@bj1eccap01 ~]# sed -i -e '1s/^\xEF\xBB\xBF//' test2.txt
[root@bj1eccap01 ~]# find . -type f -print0 | xargs -0r awk '/^\xEF\xBB\xBF/ {print FILENAME} {nextfile}'
[root@bj1eccap01 ~]# hexdump test2.txt
0000000 6548 6c6c 206f 6f57 6c72 ef64 81bc 0a0d
0000010
这个问题反过来想,我觉得是 logstash 不支持含有 BOM 头的SQL文件,是不是可以给官方提交一个Feature来解决这个问题?
本文为作者原创,如果您觉得本文对您有帮助,请随意打赏,您的支持将鼓励我继续创作。
参考资料:
1、带BOM的UTF-8
2、Byte order mark
3、How to check if file has a BOM in utf-8 text
4、Using awk/sed to detect/remove the byte order mark (BOM)
时间: 2024-10-06 01:31:47