简介这份资源面向需要在 Java 项目中集成图文识别的开发者围绕 OCR 场景给出三套可落地的技术方案对比与示例代码。方案一基于个人申请的云服务接口识别准确率高、速度快但每月请求次数受限且后期可能收费方案二采用 Tesseract 开源引擎免费但需将图片插入 PDF 后识别准确率偏低、易出现乱码方案三在方案二基础上优化拓展仍受图片须正向不旋转的限制。文档中给出了 APPID、API KEY、SECRET KEY 的配置方式以及超时、代理、日志等参数设置并附有 PDF 渲染与 Tesseract 识别的完整调用片段便于读者对照选型与快速验证。资源包共 1 个 docx 文件约 12KB结构紧凑、重点突出。已有 273 人学习适合需要权衡成本、准确率与调用限制的 Java 开发者参考。1. 从一张发票照片说起Java 做 OCR 的三条路怎么选上周同事丢过来一张手机拍的发票照片问能不能用 Java 直接把上面的文字抠出来。我第一反应不是写代码而是先问清楚这图是偶尔来一张还是每天几千张能不能联网预算多少因为 Java 做图文识别这件事方案选错比代码写错更致命。这份资源把三条路摆得很清楚一条是调云端 OCR 接口识别准、速度快但每月有请求次数上限另外两条是本地 Tesseract 开源方案免费但准确率打折还挑图片方向。下面我按「能干什么、怎么跑、怎么改」把这三套代码拆开讲适合手里有 Java 项目、需要快速接入文字识别能力的开发者照着复现。2. 三套方案的技术选型与依赖结构2.1 方案一云端 OCR SDK 的调用链路方案一走的是 SDK 直连的路子核心依赖是一个 OCR 客户端类AipOcr构造时吃三个凭证APP_ID、API_KEY、SECRET_KEY。这三个值从控制台申请后填进常量代码里用public static final声明好处是全局唯一、编译期就能检查拼写。整个调用链路很短new 客户端 → 设超时 → 调basicGeneral→ 拿回JSONObject。真正干活的是basicGeneral它把本地图片读成字节流、按接口协议打包、发 HTTP 请求、再把响应解析成 JSON 返回。这条路把网络、鉴权、重试都封在 SDK 里业务代码只关心入参和出参。从工程角度看这种方案适合识别质量要求高、调用量可控的场景比如后台管理系统里人工上传票据后触发一次识别。它的短板也很直白每月 1000 次的总量部分细分接口只有 200 或 500 次一旦业务量上来就会撞墙。所以我在项目里一般会把它包一层加计数和降级后面改造章节会讲。2.2 方案二与方案三Tesseract 本地识别的两种接法方案二和方案三是同一条技术路线的两个变体底层都是 Tesseract 引擎加 PDFBox 做 PDF 渲染。方案二的做法是先用PDDocument.load打开一个现成 PDF再用PDFRenderer.renderImageWithDPI把每一页按 300 DPI 渲染成BufferedImage最后丢给tesseract.doOCR识别。也就是说它要求输入本身就是 PDF图片得先塞进 PDF 里才能走这条路这是它最大的使用限制。方案三则反过来先拿一张普通图片用 PDFBox 新建一个PDPage通过PDImageXObject.createFromFile把图片画到页面上存成临时 PDF再走方案二那套渲染加识别的流程。它多了一步「图片转 PDF」本质是为了复用 PDFBox 的渲染能力同时通过page.setRotation(270)处理方向问题。两条路都免费但都受限于 Tesseract 的识别质量复杂版式、手写体、低质量照片上容易出乱码。2.3 依赖清单与目录约定把三套代码放一起依赖大致是这几块实际建 Maven 工程时按这个补依赖用途对应方案OCR SDK含AipOcr云端识别客户端方案一tess4jTesseract 的 Java 封装方案二、三pdfboxPDF 加载、渲染、生成方案二、三log4jSDK 日志输出配置方案一语言数据包chi_sim、engTesseract 识别语料方案二、三目录上我习惯按方案分目录ocr/cloud、ocr/local、ocr/local/pdf三层语言数据包单独放resources/tessdata路径通过配置注入而不是写死。原代码里setDatapath(E:\\projectO\\language-library-language)这种绝对路径是典型的本地调试写法挪到别的机器上必翻车后面避坑章节会专门说。3. 把三套代码跑起来从凭证配置到识别输出3.1 方案一的最小可运行骨架先看云端方案。核心就是初始化客户端、设超时、调接口三步代码不长但每个参数都有讲究// 凭证常量从控制台申请后填入切勿硬编码进版本库 public static final String APP_ID XXXXXXX; public static final String API_KEY XXXXXXX; public static final String SECRET_KEY XXXXXXX; public static void main(String[] args) { // 初始化 OCR 客户端三个凭证缺一不可 AipOcr client new AipOcr(APP_ID, API_KEY, SECRET_KEY); // 连接超时 2 秒建连阶段不该拖太久 client.setConnectionTimeoutInMillis(2000); // 读取超时 60 秒大图上传加服务端识别留足余量 client.setSocketTimeoutInMillis(60000); // 待识别图片路径实际项目应从上传流或对象存储读取 String path D:\\AppImage\\QD\\ocrImage\\78_CMAU8602333.jpg; // basicGeneral 是通用文字识别第二个参数放可选配置 JSONObject res client.basicGeneral(path, new HashMapString, String()); System.out.println(res.toString(2)); }setConnectionTimeoutInMillis管的是 TCP 建连2000 毫秒对公网接口够用setSocketTimeoutInMillis管的是数据读写识别大图时服务端处理慢给到 60000 毫秒比较稳。basicGeneral的第二个参数是HashMap用来传语言类型、是否检测方向等可选开关不传就按默认走。返回的JSONObject里通常有words_result数组每个元素带words字段遍历取值即可。这里toString(2)是带缩进打印调试时看结构很方便生产环境记得换成按字段解析。3.2 方案二PDF 逐页渲染再识别方案二的关键在于「PDF 转图」这一步DPI 和语言包是两个最容易出问题的参数// 创建 Tesseract 实例 ITesseract tesseract new Tesseract(); // 语言数据包目录chi_sim.traineddata 必须放在这里 tesseract.setDatapath(E:\\projectO\\language-library-language); // 指定简体中文 tesseract.setLanguage(chi_sim); // 加载 PDF PDDocument document PDDocument.load(new File(D:\\AppImage\\QD\\ocrImage\\测试.pdf)); PDFRenderer pdfRenderer new PDFRenderer(document); for (int page 0; page document.getNumberOfPages(); page) { // 300 DPI 渲染低于 200 识别率明显下降高于 400 收益递减还费内存 BufferedImage bufferedImage pdfRenderer.renderImageWithDPI(page, 300, ImageType.RGB); // 对渲染出的位图做 OCR String text tesseract.doOCR(bufferedImage); System.out.println(text); } document.close();setDatapath指向的是存放chi_sim.traineddata的目录不是文件本身指错了会直接抛「找不到语言数据」。renderImageWithDPI的 300 是个经验值扫描件用 300 基本够手机拍的图本身分辨率就低硬拉到 300 只是放大像素识别率不会变好。doOCR接受BufferedImage返回整页文本多页 PDF 要循环处理每页单独识别再拼接。3.3 方案三图片转 PDF 再识别的完整流程方案三多了一层「图片先落成 PDF」代码更长但把方向控制暴露出来了ITesseract tesseract new Tesseract(); tesseract.setDatapath(E:\\projectO\\language-library-language); // 中英混排场景用加号连接语言包 tesseract.setLanguage(engchi_sim); String imagePath D:\\AppImage\\QD\\ocrImage\\79_CMAU8602333.jpg; String pdfPath D:\\AppImage\\QD\\ocrImage\\output.pdf; // 新建单页 PDF把图片画上去 PDDocument document new PDDocument(); PDPage page new PDPage(); page.setRotation(270); // 处理图片方向按实际拍摄角度调整 document.addPage(page); PDImageXObject pdImage PDImageXObject.createFromFile(imagePath, document); PDPageContentStream contentStream new PDPageContentStream(document, page); // 左下角为原点宽高取图片原始尺寸 contentStream.drawImage(pdImage, 0, 0, pdImage.getWidth(), pdImage.getHeight()); contentStream.close(); document.save(pdfPath); document.close(); // 再走一遍 PDF 渲染加识别 PDDocument document2 PDDocument.load(new File(pdfPath)); PDFRenderer pdfRenderer new PDFRenderer(document2); BufferedImage bufferedImage pdfRenderer.renderImageWithDPI(0, 300, ImageType.RGB); String text tesseract.doOCR(bufferedImage); System.out.println(text);setLanguage(engchi_sim)让引擎同时加载中英两套语料适合票据里混着英文编号的场景代价是识别速度变慢。page.setRotation(270)是这套代码里最玄学的一行它决定图片在 PDF 页面上的朝向Tesseract 对倒置、旋转 90 度的文字识别率极低所以方向必须和原图一致。drawImage的四个参数是左下角坐标加宽高用pdImage.getWidth()保持原始比例别手动缩放缩放会引入插值模糊。4. 避坑与排查五个真实会踩的坑4.1 凭证硬编码导致泄露现象是代码提交后凭证出现在版本库里或者换环境后识别全部报鉴权失败。原因是APP_ID这类常量直接写死在源码里多人协作时一提交就扩散。解决是把凭证挪到环境变量或配置中心代码里用System.getenv或配置注入读取本地开发用.env文件且加进.gitignore。我一般还会在启动时校验三个值非空缺了直接 fail-fast别等到第一次调用才发现。4.2 语言数据包路径写死现象是换台机器跑 Tesseract 就抛「Failed to load language data」。原因是setDatapath用了E:\\projectO\\...这种绝对路径只在那台开发机上成立。解决是把tessdata目录放进src/main/resources运行时用getResource拿到实际路径或者打成 jar 后解压到临时目录再指过去。注意traineddata文件体积不小别打进每次构建的产物里反复拷贝。4.3 DPI 与图片方向导致识别率骤降现象是同一张图方案一识别得好好的Tesseract 出来一堆乱码。原因通常是两个渲染 DPI 太低低于 200导致笔画糊在一起或者图片方向不对旋转 90 度、180 度。解决是先确认原图方向用setRotation或图像预处理摆正再把 DPI 提到 300 左右。如果原图本身分辨率就低别指望拉高 DPI 能救得从源头换清晰图。4.4 请求次数超限没有兜底现象是月初跑得好好的月中突然全部返回限额错误。原因是方案一每月 1000 次、部分接口 200 或 500 次的硬上限业务量一涨就撞线。解决是在调用层加计数器和本地缓存同一张图识别过就存结果重复请求直接命中缓存再配一个降级开关超限后自动切到本地 Tesseract 兜底虽然准确率降了但不至于整个功能挂掉。4.5 PDF 资源未关闭导致句柄泄漏现象是批量处理几百个 PDF 后进程内存飙升甚至 OOM。原因是PDDocument和PDPageContentStream都是需要显式关闭的资源异常路径上容易漏。解决是用 try-with-resources 包住PDDocumentPDPageContentStream在 finally 里 close别只写 happy path。批量任务里我还会每处理 N 个文件主动System.gc()一次做兜底虽然不优雅但能压住峰值。5. 二次开发把三套方案拼成一个可切换的识别服务真正落地时没人会把三套main方法直接搬进业务代码。我的做法是抽一个OcrService接口三个实现类分别对应云端、Tesseract-PDF、Tesseract-图片用策略模式按配置切换。核心是统一入参出参入参是图片字节流或文件路径出参是ListString文本行把JSONObject解析和doOCR的差异都封在实现里。public interface OcrService { // 统一入口传图片路径返回识别出的文本行 ListString recognize(String imagePath); } public class CloudOcrService implements OcrService { private final AipOcr client; private final AtomicInteger monthlyCount new AtomicInteger(0); private static final int LIMIT 1000; public CloudOcrService(String appId, String apiKey, String secretKey) { this.client new AipOcr(appId, apiKey, secretKey); this.client.setConnectionTimeoutInMillis(2000); this.client.setSocketTimeoutInMillis(60000); } Override public ListString recognize(String imagePath) { // 超限直接抛异常由上层决定降级 if (monthlyCount.incrementAndGet() LIMIT) { throw new IllegalStateException(cloud ocr quota exceeded); } JSONObject res client.basicGeneral(imagePath, new HashMap()); JSONArray arr res.getJSONArray(words_result); ListString lines new ArrayList(); for (int i 0; i arr.size(); i) { lines.add(arr.getJSONObject(i).getString(words)); } return lines; } }上层再包一个FallbackOcrService先调云端捕获限额异常后切本地实现。这样业务代码只依赖OcrService换方案改一行配置就行。验证方法也简单准备一组固定测试图分别跑三个实现对比文本行数和关键字段命中率云端方案通常能到九成以上Tesseract 在清晰扫描件上七八成手机拍的图可能只有五六成这个差距心里要有数。还有一个具体技巧Tesseract 识别前先做灰度化和二值化用BufferedImage逐像素处理把背景噪点压掉识别率能提一截。我一般会写个ImagePreprocessor工具类灰度公式用0.299R 0.587G 0.114B二值化阈值取 128 起步再按样本微调。这套预处理对方案二、三都适用是性价比最高的改造点。血泪经验是别一上来就追求「一个方案打天下」。云端准但有限额本地免费但挑图正确姿势是云端做主力、本地做兜底、预处理做增强三层叠起来才稳。从那以后我每次接 OCR 需求都强制先把「调用量、图片质量、能否联网」三个问题问清楚再动手省得写完才发现方案选错返工。希望帮到你。本文还有配套的精品资源点击获取