简介这是一款基于 Java 与 PDFBox 开发的开源命令行工具用于删除 PDF 文档中的文本水印。其核心能力是支持任意字体、任意编码及多种语言的水印识别既能处理单个文件也能批量遍历整个目录还允许通过参数指定输入与输出路径方便集成到脚本或持续集成流程中适合文档处理人员、Java 开发者以及需要将水印清理纳入自动化流程的开发者。压缩包共 24 个文件整体大小仅 115KB以 8 个 Java 源码文件、8 张 PNG 前后效果对比图和 2 份 Markdown 说明文档为主同时包含安装脚本、开源许可证、版本信息、Maven 配置与清单文件目录结构清晰便于阅读与二次开发。借助工程源码读者既能快速构建出可执行的命令行程序也能深入学习 PDFBox 如何解析页面、定位文字层并重建内容配合前后效果对比图可以直观了解不同字体和编码下的清除表现。目前已有 182 人学习/下载适合对 PDF 处理、命令行工具封装及自动化文档清理感兴趣的开发者参考。 我一直觉得PDF 处理里最“万金油”的需求就是去水印。尤其是文本水印比如“预览”、“Draft”、“Confidential”还有各种评估版 PDF 上的单位名称。早几年我接到这类需求第一反应是找在线工具传上去等半天出来的 PDF 要么丢失排版要么多出难看的色块要么水印其实还在只是被压淡了。后来接触到 pdf-unstamper 这个命令行工具总算是把“文本水印”这个场景彻底理顺了。它的卖点很直接不挑字体、不挑编码、不挑语言只要是渲染出来的文本水印基本都能用同一个思路处理掉。pdf-unstamper 是基于 Apache PDFBox 构建的 Java 开源工具GitHub 上的项目名是 hwding/pdf-unstamper。它不做 OCR不做文本识别也不依赖本地安装的字体库核心逻辑是“找到水印文字所在的几何区域然后用背景色把它盖住”。就这么一个朴素的思路反而解决了大量所谓“复杂水印”的问题。这篇文章我会从原理、安装、实操到常见坑位一步步讲清楚给正在被 PDF 水印折磨的朋友一个可以直接落地的参考。1. 这个工具解决的是什么问题1.1 文本水印和图像水印的区别先说清楚一个容易被混淆的点PDF 里的水印从技术形态上分两类。一类是图像水印就是整张图片铺在页面上半透明、带旋转这种本质上是一个位图对象pdf-unstamper 不处理它想去除得走图像修复的路子比如内容感知填充那是另一个工程了。另一类是文本水印也就是标题里说的 text watermark它是以文本对象的形式存在于 PDF 内容流里的每个字符都有坐标、字号、颜色在阅读器里还能被选中、复制。文本水印恰恰是日常工作里最常见的形态尤其是政府公文、学术论文、产品手册的预览版几乎全是文本水印。pdf-unstamper 的目标就是文本水印。它的优势在于不会像在线工具那样把整页转成图片再重排而是仍然保留原始 PDF 的矢量结构和可编辑性。处理完的 PDF 依然清晰文字依然可选排版基本不动这是很多在线工具做不到的。1.2 为什么在线工具常常“不靠谱”我早期用在线去水印工具踩过不少坑这里可以总结成几条典型现象上传到云端文件大小受限几百页的 PDF 根本传不上去。输出结果被重新渲染部分字体被替换中文变成乱码或者“方框字”。免费版强制加水印去完一个水印又多一个水印循环套娃。页面里的矢量图形被栅格化成图片放大后出现锯齿。更关键的是你根本不知道它的处理逻辑是什么出了问题也没法排查。本地命令行工具的体验就完全不一样了。处理逻辑透明、可控跑完以后可以立即用 PDF 阅读器检查效果不满意就换参数重跑不用反复上传下载。对于需要批量处理、或者涉及隐私文档的场景本地工具的优势更加明显文件根本不需要离开你的电脑。2. 核心原理为什么任意字体、任意编码、任意语言都不怕2.1 从“识别文字”到“识别色块”很多人第一次看到“支持任意字体、任意编码、任意语言”这个描述时直觉会以为它用了什么高级 NLP 或者 OCR 技术。其实恰恰相反它绕开了所有语言相关的处理。PDF 文本水印在内容流里本质是一串带定位信息的字形绘制指令。PDFBox 解析 PDF 后可以拿到每个字符的 TextPosition这个对象里记录了字符的精确坐标、字号、字体、颜色等属性。pdf-unstamper 利用的就是这些几何属性而不是文字本身的内容。换句话说它根本不在乎这个字符在 Unicode 里对应的是中文、日文、阿拉伯文还是某种古老的符号字体它只关心这个字符画在哪里有多大是什么颜色的。所以“任意语言”这个说法是成立的因为文本语义完全不在处理范围内。普通的文本提取方案遇到字体编码异常、字符映射缺失、CID 字体没嵌入等情况时很可能提取出来就是乱码或者干脆提取不到正则匹配那套自然全线崩溃。而 pdf-unstamper 是拿坐标和颜色做“物理定位”只要水印渲染出来了它就能定位到。2.2 覆盖式去除背后的算法逻辑具体实现上pdf-unstamper 会在每个页面里找出所有与背景色形成明显反差的文本块然后计算每个文本块的最小外接矩形把这些矩形块用背景色填充覆盖。这个过程有几个关键细节它会先分析页面背景色通常取页面底部的颜色作为基准。水印字符的绘制位置会被聚合相邻的字符会被合并成一个矩形区域。覆盖矩形用的是实心填充所以水印在视觉上会被完全盖住。页面处理是相互独立的因此可以多线程并行。这种算法有一个明显的优点即使水印字体没有嵌入 PDF即使系统缺少对应字库也不影响覆盖效果因为覆盖动作不依赖字形渲染只需要知道字符占用的位置即可。这也解释了为什么它能处理所谓“任何编码”——编码问题影响的是字符映射到 Unicode 的过程而覆盖过程完全跳过这一层。不过这里我要先说一个使用边界它的原理是“覆盖”不是“抹除”。处理后的文件如果拿去复制文本水印字符串很可能依然存在于文本层。视觉上你看不到它但内容流里那些绘制指令还在。如果你的需求是连文本层都要彻底清干净那需要的是另外一类内容流编辑工具不是 pdf-unstamper 的职责范围。3. 环境准备与安装3.1 检查 Java 环境pdf-unstamper 是 Java 工具第一步是确认机器上有可用的 JRE 或 JDK。版本方面建议 Java 8 或更高版本太老的 Java 6、Java 7 大概率跑不起来现代的 Maven 构建也需要较新版本。检查方式很简单java -version如果命令提示找不到 java那就需要先装 JDK。Windows 用户装完记得配 JAVA_HOME 环境变量macOS 用户可以用 Homebrew 装Linux 发行版通常用各自的包管理器即可。这里不再展开属于 Java 基础环境问题。3.2 源码编译构建推荐从 GitHub 拉源码编译好处是可以拿到最新代码也方便自己看实现逻辑。项目依赖 Maven所以需要先装 Maven然后执行git clone https://github.com/hwding/pdf-unstamper.git cd pdf-unstamper mvn clean package -DskipTests构建结束后在target目录下会生成一个带有jar-with-dependencies后缀的 jar 包那个就是可以直接运行的完整包所有依赖都被打进去了。我实测构建过程很顺没有多余的网路配置需求唯一要注意的是 Maven 首次构建会下载不少依赖需要网络畅通耐心等一会儿即可。3.3 直接用 release jar如果不想自己编译也可以直接从 GitHub 的 Releases 页面下载已经打好的 jar 包。下载后建议放到一个专门的工具目录比如~/tools/pdf-unstamper/然后创建一个别名或快捷命令方便后续调用。我个人习惯把 jar 重命名为简短的名字mv pdf-unstamper-0.7.0-jar-with-dependencies.jar pdf-unstamper.jar然后用一行命令验证是否可运行java -jar pdf-unstamper.jar -h能看到参数说明就说明环境没问题。如果提示UnsupportedClassVersionError基本上是 Java 版本太低升级 JDK 即可。4. 实操从命令行去水印4.1 基础用法pdf-unstamper 的使用方式非常简洁核心就两个参数输入文件和输出文件。java -jar pdf-unstamper.jar -i 带水印.pdf -o 去水印.pdf跑起来之后控制台会打印每一页的处理状态。处理速度和我预想的一样普通文本水印基本是秒级完成一个 200 页的 PDF 也就是几秒钟的事具体取决于水印数量和机器性能。这里有一个小建议输出文件不要和输入文件放在同一个路径下的同名文件因为工具不会自动做备份。万一处理结果不理想原文件被覆盖了就很尴尬。我一般把输出文件放在独立的output子目录里处理完先检查确认没问题再决定是否替换原文件。4.2 多线程参数与性能工具支持通过-t参数指定线程数比如java -jar pdf-unstamper.jar -i 带水印.pdf -o 去水印.pdf -t 4线程数的作用是并行处理多个页面。默认情况下它会自动使用机器可用核心数但如果你的机器内存比较紧张并行太多页面反而容易内存溢出这时手动调低-t反而更稳。反过来如果你处理的是几百页的大文件机器配置也不错可以适当调高线程数处理速度会明显提升。实测下来4 核 8 G 内存的机器处理 300 页、每页都有水印的 PDF默认参数大约 10 秒内完成。瓶颈主要不在 CPU 而在内存PDFBox 解析大文件时会有不小的内存占用这个后面会详细说。4.3 批量处理思路实际工作场景很少只处理一个文件批量去水印更常见。Windows 下可以用批处理脚本macOS 和 Linux 下写一个简单的 shell 循环即可。比如for f in *.pdf; do java -jar pdf-unstamper.jar -i $f -o output/${f%.pdf}_clean.pdf done注意脚本里一定要处理文件名中的空格和中文字符加引号是最基本的防守。我见过太多人在这一步翻车文件名里带空格导致路径被拆成两段工具直接报错说找不到文件。5. 效果验证与局限5.1 处理完怎么验证处理完一定要验证不要直接拿输出文件交付。我的验证习惯分三步用 PDF 阅读器打开输出文件肉眼检查每一页的水印区域是否干净特别是页眉页脚、页面中央和四角这几个水印高发位置。缩放检查一下覆盖矩形是否越界如果越界可能会压到正文文字或者表格线这种情况需要降低覆盖范围或者换工具处理。用文本提取工具抽查一下正文字符是否还完整。前面说过覆盖矩形是画在文本层上方的正常情况下正文的文本提取不受影响但万一算法定位出了偏差就可能把正文内容一起覆盖掉。这三步都过了再考虑覆盖原文件或者交付给业务方。5.2 它做不到的事任何工具都有边界pdf-unstamper 也一样。根据我自己的使用体会下面这几类场景它处理不了需要提前知道彩色渐变背景上的水印。覆盖矩形只能填一个纯色如果背景是渐变盖上以后会留下一块明显的补丁色块。水印颜色和背景色太接近。算法找的是“与背景形成反差”的文本如果水印是浅灰色压在白色背景下对比度不够它可能看不到。旋转任意角度的水印。算法用的是最小外接矩形对于横平竖直的水印没问题但如果水印是 45 度斜排的覆盖矩形会框出一个菱形补丁视觉上可能更难看。图像型水印、半透明水印、由矢量曲线组合 LOGO 这类非文本对象它一律不处理。这些情况下我的建议是重新考虑水印的来源拿到未加水印的原文件才是根治方案。去水印本身是“事后的补救”不是“万能的魔法”。6. 常见问题与排查技巧6.1 处理完了水印还在这是最常出现的“问题”但大概率不是工具的问题而是水印类型判断错误。先去 PDF 阅读器里点击水印文字看能不能选中文本。如果能选中那是文本水印理论上一轮覆盖就能去掉。如果选不中那水印很可能已经被转成曲线或者图片pdf-unstamper 对它无效。另一个隐蔽原因是水印颜色和背景对比度不足。工具默认会有一个颜色差阈值如果水印比较浅可能被当成背景的一部分导致检测不到。这种场景说实话没法通过调整参数一键解决比较务实的做法是用 PDF 编辑器先手动改一下背景色提高反差或者另想办法。6.2 页面出现额外色块出现色块通常意味着覆盖矩形定位偏了覆盖范围超出了水印区域压到了正文。常见的触发场景是水印文字和正文文字靠得太近算法合并矩形时把它们当成一个整体了。应对思路有两个一是检查原 PDF 是不是有多重水印层比如页脚有条形码或者印章它们也可能被误识别成水印二是换用更高版本的 jar新版本在矩形合并算法上做了不少优化误覆盖概率会低一些。如果你的 PDF 是扫描件那基本不要指望这个工具扫描件必须走 OCR 或者图像修复路线。6.3 大文件内存溢出PDFBox 处理几百 MB 的 PDF 时JVM 默认内存可能不够用报OutOfMemoryError很常见。解决办法是手动指定 JVM 堆内存比如java -Xmx2g -jar pdf-unstamper.jar -i 大文件.pdf -o 输出.pdf-Xmx2g表示最大堆内存 2 GB可以按机器内存调整。同时配合调低线程数减少并发页面数量带来的内存压力。我的经验是 8 GB 内存的笔记本给 JVM 分配 2 GB 就够了再大也意义不大反而影响系统其他程序运行。6.4 中文文件名和路径问题Windows 下如果文件路径含中文或者 jar 包放在带空格的目录里偶尔会出现找不到文件的现象。这个多半是控制台编码问题不是工具的 bug。最简单的解决办法是进入 jar 包所在的目录执行命令输入文件用相对路径输出文件名先改成英文处理完再重命名回中文。省心省事不用跟编码格式纠缠。顺手整理一个排查速查表方便大家对照现象可能原因解决办法水印完全没变化水印是图片或曲线换图像去水印方案水印变浅但还有颜色对比度不足提高背景反差后重试正文被色块盖住矩形合并越界换新版本 jar 或拆分 PDF 分页处理报 OOM 内存溢出JVM 堆内存不足加-Xmx2g参数中文路径找不到文件控制台编码问题切换英文路径重试我的实操心得最后分享两个细节。第一pdf-unstamper 适合的场景是“水印是后来批量加上的”也就是水印和正文不在同一个内容层里。如果水印和正文混在同一个文本流里覆盖效果会很差因为无法精准区分哪部分是水印哪部分是正文。第二处理前最好先复制一份原文件我的习惯是在原文件名后面加.bak.pdf这样哪怕处理结果不理想随时可以回到原点重来。工具本身很稳定但 PDF 这个格式的复杂度决定了任何自动化处理都可能遇到意外保留原始文件是最低成本的风控手段。这个工具后续还可以和脚本、文件监控配合比如指定目录里新出现的 PDF 自动去水印并归档属于工程化的小扩展了。如果你也经常和 PDF 水印打交道建议把它装进自己的工具集里处理文本水印的效率会明显上一个台阶。本文还有配套的精品资源点击获取 pdf-unstamper：基于PDFBox的命令行PDF文本水印去除指南
简介这是一款基于 Java 与 PDFBox 开发的开源命令行工具用于删除 PDF 文档中的文本水印。其核心能力是支持任意字体、任意编码及多种语言的水印识别既能处理单个文件也能批量遍历整个目录还允许通过参数指定输入与输出路径方便集成到脚本或持续集成流程中适合文档处理人员、Java 开发者以及需要将水印清理纳入自动化流程的开发者。压缩包共 24 个文件整体大小仅 115KB以 8 个 Java 源码文件、8 张 PNG 前后效果对比图和 2 份 Markdown 说明文档为主同时包含安装脚本、开源许可证、版本信息、Maven 配置与清单文件目录结构清晰便于阅读与二次开发。借助工程源码读者既能快速构建出可执行的命令行程序也能深入学习 PDFBox 如何解析页面、定位文字层并重建内容配合前后效果对比图可以直观了解不同字体和编码下的清除表现。目前已有 182 人学习/下载适合对 PDF 处理、命令行工具封装及自动化文档清理感兴趣的开发者参考。 我一直觉得PDF 处理里最“万金油”的需求就是去水印。尤其是文本水印比如“预览”、“Draft”、“Confidential”还有各种评估版 PDF 上的单位名称。早几年我接到这类需求第一反应是找在线工具传上去等半天出来的 PDF 要么丢失排版要么多出难看的色块要么水印其实还在只是被压淡了。后来接触到 pdf-unstamper 这个命令行工具总算是把“文本水印”这个场景彻底理顺了。它的卖点很直接不挑字体、不挑编码、不挑语言只要是渲染出来的文本水印基本都能用同一个思路处理掉。pdf-unstamper 是基于 Apache PDFBox 构建的 Java 开源工具GitHub 上的项目名是 hwding/pdf-unstamper。它不做 OCR不做文本识别也不依赖本地安装的字体库核心逻辑是“找到水印文字所在的几何区域然后用背景色把它盖住”。就这么一个朴素的思路反而解决了大量所谓“复杂水印”的问题。这篇文章我会从原理、安装、实操到常见坑位一步步讲清楚给正在被 PDF 水印折磨的朋友一个可以直接落地的参考。1. 这个工具解决的是什么问题1.1 文本水印和图像水印的区别先说清楚一个容易被混淆的点PDF 里的水印从技术形态上分两类。一类是图像水印就是整张图片铺在页面上半透明、带旋转这种本质上是一个位图对象pdf-unstamper 不处理它想去除得走图像修复的路子比如内容感知填充那是另一个工程了。另一类是文本水印也就是标题里说的 text watermark它是以文本对象的形式存在于 PDF 内容流里的每个字符都有坐标、字号、颜色在阅读器里还能被选中、复制。文本水印恰恰是日常工作里最常见的形态尤其是政府公文、学术论文、产品手册的预览版几乎全是文本水印。pdf-unstamper 的目标就是文本水印。它的优势在于不会像在线工具那样把整页转成图片再重排而是仍然保留原始 PDF 的矢量结构和可编辑性。处理完的 PDF 依然清晰文字依然可选排版基本不动这是很多在线工具做不到的。1.2 为什么在线工具常常“不靠谱”我早期用在线去水印工具踩过不少坑这里可以总结成几条典型现象上传到云端文件大小受限几百页的 PDF 根本传不上去。输出结果被重新渲染部分字体被替换中文变成乱码或者“方框字”。免费版强制加水印去完一个水印又多一个水印循环套娃。页面里的矢量图形被栅格化成图片放大后出现锯齿。更关键的是你根本不知道它的处理逻辑是什么出了问题也没法排查。本地命令行工具的体验就完全不一样了。处理逻辑透明、可控跑完以后可以立即用 PDF 阅读器检查效果不满意就换参数重跑不用反复上传下载。对于需要批量处理、或者涉及隐私文档的场景本地工具的优势更加明显文件根本不需要离开你的电脑。2. 核心原理为什么任意字体、任意编码、任意语言都不怕2.1 从“识别文字”到“识别色块”很多人第一次看到“支持任意字体、任意编码、任意语言”这个描述时直觉会以为它用了什么高级 NLP 或者 OCR 技术。其实恰恰相反它绕开了所有语言相关的处理。PDF 文本水印在内容流里本质是一串带定位信息的字形绘制指令。PDFBox 解析 PDF 后可以拿到每个字符的 TextPosition这个对象里记录了字符的精确坐标、字号、字体、颜色等属性。pdf-unstamper 利用的就是这些几何属性而不是文字本身的内容。换句话说它根本不在乎这个字符在 Unicode 里对应的是中文、日文、阿拉伯文还是某种古老的符号字体它只关心这个字符画在哪里有多大是什么颜色的。所以“任意语言”这个说法是成立的因为文本语义完全不在处理范围内。普通的文本提取方案遇到字体编码异常、字符映射缺失、CID 字体没嵌入等情况时很可能提取出来就是乱码或者干脆提取不到正则匹配那套自然全线崩溃。而 pdf-unstamper 是拿坐标和颜色做“物理定位”只要水印渲染出来了它就能定位到。2.2 覆盖式去除背后的算法逻辑具体实现上pdf-unstamper 会在每个页面里找出所有与背景色形成明显反差的文本块然后计算每个文本块的最小外接矩形把这些矩形块用背景色填充覆盖。这个过程有几个关键细节它会先分析页面背景色通常取页面底部的颜色作为基准。水印字符的绘制位置会被聚合相邻的字符会被合并成一个矩形区域。覆盖矩形用的是实心填充所以水印在视觉上会被完全盖住。页面处理是相互独立的因此可以多线程并行。这种算法有一个明显的优点即使水印字体没有嵌入 PDF即使系统缺少对应字库也不影响覆盖效果因为覆盖动作不依赖字形渲染只需要知道字符占用的位置即可。这也解释了为什么它能处理所谓“任何编码”——编码问题影响的是字符映射到 Unicode 的过程而覆盖过程完全跳过这一层。不过这里我要先说一个使用边界它的原理是“覆盖”不是“抹除”。处理后的文件如果拿去复制文本水印字符串很可能依然存在于文本层。视觉上你看不到它但内容流里那些绘制指令还在。如果你的需求是连文本层都要彻底清干净那需要的是另外一类内容流编辑工具不是 pdf-unstamper 的职责范围。3. 环境准备与安装3.1 检查 Java 环境pdf-unstamper 是 Java 工具第一步是确认机器上有可用的 JRE 或 JDK。版本方面建议 Java 8 或更高版本太老的 Java 6、Java 7 大概率跑不起来现代的 Maven 构建也需要较新版本。检查方式很简单java -version如果命令提示找不到 java那就需要先装 JDK。Windows 用户装完记得配 JAVA_HOME 环境变量macOS 用户可以用 Homebrew 装Linux 发行版通常用各自的包管理器即可。这里不再展开属于 Java 基础环境问题。3.2 源码编译构建推荐从 GitHub 拉源码编译好处是可以拿到最新代码也方便自己看实现逻辑。项目依赖 Maven所以需要先装 Maven然后执行git clone https://github.com/hwding/pdf-unstamper.git cd pdf-unstamper mvn clean package -DskipTests构建结束后在target目录下会生成一个带有jar-with-dependencies后缀的 jar 包那个就是可以直接运行的完整包所有依赖都被打进去了。我实测构建过程很顺没有多余的网路配置需求唯一要注意的是 Maven 首次构建会下载不少依赖需要网络畅通耐心等一会儿即可。3.3 直接用 release jar如果不想自己编译也可以直接从 GitHub 的 Releases 页面下载已经打好的 jar 包。下载后建议放到一个专门的工具目录比如~/tools/pdf-unstamper/然后创建一个别名或快捷命令方便后续调用。我个人习惯把 jar 重命名为简短的名字mv pdf-unstamper-0.7.0-jar-with-dependencies.jar pdf-unstamper.jar然后用一行命令验证是否可运行java -jar pdf-unstamper.jar -h能看到参数说明就说明环境没问题。如果提示UnsupportedClassVersionError基本上是 Java 版本太低升级 JDK 即可。4. 实操从命令行去水印4.1 基础用法pdf-unstamper 的使用方式非常简洁核心就两个参数输入文件和输出文件。java -jar pdf-unstamper.jar -i 带水印.pdf -o 去水印.pdf跑起来之后控制台会打印每一页的处理状态。处理速度和我预想的一样普通文本水印基本是秒级完成一个 200 页的 PDF 也就是几秒钟的事具体取决于水印数量和机器性能。这里有一个小建议输出文件不要和输入文件放在同一个路径下的同名文件因为工具不会自动做备份。万一处理结果不理想原文件被覆盖了就很尴尬。我一般把输出文件放在独立的output子目录里处理完先检查确认没问题再决定是否替换原文件。4.2 多线程参数与性能工具支持通过-t参数指定线程数比如java -jar pdf-unstamper.jar -i 带水印.pdf -o 去水印.pdf -t 4线程数的作用是并行处理多个页面。默认情况下它会自动使用机器可用核心数但如果你的机器内存比较紧张并行太多页面反而容易内存溢出这时手动调低-t反而更稳。反过来如果你处理的是几百页的大文件机器配置也不错可以适当调高线程数处理速度会明显提升。实测下来4 核 8 G 内存的机器处理 300 页、每页都有水印的 PDF默认参数大约 10 秒内完成。瓶颈主要不在 CPU 而在内存PDFBox 解析大文件时会有不小的内存占用这个后面会详细说。4.3 批量处理思路实际工作场景很少只处理一个文件批量去水印更常见。Windows 下可以用批处理脚本macOS 和 Linux 下写一个简单的 shell 循环即可。比如for f in *.pdf; do java -jar pdf-unstamper.jar -i $f -o output/${f%.pdf}_clean.pdf done注意脚本里一定要处理文件名中的空格和中文字符加引号是最基本的防守。我见过太多人在这一步翻车文件名里带空格导致路径被拆成两段工具直接报错说找不到文件。5. 效果验证与局限5.1 处理完怎么验证处理完一定要验证不要直接拿输出文件交付。我的验证习惯分三步用 PDF 阅读器打开输出文件肉眼检查每一页的水印区域是否干净特别是页眉页脚、页面中央和四角这几个水印高发位置。缩放检查一下覆盖矩形是否越界如果越界可能会压到正文文字或者表格线这种情况需要降低覆盖范围或者换工具处理。用文本提取工具抽查一下正文字符是否还完整。前面说过覆盖矩形是画在文本层上方的正常情况下正文的文本提取不受影响但万一算法定位出了偏差就可能把正文内容一起覆盖掉。这三步都过了再考虑覆盖原文件或者交付给业务方。5.2 它做不到的事任何工具都有边界pdf-unstamper 也一样。根据我自己的使用体会下面这几类场景它处理不了需要提前知道彩色渐变背景上的水印。覆盖矩形只能填一个纯色如果背景是渐变盖上以后会留下一块明显的补丁色块。水印颜色和背景色太接近。算法找的是“与背景形成反差”的文本如果水印是浅灰色压在白色背景下对比度不够它可能看不到。旋转任意角度的水印。算法用的是最小外接矩形对于横平竖直的水印没问题但如果水印是 45 度斜排的覆盖矩形会框出一个菱形补丁视觉上可能更难看。图像型水印、半透明水印、由矢量曲线组合 LOGO 这类非文本对象它一律不处理。这些情况下我的建议是重新考虑水印的来源拿到未加水印的原文件才是根治方案。去水印本身是“事后的补救”不是“万能的魔法”。6. 常见问题与排查技巧6.1 处理完了水印还在这是最常出现的“问题”但大概率不是工具的问题而是水印类型判断错误。先去 PDF 阅读器里点击水印文字看能不能选中文本。如果能选中那是文本水印理论上一轮覆盖就能去掉。如果选不中那水印很可能已经被转成曲线或者图片pdf-unstamper 对它无效。另一个隐蔽原因是水印颜色和背景对比度不足。工具默认会有一个颜色差阈值如果水印比较浅可能被当成背景的一部分导致检测不到。这种场景说实话没法通过调整参数一键解决比较务实的做法是用 PDF 编辑器先手动改一下背景色提高反差或者另想办法。6.2 页面出现额外色块出现色块通常意味着覆盖矩形定位偏了覆盖范围超出了水印区域压到了正文。常见的触发场景是水印文字和正文文字靠得太近算法合并矩形时把它们当成一个整体了。应对思路有两个一是检查原 PDF 是不是有多重水印层比如页脚有条形码或者印章它们也可能被误识别成水印二是换用更高版本的 jar新版本在矩形合并算法上做了不少优化误覆盖概率会低一些。如果你的 PDF 是扫描件那基本不要指望这个工具扫描件必须走 OCR 或者图像修复路线。6.3 大文件内存溢出PDFBox 处理几百 MB 的 PDF 时JVM 默认内存可能不够用报OutOfMemoryError很常见。解决办法是手动指定 JVM 堆内存比如java -Xmx2g -jar pdf-unstamper.jar -i 大文件.pdf -o 输出.pdf-Xmx2g表示最大堆内存 2 GB可以按机器内存调整。同时配合调低线程数减少并发页面数量带来的内存压力。我的经验是 8 GB 内存的笔记本给 JVM 分配 2 GB 就够了再大也意义不大反而影响系统其他程序运行。6.4 中文文件名和路径问题Windows 下如果文件路径含中文或者 jar 包放在带空格的目录里偶尔会出现找不到文件的现象。这个多半是控制台编码问题不是工具的 bug。最简单的解决办法是进入 jar 包所在的目录执行命令输入文件用相对路径输出文件名先改成英文处理完再重命名回中文。省心省事不用跟编码格式纠缠。顺手整理一个排查速查表方便大家对照现象可能原因解决办法水印完全没变化水印是图片或曲线换图像去水印方案水印变浅但还有颜色对比度不足提高背景反差后重试正文被色块盖住矩形合并越界换新版本 jar 或拆分 PDF 分页处理报 OOM 内存溢出JVM 堆内存不足加-Xmx2g参数中文路径找不到文件控制台编码问题切换英文路径重试我的实操心得最后分享两个细节。第一pdf-unstamper 适合的场景是“水印是后来批量加上的”也就是水印和正文不在同一个内容层里。如果水印和正文混在同一个文本流里覆盖效果会很差因为无法精准区分哪部分是水印哪部分是正文。第二处理前最好先复制一份原文件我的习惯是在原文件名后面加.bak.pdf这样哪怕处理结果不理想随时可以回到原点重来。工具本身很稳定但 PDF 这个格式的复杂度决定了任何自动化处理都可能遇到意外保留原始文件是最低成本的风控手段。这个工具后续还可以和脚本、文件监控配合比如指定目录里新出现的 PDF 自动去水印并归档属于工程化的小扩展了。如果你也经常和 PDF 水印打交道建议把它装进自己的工具集里处理文本水印的效率会明显上一个台阶。本文还有配套的精品资源点击获取