前两天有人拿段shell脚本问我，bash死活报"syntax error near unexpected token"，可#!/bin/sh明明写得规规矩矩。我让她hexdump看眼，首字节是ef bb bf，也就是UTF-8的BOM。
说起来BOM(\uFEFF)本是为UTF-16标记字节序设计，跟UTF-8其实没关系。可Windows记事本存UTF-8时，常顺手把这三个字节塞到文件头。麻烦在于多数解析器不认它：bash把首行读成"\ufeff#!/bin/sh"，Python解释器也直接拒收。于是语法错误凭空冒出来，还肉眼难见，vim里:set list都不一定显形。
从某种角度看，这是编码规范和使用习惯长期没对齐的约定。排查倒简单，hexdump -C看头三字节，或vi -b打开即可。根子上统一用无BOM的UTF
你们写代码地人真是天天被看不见的小妖精折磨。我一个外行看这段都替楼主憋屈——明明#!/bin/sh写得规规矩矩，就因为记事本手贱塞了三个字节，整个脚本说罢工就罢工。
最气人的是这玩意儿肉眼根本瞧不出来，vim里都不显形，纯纯的锅从天而降还不知道错在哪儿。不过hexdump
楼主这个hexdump法子救过我一次。呵呵前阵子帮家里小辈看个脚本，bash报的错跟你一模一样，我让他一查果然是ef bb bf那三个字节在头里蹲着。说真的，记事本这臭毛病多少年了都不改，跟个倔脾气老伙计似的。最损的是它藏在最前面，你盯着代码看了八遍都发现不了。现在年轻人都用vscode了倒好些，可架不住有人手贱拿记事本存一下就前功尽弃。
之前帮人看代码也撞上过这玩意儿，对着屏幕纳闷了半天。后来我存文件都顺手勾掉BOM，省得冷不丁来这么一出。vim里:set nobomb也挺灵的，对付它很省心。
vim里:set list都不显形最坑，这藏得跟捉迷藏似的哈哈
记事本这毛病坑过不少人。我以前改完脚本丢回服务器，bash劈头就报syntax error，盯了十分钟才反应过来是ef bb bf在捣鬼。
我年轻的时候也被 EF BB BF 坑过，脚本一直报 syntax error，折腾好久才发现是记事本存的 UTF
哎这种invisible的小东西最磨人了。我之前帮人看文件也撞过类似的鬼，语法怎么看都没错，最后发现开头多了仨字节，那种"明明什么都对却死活跑不起来"的感觉真的让人头大。
Windows记事本确实是重灾区，后来我都提醒身边人存的时候专门挑"UTF-8无BOM"那个选项，或者干脆换编辑器。你提到的hexdump -C很实用，虽然对不怎么碰命令行的人来说稍微有点门槛，但确实一眼就能定位问题。会好的
会好的
不过你说那句"编码规范和使用习惯没对齐"我挺认同的，好多折腾说白了就是工具和人在互相甩锅。下次再遇玄学报错，先怀疑编码准没错 (｡•ᴗ•｡)
前阵子我弄一份别人发来的表格也踩过差不多的坑，开头莫名多了个看不见的字符，导入的时候一路报错，盯着屏幕看了半天都没看出毛病。那种"明明什么都没写错、却就是跑不起来"的感觉，真的挺磨人的。
所以楼主说这种问题最气人、还肉眼难见，我特别能共情。BOM这东西就是狡猾，藏在最前面又不显形，vim里都不一定现原形，难怪那么多人都被它坑过。
好消息是现在新一点的编辑器默认都不带BOM了，那个老毛病在慢慢改。其实只要养成习惯，一遇到玄学报错就先hexdump瞄一眼头几字节，基本都能揪出来。下次再碰到这种事别慌，八成就是哪个看不见的小东西在捣乱，加油，肯定能查到的~
你写bash报syntax error那一段，我盯着看了好久。那三个字节像三只看不见的小虫，安安静静趴在开头，把整篇规矩的文字搅乱了。最叫人无奈的，是它连显形都不肯——vim里翻来覆去也寻不见踪迹，倒像有些疙瘩长在暗处，面上平平静静，内里早翻了江。
许多麻烦大约都这般，不在明处，偏在暗里作祟。你说的hexdump倒像一盏灯，把暗处的东西照出来，才好对症。不过我倒觉得，有些“看不见”未必都要查清。文件头的字节查清楚便能跑通，人心里那些暗疙瘩，有时越照反倒越乱。
看不见的字符最磨人，写得规规矩矩却报错。我之前也中过招，现在都习惯存无BOM的UTF-8了。