大家好我是[翻翻看老张]。不知道大家在接手老旧项目或者从Git上拉取某些特定仓库时有没有遇到过这种邪门儿的事代码看起来一模一样Git diff也干净但编译就是报错或者正则表达式死活匹配不上甚至JSON解析突然失败……如果你也遇到过别慌大概率不是你代码写得有问题而是你的Java文件里藏着一个看不见的幽灵——BOM头。今天我就用刚处理完的一个真实案例手把手教大家如何用PowerShell一键清除项目中的BOM顺便聊聊这个坑是怎么来的。一个“编译不过”的诡异下午事情是这样的最近我接手了一个基于Spring Boot的老项目hubble-boot4。从SVN迁下来后明明IDEA里看着一切正常但用Maven一编译控制台就报一堆莫名其妙的语法错误。最离谱的是报错指向的文件我打开一看语法完全正确。直觉告诉我这背后一定有脏东西。我用十六进制编辑器打开文件一看真相大白文件的头三个字节是EF BB BF。![示意图十六进制下的BOM头]是的这就是UTF-8 with BOM。虽然人类肉眼看不见但Java编译器尤其是非Windows环境或特定版本可不会惯着它直接把它当成了非法字符或者标识符的一部分。为什么要干掉BOM在.java源文件中BOM是百害而无一利的编译报错JDK的严格模式下BOM会导致“需要class, interface或enum”之类的诡异错误。 注解失效像RestController、Service这类注解紧跟在BOM后面可能导致解析异常。 跨平台噩梦Windows下写的带BOM文件提交到Linux服务器CI/CD环境编译时必炸。 代码审丑虽然看不见但它占用了文件头部的空间有时候还会导致Git认为整个文件都被修改了。既然这么烦人那就必须斩草除根。手动去删几百上千个文件得删到何年何月写段脚本吧核弹级解决方案PowerShell一键扫描与修复考虑到团队里不只有Mac用户还有很多小伙伴用Windows为了通用性我写了一段PowerShell脚本。只要把这个脚本保存为fix_bom.ps1放在项目根目录下双击运行或者右键使用PowerShell运行整个世界就清净了。完整脚本如下$projectPathE:\IdeaProjects\hubble-boot4# 改成你的项目路径$fixedCount 0$fixedFiles ()Write-Host开始扫描并修复项目中的 BOM 文件...-ForegroundColor CyanWrite-Host项目路径:$projectPath-ForegroundColor GrayWrite-HostGet-ChildItem-Path$projectPath-Filter*.java-Recurse|ForEach-Object{$bytes[System.IO.File]::ReadAllBytes($_.FullName)# 检查是否有 BOM (EF BB BF)if($bytes.Length-ge3-and$bytes[0]-eq0xEF-and$bytes[1]-eq0xBB-and$bytes[2]-eq0xBF){# 移除 BOM跳过前3个字节保留剩余内容$newBytes$bytes[3..($bytes.Length-1)][System.IO.File]::WriteAllBytes($_.FullName,$newBytes)$fixedCount$relativePath$_.FullName.Replace($projectPath,).TrimStart(\)$fixedFiles$relativePathWrite-Host✓ 已修复:$relativePath-ForegroundColor Green}}Write-HostWrite-Host-ForegroundColor CyanWrite-Host修复完成-ForegroundColor GreenWrite-Host-ForegroundColor CyanWrite-Host共修复文件数:$fixedCount-ForegroundColor Yellowif($fixedCount-gt0){Write-HostWrite-Host修复的文件列表:-ForegroundColor Cyan$fixedFiles|ForEach-Object{Write-Host •$_-ForegroundColor Gray}}Write-HostWrite-Host按任意键退出...-ForegroundColor Gray$null$Host.UI.RawUI.ReadKey(NoEcho,IncludeKeyDown)脚本效果展示运行它你会看到非常治愈的画面开始扫描并修复项目中的 BOM 文件... *项目路径: E:\IdeaProjects\hubble-boot4* ✓ 已修复: src\main\java\com\example\DemoApplication.java ✓ 已修复: src\main\java\com\example\controller\UserController.java ... ** 修复完成 ** 共修复文件数: 37写在最后防御胜于治疗虽然我们有了这个“大扫除”脚本但最好的办法是从源头杜绝。这里给大家三个小建议统一IDE编码在IntelliJ IDEA中进入 Settings Editor File Encodings把 UTF-8 勾选上并确保 BOM 选项设置为 NO BOM。 配置Git在项目的 .gitattributes 文件中加入一行*.java text eollf这能统一换行符并尽量避免BOM的引入。 门禁控制在CI流水线Jenkins/GitHub Actions中可以加入一个检查脚本如果检测到BOM文件直接让构建失败强制开发者修复。最后如果你手头也有一堆陈年代码需要清理别犹豫复制上面的脚本三秒钟还你一个清爽的项目觉得有用的话点个“在看”分享给那个还在手动删BOM的倒霉朋友吧 还在手动去BOM？教你一招，PowerShell批量拯救混乱代码库
大家好我是[翻翻看老张]。不知道大家在接手老旧项目或者从Git上拉取某些特定仓库时有没有遇到过这种邪门儿的事代码看起来一模一样Git diff也干净但编译就是报错或者正则表达式死活匹配不上甚至JSON解析突然失败……如果你也遇到过别慌大概率不是你代码写得有问题而是你的Java文件里藏着一个看不见的幽灵——BOM头。今天我就用刚处理完的一个真实案例手把手教大家如何用PowerShell一键清除项目中的BOM顺便聊聊这个坑是怎么来的。一个“编译不过”的诡异下午事情是这样的最近我接手了一个基于Spring Boot的老项目hubble-boot4。从SVN迁下来后明明IDEA里看着一切正常但用Maven一编译控制台就报一堆莫名其妙的语法错误。最离谱的是报错指向的文件我打开一看语法完全正确。直觉告诉我这背后一定有脏东西。我用十六进制编辑器打开文件一看真相大白文件的头三个字节是EF BB BF。![示意图十六进制下的BOM头]是的这就是UTF-8 with BOM。虽然人类肉眼看不见但Java编译器尤其是非Windows环境或特定版本可不会惯着它直接把它当成了非法字符或者标识符的一部分。为什么要干掉BOM在.java源文件中BOM是百害而无一利的编译报错JDK的严格模式下BOM会导致“需要class, interface或enum”之类的诡异错误。 注解失效像RestController、Service这类注解紧跟在BOM后面可能导致解析异常。 跨平台噩梦Windows下写的带BOM文件提交到Linux服务器CI/CD环境编译时必炸。 代码审丑虽然看不见但它占用了文件头部的空间有时候还会导致Git认为整个文件都被修改了。既然这么烦人那就必须斩草除根。手动去删几百上千个文件得删到何年何月写段脚本吧核弹级解决方案PowerShell一键扫描与修复考虑到团队里不只有Mac用户还有很多小伙伴用Windows为了通用性我写了一段PowerShell脚本。只要把这个脚本保存为fix_bom.ps1放在项目根目录下双击运行或者右键使用PowerShell运行整个世界就清净了。完整脚本如下$projectPathE:\IdeaProjects\hubble-boot4# 改成你的项目路径$fixedCount 0$fixedFiles ()Write-Host开始扫描并修复项目中的 BOM 文件...-ForegroundColor CyanWrite-Host项目路径:$projectPath-ForegroundColor GrayWrite-HostGet-ChildItem-Path$projectPath-Filter*.java-Recurse|ForEach-Object{$bytes[System.IO.File]::ReadAllBytes($_.FullName)# 检查是否有 BOM (EF BB BF)if($bytes.Length-ge3-and$bytes[0]-eq0xEF-and$bytes[1]-eq0xBB-and$bytes[2]-eq0xBF){# 移除 BOM跳过前3个字节保留剩余内容$newBytes$bytes[3..($bytes.Length-1)][System.IO.File]::WriteAllBytes($_.FullName,$newBytes)$fixedCount$relativePath$_.FullName.Replace($projectPath,).TrimStart(\)$fixedFiles$relativePathWrite-Host✓ 已修复:$relativePath-ForegroundColor Green}}Write-HostWrite-Host-ForegroundColor CyanWrite-Host修复完成-ForegroundColor GreenWrite-Host-ForegroundColor CyanWrite-Host共修复文件数:$fixedCount-ForegroundColor Yellowif($fixedCount-gt0){Write-HostWrite-Host修复的文件列表:-ForegroundColor Cyan$fixedFiles|ForEach-Object{Write-Host •$_-ForegroundColor Gray}}Write-HostWrite-Host按任意键退出...-ForegroundColor Gray$null$Host.UI.RawUI.ReadKey(NoEcho,IncludeKeyDown)脚本效果展示运行它你会看到非常治愈的画面开始扫描并修复项目中的 BOM 文件... *项目路径: E:\IdeaProjects\hubble-boot4* ✓ 已修复: src\main\java\com\example\DemoApplication.java ✓ 已修复: src\main\java\com\example\controller\UserController.java ... ** 修复完成 ** 共修复文件数: 37写在最后防御胜于治疗虽然我们有了这个“大扫除”脚本但最好的办法是从源头杜绝。这里给大家三个小建议统一IDE编码在IntelliJ IDEA中进入 Settings Editor File Encodings把 UTF-8 勾选上并确保 BOM 选项设置为 NO BOM。 配置Git在项目的 .gitattributes 文件中加入一行*.java text eollf这能统一换行符并尽量避免BOM的引入。 门禁控制在CI流水线Jenkins/GitHub Actions中可以加入一个检查脚本如果检测到BOM文件直接让构建失败强制开发者修复。最后如果你手头也有一堆陈年代码需要清理别犹豫复制上面的脚本三秒钟还你一个清爽的项目觉得有用的话点个“在看”分享给那个还在手动删BOM的倒霉朋友吧