mysql导入sql1064错误BOM_SQL文件的BOM问题导致的invalid character错误及解决

在将Oracle数据迁移到ES过程中,遇到'ORA-00911 invalid character'错误,原因是SQL文件在Windows下用记事本以UTF-8带BOM格式保存。通过在Linux下检查文件BOM头并使用sed命令删除,成功解决问题。提醒避免使用记事本保存SQL文件,并提出Logstash可能不支持BOM文件的猜想。
摘要由CSDN通过智能技术生成

最近在做数据的搬运工,将Oracle中的数据搬运到ES中,方案很成熟了,使用Logstash的jdbc-input执行SQL,然后将结果输出到ES中。这么简单的问题,在测试环境中测试也一帆风顺,可一上生产环境傻眼了,始终报“ORA-00911 invalid character”的错误。

困扰了好几天,测试环境一直没问题,生产环境不管用多么简单的SQL都出同样的问题。最后,认真看了一下日志,突然发现 feff是什么鬼?

fd27338148e3feb925d9403e76884ff0.png

有了这个线索,百度了一下,原来是文件的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来解决这个问题?

本文为作者原创,如果您觉得本文对您有帮助,请随意打赏,您的支持将鼓励我继续创作。

73732841d8343f0c62729fa13ff55efb.png

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值