1. 这个报错到底在说什么Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources Input length 1——如果你是个常年跟Java项目打交道的后端看到这行红字大概率血压已经上来了。它不像编译错误那样能直接定位到某一行代码也不像依赖冲突那样有清晰的树状图它出现在maven-resources-plugin执行resources目标的时候报了一个极其含糊的Input length 1。先把结论放在前面这个报错的本质是Maven在读取某个资源文件时遇到了一个它无法解析的字符编码问题。Input length 1是Java的MalformedInputException在NIO解码时抛出的典型信息意思是解码器在当前位置只读到了1个字节但这个字节无法构成一个合法的字符。翻译成人话就是你的资源文件里有一个字节用当前指定的字符集去解码解不出来。这个问题在maven-resources-plugin3.2.0版本上特别常见因为3.2.0对资源过滤filtering的编码处理比之前的版本更严格了。以前可能睁一只眼闭一只眼就过去了现在直接给你报错中断构建。谁最容易踩这个坑我观察下来主要是三类人一是项目里有中文注释或者中文属性值的二是从Windows环境迁移到Linux构建环境的三是项目里混入了GBK编码文件的。如果你正好在做多模块项目、资源文件里带中文、或者CI/CD流水线突然挂了那这篇文章就是写给你的。接下来我会把这个报错从根因到解决方案完整拆一遍包括编码原理、排查手段、修复方案以及我在实际项目里踩过的那些坑。2. 编码问题的根因拆解2.1 为什么偏偏是maven-resources-plugin要理解这个报错得先搞清楚maven-resources-plugin到底干了什么。它的核心职责是把src/main/resources和src/test/resources目录下的资源文件复制到target/classes目录。听起来很简单对吧但问题就出在复制这个动作上。当你的pom.xml里开启了资源过滤filteringtrue/filtering时这个插件就不只是简单复制了它会读取文件内容、替换其中的${...}占位符、然后再写出去。这个读取的过程就需要用到字符集解码。如果插件配置的编码和文件实际编码不一致解码就会失败。maven-resources-plugin3.2.0这个版本有个变化它默认使用${project.build.sourceEncoding}作为资源过滤的编码。如果你的项目没有显式设置这个属性或者设置的值和实际文件编码不匹配就会触发Input length 1。2.2 Input length 1 的真实含义这个报错信息来自Java NIO的CharsetDecoder。当你用一个字符集去解码字节序列时如果遇到一个字节序列在当前字符集下不合法就会抛出MalformedInputException而Input length 1表示出问题的位置只有1个字节。举个具体的例子假设你的文件是GBK编码的里面有个中文字中GBK编码是0xD6 0xD0两个字节。如果你用UTF-8去解码这两个字节0xD6在UTF-8里是一个多字节字符的起始字节它期望后面跟着 continuation byte10xxxxxx格式但0xD0是11010000确实符合continuation byte的格式所以这两个字节在UTF-8下可能被解析成一个奇怪的字符但不一定报错。真正会报Input length 1的情况通常是遇到了UTF-8中完全不合法的字节序列。比如GBK编码的某些字符会产生0x80到0xFF之间的单字节这些在UTF-8里都是非法的起始字节。或者文件里混入了BOM头、二进制数据、特殊控制字符等。2.3 常见的触发场景根据我这些年的排查经验触发这个报错的场景高度集中触发场景具体表现占比资源文件含中文且编码不一致.properties、.xml、.json里有中文约60%项目从Windows迁移到LinuxWindows默认GBKLinux默认UTF-8约20%文件含BOM头UTF-8 BOM导致解码异常约10%资源文件混入二进制内容误把图片、证书当文本处理约5%插件版本升级导致行为变化从3.1.x升到3.2.0约5%这个分布很说明问题——绝大多数情况都是编码不一致导致的。而编码不一致的根源往往不是开发者故意为之而是不同操作系统、不同编辑器、不同工具链之间的默认行为差异造成的。3. 排查思路与定位手段3.1 先确认是哪个文件出了问题Maven的报错信息有时候不会直接告诉你具体是哪个文件这就需要我们主动去定位。最直接的办法是加上-X参数跑一次构建mvn clean compile -X 21 | grep -A 5 Input length-X会输出debug级别的日志你能看到插件正在处理哪个资源文件时挂掉的。如果日志太多可以把输出重定向到文件再搜索mvn clean compile -X build-debug.log 21然后在build-debug.log里搜索Input length往上翻几行就能看到当前处理的文件名。3.2 用file命令批量检测文件编码定位到可疑目录后可以用file命令批量检查文件编码find src/main/resources -type f -exec file {} \;输出里会显示每个文件的编码类型比如UTF-8 Unicode text、ISO-8859 text、Non-ISO extended-ASCII text等。如果看到某个文件显示的不是UTF-8那它就是嫌疑对象。更精确一点可以用file -i显示MIME编码find src/main/resources -type f -exec file -i {} \; | grep -v charsetutf-8这条命令会列出所有非UTF-8编码的文件非常实用。3.3 用iconv验证编码转换如果怀疑某个文件是GBK编码可以用iconv测试一下iconv -f GBK -t UTF-8 suspect-file.properties /dev/null如果没有报错说明这个文件确实是GBK编码且内容合法。如果报错说明文件里可能混了多种编码或者有非法字节。反过来也可以验证iconv -f UTF-8 -t UTF-8 suspect-file.properties /dev/null如果这个报错那基本可以确认文件不是合法的UTF-8。3.4 用hexdump查看具体字节对于特别顽固的文件直接看字节是最靠谱的hexdump -C suspect-file.properties | head -50重点看有没有ef bb bfUTF-8 BOM、ff feUTF-16 LE BOM、fe ffUTF-16 BE BOM这些BOM头或者有没有明显不属于文本的字节序列。提示BOM头是很多编码问题的隐形杀手。Windows上某些编辑器保存UTF-8文件时会自动加BOM而Java的InputStreamReader默认不会跳过BOM导致文件开头多出几个不可见字符进而引发各种诡异问题。4. 解决方案与实操步骤4.1 方案一统一设置项目编码推荐最根本的解决办法是在pom.xml里显式声明编码并且确保所有环节都用同一个编码。在properties节点里加上properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding maven.compiler.encodingUTF-8/maven.compiler.encoding /properties这三个属性分别控制源码编码、报告输出编码、编译器编码。三个都设成UTF-8能覆盖绝大多数场景。然后在maven-resources-plugin的配置里也显式指定编码plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version3.2.0/version configuration encodingUTF-8/encoding /configuration /plugin这样配置之后插件在读取资源文件时会强制用UTF-8解码。但注意——这要求你的资源文件本身确实是UTF-8编码。如果文件本身是GBK的强制用UTF-8读还是会报错。4.2 方案二批量转换文件编码如果确认项目里有GBK编码的文件需要把它们转成UTF-8。单个文件转换iconv -f GBK -t UTF-8 input.properties output.properties mv output.properties input.properties批量转换可以用循环find src/main/resources -type f \( -name *.properties -o -name *.xml -o -name *.json \) | while read file; do if ! iconv -f UTF-8 -t UTF-8 $file /dev/null 21; then echo Converting: $file iconv -f GBK -t UTF-8 $file $file.tmp mv $file.tmp $file fi done这段脚本的逻辑是先检测文件是否是合法UTF-8如果不是就当作GBK转成UTF-8。转换前建议先备份或者确保项目在Git里已经提交过。注意iconv转换时如果遇到无法映射的字符会报错中断。可以加-c参数忽略无法转换的字符但这可能导致内容丢失。更稳妥的做法是先转换到临时文件人工检查后再替换。4.3 方案三处理BOM头问题如果文件是UTF-8 BOM格式需要去掉BOM头。可以用sedsed -i 1s/^\xEF\xBB\xBF// suspect-file.properties或者用dos2unix工具dos2unix suspect-file.propertiesdos2unix不仅能去BOM还能把Windows的\r\n换行转成Unix的\n一举两得。批量处理find src/main/resources -type f -exec sed -i 1s/^\xEF\xBB\xBF// {} \;4.4 方案四跳过资源过滤如果某些资源文件确实不需要过滤比如二进制文件、字体文件、图片可以在pom.xml里排除它们plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version3.2.0/version configuration encodingUTF-8/encoding nonFilteredFileExtensions nonFilteredFileExtensionjpg/nonFilteredFileExtension nonFilteredFileExtensionpng/nonFilteredFileExtension nonFilteredFileExtensiongif/nonFilteredFileExtension nonFilteredFileExtensionpdf/nonFilteredFileExtension nonFilteredFileExtensionzip/nonFilteredFileExtension /nonFilteredFileExtensions /configuration /plugin这样配置后这些扩展名的文件会直接复制不经过过滤和编码解码自然就不会报错了。4.5 方案五降级插件版本临时方案如果项目紧急上线来不及排查编码问题可以临时把maven-resources-plugin降级到3.1.0plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version3.1.0/version /plugin3.1.0对编码的处理更宽松很多在3.2.0上报错的文件在3.1.0上能正常处理。但这只是权宜之计不建议长期使用因为编码问题迟早会在其他地方爆发。5. 实操过程完整记录5.1 一个真实项目的排查过程前段时间接手了一个多模块项目构建时一直报Input length 1。项目结构大概是这样的project-root/ ├── pom.xml ├── module-common/ │ └── src/main/resources/ │ ├── messages.properties │ └── config/ │ └── app-config.xml ├── module-service/ │ └── src/main/resources/ │ └── sql/ │ └── init-data.sql └── module-web/ └── src/main/resources/ └── i18n/ └── messages_zh_CN.properties第一步用-X参数定位到出问题的模块是module-common但日志没有明确说是哪个文件。于是我用file -i批量检查find module-common/src/main/resources -type f -exec file -i {} \;输出结果里messages.properties显示的是charsetiso-8859-1其他文件都是charsetutf-8。嫌疑锁定。第二步用hexdump看这个文件的前几十个字节hexdump -C module-common/src/main/resources/messages.properties | head -20发现里面确实有0xD6 0xD0这样的字节序列典型的GBK编码中文。第三步确认文件内容iconv -f GBK -t UTF-8 module-common/src/main/resources/messages.properties输出正常确认是GBK编码。第四步转换编码iconv -f GBK -t UTF-8 module-common/src/main/resources/messages.properties /tmp/messages.properties mv /tmp/messages.properties module-common/src/main/resources/messages.properties第五步在根pom.xml里加上编码配置参考4.1节的配置。第六步重新构建mvn clean compile构建成功问题解决。5.2 另一个案例BOM头导致的诡异问题还有一个项目所有文件都确认是UTF-8编码但依然报Input length 1。用hexdump检查后发现某个.xml文件开头有ef bb bf也就是UTF-8 BOM。这个BOM头在大多数编辑器里是看不见的但Java读取时会把它当作文件内容的一部分。如果这个XML文件被maven-resources-plugin过滤BOM头就会被当作普通字符处理在某些情况下触发解码异常。解决办法就是去掉BOMsed -i 1s/^\xEF\xBB\xBF// module-service/src/main/resources/config/app-config.xml去掉之后重新构建问题消失。5.3 CI/CD流水线上的编码问题最麻烦的是CI/CD流水线上的编码问题。本地构建正常一到流水线就报错。这种情况通常是本地和流水线的默认编码不一致导致的。本地开发机可能是macOS或Linux默认UTF-8流水线如果跑在Windows Agent上默认可能是GBK。或者流水线的JVM参数里没有设置-Dfile.encodingUTF-8。解决办法是在流水线配置里显式设置环境变量export JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8 export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8或者在Maven命令里直接指定mvn clean compile -Dfile.encodingUTF-8提示JAVA_TOOL_OPTIONS环境变量会被JVM自动读取适合在CI/CD环境里全局设置编码。但注意它会影响所有Java进程如果流水线里还跑了其他Java应用需要确认不会产生副作用。6. 常见问题速查与避坑经验6.1 常见问题速查表问题现象可能原因快速排查解决方案报错但不提示具体文件插件日志级别不够加-X参数重新构建从debug日志里找文件名本地正常CI报错环境编码不一致检查LANG、file.encoding统一设置UTF-8环境变量只有部分文件报错混合编码file -i批量检测统一转成UTF-8升级插件后突然报错3.2.0更严格对比插件版本统一编码或降级插件文件看起来是UTF-8但报错可能有BOMhexdump看开头字节去掉BOM头转换编码后中文变乱码转换方向搞反了确认原文件编码用正确的-f参数6.2 避坑经验一不要依赖IDE的默认编码很多人觉得IDE里显示正常就没问题但IDE的编码设置和Maven的编码设置是两回事。IntelliJ IDEA默认可能用系统编码Eclipse可能用GBK而Maven插件用的是project.build.sourceEncoding。这三者不一致就会出问题。我的建议是在项目根目录放一个.editorconfig文件强制统一编码root true [*] charset utf-8 end_of_line lf insert_final_newline true trim_trailing_whitespace true [*.{properties,xml,json,yml,yaml}] charset utf-8这样大多数现代编辑器和IDE都会遵循这个配置减少编码不一致的概率。6.3 避坑经验二properties文件的特殊处理.properties文件在Java里有个历史遗留问题java.util.Properties默认用ISO-8859-1读取中文需要转成\uXXXX格式。虽然Maven插件不直接用Properties类但很多开发者会混淆这一点。对于.properties文件我的建议是如果项目用JDK 9可以用PropertyResourceBundle配合UTF-8读取如果必须兼容老版本把中文转成Unicode转义序列或者干脆用YAML替代propertiesSpring Boot项目推荐转换中文到Unicode可以用native2ascii工具JDK自带native2ascii -encoding UTF-8 messages.properties messages_ascii.properties6.4 避坑经验三Git的换行符配置Git在Windows和Linux之间同步代码时可能会自动转换换行符core.autocrlf。这个转换有时会引入不可见字符间接导致编码问题。建议在项目根目录加一个.gitattributes文件* textauto eollf *.png binary *.jpg binary *.jar binary *.zip binary这样能确保文本文件统一用LF换行二进制文件不被篡改。6.5 避坑经验四构建缓存导致的假象有时候你明明改了文件编码但重新构建还是报错。这可能是Maven的增量编译或者IDE的缓存导致的。解决办法是彻底清理mvn clean rm -rf target/如果用的是IDE还要清理IDE的缓存IntelliJ IDEA里是File - Invalidate Caches。6.6 避坑经验五不要忽略警告Maven在编码问题上有时会先给警告再报错。比如[WARNING] Using platform encoding (GBK actually) to copy filtered resources看到这种警告就要警惕了它意味着当前用的是平台默认编码而不是你期望的UTF-8。警告往往是大问题的前兆不要等到报错了才去处理。7. 长效预防机制7.1 在父POM里统一编码配置如果是多模块项目一定要在父POM里统一配置编码子模块继承即可properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding maven.compiler.encodingUTF-8/maven.compiler.encoding /properties build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version3.2.0/version configuration encodingUTF-8/encoding /configuration /plugin /plugins /pluginManagement /build7.2 加一个编码检查的构建步骤可以在validate阶段加一个编码检查插件提前发现问题plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version3.0.0/version executions execution idenforce-encoding/id goals goalenforce/goal /goals configuration rules requireProperty propertyproject.build.sourceEncoding/property message必须设置project.build.sourceEncoding为UTF-8/message /requireProperty /rules /configuration /execution /executions /plugin这样如果哪个模块忘了设置编码构建会直接失败并给出明确提示比等到resources阶段报Input length 1要友好得多。7.3 在CI/CD里加编码检测在流水线的构建脚本里加一段编码检测#!/bin/bash INVALID_FILES$(find src -type f \( -name *.java -o -name *.properties -o -name *.xml \) -exec file -i {} \; | grep -v charsetutf-8 | grep -v charsetus-ascii) if [ -n $INVALID_FILES ]; then echo 发现非UTF-8编码的文件 echo $INVALID_FILES exit 1 fi这段脚本会在构建前检查所有源文件发现非UTF-8编码就中断流水线把问题拦截在更早的阶段。7.4 团队规范层面的建议技术手段能解决大部分问题但最根本的还是团队规范。我在团队里推行的几条规则所有文本文件统一UTF-8无BOM编码这是硬性要求提交代码前用file -i自查一遍新增文件禁止在.properties里直接写中文用Unicode转义或改用YAML新项目初始化时就把编码配置写进父POM模板代码评审时把编码问题作为检查项之一这些规则看起来琐碎但能省下大量排查编码问题的时间。我算过一笔账一个编码问题从出现到定位到解决平均要花1到2小时而预防成本几乎为零。8. 一些补充的技术细节8.1 为什么是Input length 1而不是其他数字Input length 1里的数字表示解码器在当前位置读取的字节数。当解码器遇到一个非法字节时它会报告当前读取了多少字节。大多数情况下是1因为UTF-8解码器逐字节读取遇到非法起始字节就立即报错。如果报的是Input length 2或Input length 3说明解码器读取了多个字节后才发现问题通常是因为多字节序列的后续字节不合法。8.2 maven-resources-plugin各版本的行为差异版本编码默认行为特点3.0.x使用平台默认编码问题最多但报错少3.1.0使用project.build.sourceEncoding相对宽松3.2.0严格使用配置编码报错更明确但更容易触发3.3.x优化了错误提示会提示具体文件名如果项目还在用3.0.x强烈建议升级到3.2.0或更高版本虽然可能会暴露一些隐藏的编码问题但早暴露早解决。8.3 关于file.encoding系统属性file.encoding是JVM的一个系统属性影响InputStreamReader等类的默认编码。但它有个坑JVM启动后修改file.encoding不一定生效因为很多类在初始化时就已经缓存了编码。所以设置file.encoding最好通过JVM启动参数java -Dfile.encodingUTF-8 -jar your-app.jar或者在MAVEN_OPTS里设置export MAVEN_OPTS-Dfile.encodingUTF-88.4 关于Maven的filtering机制资源过滤的本质是文本替换。Maven会把资源文件当作文本读取替换${...}占位符然后写出去。这个过程中任何非文本内容都会导致问题。所以对于二进制文件图片、字体、压缩包等一定要通过nonFilteredFileExtensions排除不要让它们经过过滤流程。这不仅是为了避免编码错误也是为了保证二进制内容的完整性——文本读写可能会破坏二进制数据。8.5 一个容易忽略的细节文件末尾的换行有些编码问题是由文件末尾的换行符引起的。Windows的\r\n和Unix的\n在UTF-8下都是合法字符但如果文件末尾缺少换行某些工具可能会追加一个导致文件内容变化。建议在.editorconfig里设置insert_final_newline true确保所有文件末尾都有换行避免这类问题。9. 我在实际项目中的体会处理了这么多次Input length 1我最大的体会是编码问题从来不是单纯的技术问题而是工程规范问题。一个项目如果从一开始就统一了编码规范后面几乎不会遇到这类报错。反之如果编码规范缺失今天修好了这个文件明天可能又冒出另一个。另一个体会是不要怕报错怕的是报错信息不明确。Input length 1虽然看起来含糊但它至少告诉你是编码问题。比起那些静默失败、中文变乱码、构建成功但运行时报错的情况这种直接报错反而更好排查。最后分享一个我常用的小技巧在项目根目录放一个check-encoding.sh脚本每次提交代码前跑一下能拦截90%以上的编码问题。脚本内容就是前面7.3节那段简单但有效。团队里推广之后编码相关的构建失败率下降了八成以上。如果你现在正被这个报错卡住按照第4节的方案一步步来基本都能解决。如果试了所有方案还是不行那可能是更底层的问题比如文件系统损坏、磁盘坏道之类的那就需要换台机器验证一下了。 
长河君 · 2026/10/20 12:31:38 · 阅读 1.2k Maven构建报错Input length = 1：资源文件编码问题排查与解决方案
1. 这个报错到底在说什么Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources Input length 1——如果你是个常年跟Java项目打交道的后端看到这行红字大概率血压已经上来了。它不像编译错误那样能直接定位到某一行代码也不像依赖冲突那样有清晰的树状图它出现在maven-resources-plugin执行resources目标的时候报了一个极其含糊的Input length 1。先把结论放在前面这个报错的本质是Maven在读取某个资源文件时遇到了一个它无法解析的字符编码问题。Input length 1是Java的MalformedInputException在NIO解码时抛出的典型信息意思是解码器在当前位置只读到了1个字节但这个字节无法构成一个合法的字符。翻译成人话就是你的资源文件里有一个字节用当前指定的字符集去解码解不出来。这个问题在maven-resources-plugin3.2.0版本上特别常见因为3.2.0对资源过滤filtering的编码处理比之前的版本更严格了。以前可能睁一只眼闭一只眼就过去了现在直接给你报错中断构建。谁最容易踩这个坑我观察下来主要是三类人一是项目里有中文注释或者中文属性值的二是从Windows环境迁移到Linux构建环境的三是项目里混入了GBK编码文件的。如果你正好在做多模块项目、资源文件里带中文、或者CI/CD流水线突然挂了那这篇文章就是写给你的。接下来我会把这个报错从根因到解决方案完整拆一遍包括编码原理、排查手段、修复方案以及我在实际项目里踩过的那些坑。2. 编码问题的根因拆解2.1 为什么偏偏是maven-resources-plugin要理解这个报错得先搞清楚maven-resources-plugin到底干了什么。它的核心职责是把src/main/resources和src/test/resources目录下的资源文件复制到target/classes目录。听起来很简单对吧但问题就出在复制这个动作上。当你的pom.xml里开启了资源过滤filteringtrue/filtering时这个插件就不只是简单复制了它会读取文件内容、替换其中的${...}占位符、然后再写出去。这个读取的过程就需要用到字符集解码。如果插件配置的编码和文件实际编码不一致解码就会失败。maven-resources-plugin3.2.0这个版本有个变化它默认使用${project.build.sourceEncoding}作为资源过滤的编码。如果你的项目没有显式设置这个属性或者设置的值和实际文件编码不匹配就会触发Input length 1。2.2 Input length 1 的真实含义这个报错信息来自Java NIO的CharsetDecoder。当你用一个字符集去解码字节序列时如果遇到一个字节序列在当前字符集下不合法就会抛出MalformedInputException而Input length 1表示出问题的位置只有1个字节。举个具体的例子假设你的文件是GBK编码的里面有个中文字中GBK编码是0xD6 0xD0两个字节。如果你用UTF-8去解码这两个字节0xD6在UTF-8里是一个多字节字符的起始字节它期望后面跟着 continuation byte10xxxxxx格式但0xD0是11010000确实符合continuation byte的格式所以这两个字节在UTF-8下可能被解析成一个奇怪的字符但不一定报错。真正会报Input length 1的情况通常是遇到了UTF-8中完全不合法的字节序列。比如GBK编码的某些字符会产生0x80到0xFF之间的单字节这些在UTF-8里都是非法的起始字节。或者文件里混入了BOM头、二进制数据、特殊控制字符等。2.3 常见的触发场景根据我这些年的排查经验触发这个报错的场景高度集中触发场景具体表现占比资源文件含中文且编码不一致.properties、.xml、.json里有中文约60%项目从Windows迁移到LinuxWindows默认GBKLinux默认UTF-8约20%文件含BOM头UTF-8 BOM导致解码异常约10%资源文件混入二进制内容误把图片、证书当文本处理约5%插件版本升级导致行为变化从3.1.x升到3.2.0约5%这个分布很说明问题——绝大多数情况都是编码不一致导致的。而编码不一致的根源往往不是开发者故意为之而是不同操作系统、不同编辑器、不同工具链之间的默认行为差异造成的。3. 排查思路与定位手段3.1 先确认是哪个文件出了问题Maven的报错信息有时候不会直接告诉你具体是哪个文件这就需要我们主动去定位。最直接的办法是加上-X参数跑一次构建mvn clean compile -X 21 | grep -A 5 Input length-X会输出debug级别的日志你能看到插件正在处理哪个资源文件时挂掉的。如果日志太多可以把输出重定向到文件再搜索mvn clean compile -X build-debug.log 21然后在build-debug.log里搜索Input length往上翻几行就能看到当前处理的文件名。3.2 用file命令批量检测文件编码定位到可疑目录后可以用file命令批量检查文件编码find src/main/resources -type f -exec file {} \;输出里会显示每个文件的编码类型比如UTF-8 Unicode text、ISO-8859 text、Non-ISO extended-ASCII text等。如果看到某个文件显示的不是UTF-8那它就是嫌疑对象。更精确一点可以用file -i显示MIME编码find src/main/resources -type f -exec file -i {} \; | grep -v charsetutf-8这条命令会列出所有非UTF-8编码的文件非常实用。3.3 用iconv验证编码转换如果怀疑某个文件是GBK编码可以用iconv测试一下iconv -f GBK -t UTF-8 suspect-file.properties /dev/null如果没有报错说明这个文件确实是GBK编码且内容合法。如果报错说明文件里可能混了多种编码或者有非法字节。反过来也可以验证iconv -f UTF-8 -t UTF-8 suspect-file.properties /dev/null如果这个报错那基本可以确认文件不是合法的UTF-8。3.4 用hexdump查看具体字节对于特别顽固的文件直接看字节是最靠谱的hexdump -C suspect-file.properties | head -50重点看有没有ef bb bfUTF-8 BOM、ff feUTF-16 LE BOM、fe ffUTF-16 BE BOM这些BOM头或者有没有明显不属于文本的字节序列。提示BOM头是很多编码问题的隐形杀手。Windows上某些编辑器保存UTF-8文件时会自动加BOM而Java的InputStreamReader默认不会跳过BOM导致文件开头多出几个不可见字符进而引发各种诡异问题。4. 解决方案与实操步骤4.1 方案一统一设置项目编码推荐最根本的解决办法是在pom.xml里显式声明编码并且确保所有环节都用同一个编码。在properties节点里加上properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding maven.compiler.encodingUTF-8/maven.compiler.encoding /properties这三个属性分别控制源码编码、报告输出编码、编译器编码。三个都设成UTF-8能覆盖绝大多数场景。然后在maven-resources-plugin的配置里也显式指定编码plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version3.2.0/version configuration encodingUTF-8/encoding /configuration /plugin这样配置之后插件在读取资源文件时会强制用UTF-8解码。但注意——这要求你的资源文件本身确实是UTF-8编码。如果文件本身是GBK的强制用UTF-8读还是会报错。4.2 方案二批量转换文件编码如果确认项目里有GBK编码的文件需要把它们转成UTF-8。单个文件转换iconv -f GBK -t UTF-8 input.properties output.properties mv output.properties input.properties批量转换可以用循环find src/main/resources -type f \( -name *.properties -o -name *.xml -o -name *.json \) | while read file; do if ! iconv -f UTF-8 -t UTF-8 $file /dev/null 21; then echo Converting: $file iconv -f GBK -t UTF-8 $file $file.tmp mv $file.tmp $file fi done这段脚本的逻辑是先检测文件是否是合法UTF-8如果不是就当作GBK转成UTF-8。转换前建议先备份或者确保项目在Git里已经提交过。注意iconv转换时如果遇到无法映射的字符会报错中断。可以加-c参数忽略无法转换的字符但这可能导致内容丢失。更稳妥的做法是先转换到临时文件人工检查后再替换。4.3 方案三处理BOM头问题如果文件是UTF-8 BOM格式需要去掉BOM头。可以用sedsed -i 1s/^\xEF\xBB\xBF// suspect-file.properties或者用dos2unix工具dos2unix suspect-file.propertiesdos2unix不仅能去BOM还能把Windows的\r\n换行转成Unix的\n一举两得。批量处理find src/main/resources -type f -exec sed -i 1s/^\xEF\xBB\xBF// {} \;4.4 方案四跳过资源过滤如果某些资源文件确实不需要过滤比如二进制文件、字体文件、图片可以在pom.xml里排除它们plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version3.2.0/version configuration encodingUTF-8/encoding nonFilteredFileExtensions nonFilteredFileExtensionjpg/nonFilteredFileExtension nonFilteredFileExtensionpng/nonFilteredFileExtension nonFilteredFileExtensiongif/nonFilteredFileExtension nonFilteredFileExtensionpdf/nonFilteredFileExtension nonFilteredFileExtensionzip/nonFilteredFileExtension /nonFilteredFileExtensions /configuration /plugin这样配置后这些扩展名的文件会直接复制不经过过滤和编码解码自然就不会报错了。4.5 方案五降级插件版本临时方案如果项目紧急上线来不及排查编码问题可以临时把maven-resources-plugin降级到3.1.0plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version3.1.0/version /plugin3.1.0对编码的处理更宽松很多在3.2.0上报错的文件在3.1.0上能正常处理。但这只是权宜之计不建议长期使用因为编码问题迟早会在其他地方爆发。5. 实操过程完整记录5.1 一个真实项目的排查过程前段时间接手了一个多模块项目构建时一直报Input length 1。项目结构大概是这样的project-root/ ├── pom.xml ├── module-common/ │ └── src/main/resources/ │ ├── messages.properties │ └── config/ │ └── app-config.xml ├── module-service/ │ └── src/main/resources/ │ └── sql/ │ └── init-data.sql └── module-web/ └── src/main/resources/ └── i18n/ └── messages_zh_CN.properties第一步用-X参数定位到出问题的模块是module-common但日志没有明确说是哪个文件。于是我用file -i批量检查find module-common/src/main/resources -type f -exec file -i {} \;输出结果里messages.properties显示的是charsetiso-8859-1其他文件都是charsetutf-8。嫌疑锁定。第二步用hexdump看这个文件的前几十个字节hexdump -C module-common/src/main/resources/messages.properties | head -20发现里面确实有0xD6 0xD0这样的字节序列典型的GBK编码中文。第三步确认文件内容iconv -f GBK -t UTF-8 module-common/src/main/resources/messages.properties输出正常确认是GBK编码。第四步转换编码iconv -f GBK -t UTF-8 module-common/src/main/resources/messages.properties /tmp/messages.properties mv /tmp/messages.properties module-common/src/main/resources/messages.properties第五步在根pom.xml里加上编码配置参考4.1节的配置。第六步重新构建mvn clean compile构建成功问题解决。5.2 另一个案例BOM头导致的诡异问题还有一个项目所有文件都确认是UTF-8编码但依然报Input length 1。用hexdump检查后发现某个.xml文件开头有ef bb bf也就是UTF-8 BOM。这个BOM头在大多数编辑器里是看不见的但Java读取时会把它当作文件内容的一部分。如果这个XML文件被maven-resources-plugin过滤BOM头就会被当作普通字符处理在某些情况下触发解码异常。解决办法就是去掉BOMsed -i 1s/^\xEF\xBB\xBF// module-service/src/main/resources/config/app-config.xml去掉之后重新构建问题消失。5.3 CI/CD流水线上的编码问题最麻烦的是CI/CD流水线上的编码问题。本地构建正常一到流水线就报错。这种情况通常是本地和流水线的默认编码不一致导致的。本地开发机可能是macOS或Linux默认UTF-8流水线如果跑在Windows Agent上默认可能是GBK。或者流水线的JVM参数里没有设置-Dfile.encodingUTF-8。解决办法是在流水线配置里显式设置环境变量export JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8 export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8或者在Maven命令里直接指定mvn clean compile -Dfile.encodingUTF-8提示JAVA_TOOL_OPTIONS环境变量会被JVM自动读取适合在CI/CD环境里全局设置编码。但注意它会影响所有Java进程如果流水线里还跑了其他Java应用需要确认不会产生副作用。6. 常见问题速查与避坑经验6.1 常见问题速查表问题现象可能原因快速排查解决方案报错但不提示具体文件插件日志级别不够加-X参数重新构建从debug日志里找文件名本地正常CI报错环境编码不一致检查LANG、file.encoding统一设置UTF-8环境变量只有部分文件报错混合编码file -i批量检测统一转成UTF-8升级插件后突然报错3.2.0更严格对比插件版本统一编码或降级插件文件看起来是UTF-8但报错可能有BOMhexdump看开头字节去掉BOM头转换编码后中文变乱码转换方向搞反了确认原文件编码用正确的-f参数6.2 避坑经验一不要依赖IDE的默认编码很多人觉得IDE里显示正常就没问题但IDE的编码设置和Maven的编码设置是两回事。IntelliJ IDEA默认可能用系统编码Eclipse可能用GBK而Maven插件用的是project.build.sourceEncoding。这三者不一致就会出问题。我的建议是在项目根目录放一个.editorconfig文件强制统一编码root true [*] charset utf-8 end_of_line lf insert_final_newline true trim_trailing_whitespace true [*.{properties,xml,json,yml,yaml}] charset utf-8这样大多数现代编辑器和IDE都会遵循这个配置减少编码不一致的概率。6.3 避坑经验二properties文件的特殊处理.properties文件在Java里有个历史遗留问题java.util.Properties默认用ISO-8859-1读取中文需要转成\uXXXX格式。虽然Maven插件不直接用Properties类但很多开发者会混淆这一点。对于.properties文件我的建议是如果项目用JDK 9可以用PropertyResourceBundle配合UTF-8读取如果必须兼容老版本把中文转成Unicode转义序列或者干脆用YAML替代propertiesSpring Boot项目推荐转换中文到Unicode可以用native2ascii工具JDK自带native2ascii -encoding UTF-8 messages.properties messages_ascii.properties6.4 避坑经验三Git的换行符配置Git在Windows和Linux之间同步代码时可能会自动转换换行符core.autocrlf。这个转换有时会引入不可见字符间接导致编码问题。建议在项目根目录加一个.gitattributes文件* textauto eollf *.png binary *.jpg binary *.jar binary *.zip binary这样能确保文本文件统一用LF换行二进制文件不被篡改。6.5 避坑经验四构建缓存导致的假象有时候你明明改了文件编码但重新构建还是报错。这可能是Maven的增量编译或者IDE的缓存导致的。解决办法是彻底清理mvn clean rm -rf target/如果用的是IDE还要清理IDE的缓存IntelliJ IDEA里是File - Invalidate Caches。6.6 避坑经验五不要忽略警告Maven在编码问题上有时会先给警告再报错。比如[WARNING] Using platform encoding (GBK actually) to copy filtered resources看到这种警告就要警惕了它意味着当前用的是平台默认编码而不是你期望的UTF-8。警告往往是大问题的前兆不要等到报错了才去处理。7. 长效预防机制7.1 在父POM里统一编码配置如果是多模块项目一定要在父POM里统一配置编码子模块继承即可properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding maven.compiler.encodingUTF-8/maven.compiler.encoding /properties build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version3.2.0/version configuration encodingUTF-8/encoding /configuration /plugin /plugins /pluginManagement /build7.2 加一个编码检查的构建步骤可以在validate阶段加一个编码检查插件提前发现问题plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version3.0.0/version executions execution idenforce-encoding/id goals goalenforce/goal /goals configuration rules requireProperty propertyproject.build.sourceEncoding/property message必须设置project.build.sourceEncoding为UTF-8/message /requireProperty /rules /configuration /execution /executions /plugin这样如果哪个模块忘了设置编码构建会直接失败并给出明确提示比等到resources阶段报Input length 1要友好得多。7.3 在CI/CD里加编码检测在流水线的构建脚本里加一段编码检测#!/bin/bash INVALID_FILES$(find src -type f \( -name *.java -o -name *.properties -o -name *.xml \) -exec file -i {} \; | grep -v charsetutf-8 | grep -v charsetus-ascii) if [ -n $INVALID_FILES ]; then echo 发现非UTF-8编码的文件 echo $INVALID_FILES exit 1 fi这段脚本会在构建前检查所有源文件发现非UTF-8编码就中断流水线把问题拦截在更早的阶段。7.4 团队规范层面的建议技术手段能解决大部分问题但最根本的还是团队规范。我在团队里推行的几条规则所有文本文件统一UTF-8无BOM编码这是硬性要求提交代码前用file -i自查一遍新增文件禁止在.properties里直接写中文用Unicode转义或改用YAML新项目初始化时就把编码配置写进父POM模板代码评审时把编码问题作为检查项之一这些规则看起来琐碎但能省下大量排查编码问题的时间。我算过一笔账一个编码问题从出现到定位到解决平均要花1到2小时而预防成本几乎为零。8. 一些补充的技术细节8.1 为什么是Input length 1而不是其他数字Input length 1里的数字表示解码器在当前位置读取的字节数。当解码器遇到一个非法字节时它会报告当前读取了多少字节。大多数情况下是1因为UTF-8解码器逐字节读取遇到非法起始字节就立即报错。如果报的是Input length 2或Input length 3说明解码器读取了多个字节后才发现问题通常是因为多字节序列的后续字节不合法。8.2 maven-resources-plugin各版本的行为差异版本编码默认行为特点3.0.x使用平台默认编码问题最多但报错少3.1.0使用project.build.sourceEncoding相对宽松3.2.0严格使用配置编码报错更明确但更容易触发3.3.x优化了错误提示会提示具体文件名如果项目还在用3.0.x强烈建议升级到3.2.0或更高版本虽然可能会暴露一些隐藏的编码问题但早暴露早解决。8.3 关于file.encoding系统属性file.encoding是JVM的一个系统属性影响InputStreamReader等类的默认编码。但它有个坑JVM启动后修改file.encoding不一定生效因为很多类在初始化时就已经缓存了编码。所以设置file.encoding最好通过JVM启动参数java -Dfile.encodingUTF-8 -jar your-app.jar或者在MAVEN_OPTS里设置export MAVEN_OPTS-Dfile.encodingUTF-88.4 关于Maven的filtering机制资源过滤的本质是文本替换。Maven会把资源文件当作文本读取替换${...}占位符然后写出去。这个过程中任何非文本内容都会导致问题。所以对于二进制文件图片、字体、压缩包等一定要通过nonFilteredFileExtensions排除不要让它们经过过滤流程。这不仅是为了避免编码错误也是为了保证二进制内容的完整性——文本读写可能会破坏二进制数据。8.5 一个容易忽略的细节文件末尾的换行有些编码问题是由文件末尾的换行符引起的。Windows的\r\n和Unix的\n在UTF-8下都是合法字符但如果文件末尾缺少换行某些工具可能会追加一个导致文件内容变化。建议在.editorconfig里设置insert_final_newline true确保所有文件末尾都有换行避免这类问题。9. 我在实际项目中的体会处理了这么多次Input length 1我最大的体会是编码问题从来不是单纯的技术问题而是工程规范问题。一个项目如果从一开始就统一了编码规范后面几乎不会遇到这类报错。反之如果编码规范缺失今天修好了这个文件明天可能又冒出另一个。另一个体会是不要怕报错怕的是报错信息不明确。Input length 1虽然看起来含糊但它至少告诉你是编码问题。比起那些静默失败、中文变乱码、构建成功但运行时报错的情况这种直接报错反而更好排查。最后分享一个我常用的小技巧在项目根目录放一个check-encoding.sh脚本每次提交代码前跑一下能拦截90%以上的编码问题。脚本内容就是前面7.3节那段简单但有效。团队里推广之后编码相关的构建失败率下降了八成以上。如果你现在正被这个报错卡住按照第4节的方案一步步来基本都能解决。如果试了所有方案还是不行那可能是更底层的问题比如文件系统损坏、磁盘坏道之类的那就需要换台机器验证一下了。