C OCR 又补齐 Java 生态了！lw.PPOCR.C v0.1.0-preview.7 发布

C OCR 又补齐 Java 生态了！lw.PPOCR.C v0.1.0-preview.7 发布

lw.PPOCR.C 的单文件离线 OCR 方案又进一步完善了。

在上一版 v0.1.0-.6 中，我们重点完成了 ARM64 支持，让同一套纯 C OCR 可以运行在 、Linux、 和 上。

这几天收到了一些非常有价值的反馈。

有人问：

支持 Java 吗？

还有用户继续问：

能不能通过 直接生成 Java 调用需要的 DLL 和 SO？

与此同时，HTML 版本也有人提出：

能不能直接粘贴截图识别？

这些需求都很实际。

于是 v0.1.0-.7 的方向也很明确：

继续降低 OCR 的集成和使用门槛。

这一版主要补齐了桌面 Java/JVM 支持、 Java 支持，同时让单文件 HTML 可以直接通过 Ctrl+V / V 粘贴截图进行 OCR。

一、普通 Java/JVM 现在可以直接调用 lw.PPOCR.C

之前 lw.PPOCR.C 已经有比较稳定的纯 C ABI，也有 C、C#、、 等接入方式。

但对于普通桌面 Java 项目来说，还缺少最后一层。

现在补上了。

整体结构非常简单：

Java / JVM
    ↓
Java Wrapper
    ↓
JNI
    ↓
lw_ppocr_java.dll / .so
    ↓
lw_ppocr_c.dll / .so
    ↓
PP-OCRv6 Tiny

也就是说，这不是 Java，而是普通的：

Windows + Java
Linux + Java

项目。

目前已经通过 CI 实际验证：

Java 8+
Windows x64
Linux x64

Java 层不需要接入C OCR 又补齐 Java 生态了！lw.PPOCR.C v0.1.0-preview.7 发布，也不需要 ONNX 、 或 。

图片读取直接使用 Java 标准库 。

例如，一个最小调用大致就是这样：

try (NativeOcr ocr = new NativeOcr(
        "models",
        false,
        0)) {
    String[] lines =
            ocr.recognizeFile("test.jpg");
    for (String line : lines) {
        System.out.println(line);
    }
}

Java 负责图片读取，JNI 只是很薄的一层桥接，真正的：

DET
CLS
REC

仍然由 lw.PPOCR.C 完成。

这也是整个项目一直坚持的思路：

核心能力尽量集中在一套轻量级纯 C 中，上层语言只做薄封装。

二、 DLL、Linux SO 已经直接放进

如果只是提供 JNI 示例，Java 用户仍然需要：

准备 JDK
准备 CMake
准备编译器
自己编 JNI

对很多只想“拿来用”的用户来说，还是稍微麻烦了一点。

所以这次把 CI 继续往前做了一步。

现在 会分别在：

Windows Server 2022 x64
Ubuntu 22.04 x64

环境中：

编译 lw.PPOCR.C
        ↓
安装 Development Package
        ↓
通过安装包编译 Java JNI
        ↓
整理最终 Bundle
        ↓
校验 DLL / SO
        ↓
校验 SHA256
        ↓
实际运行 Java OCR
        ↓
检查中文识别结果
        ↓
生成 Release 产物

换句话说，我们测试的已经不是：

“代码能不能编译。”

而是：

“最终准备交给用户下载的那一包文件，到底能不能真实完成 OCR。”

v0.1.0-.7 中现在直接提供：

lw.PPOCR.C-0.1.0-java-jni-windows-x64.zip

以及：

lw.PPOCR.C-0.1.0-java-jni-linux-x64.tar.gz

包中包含 JNI DLL、核心 OCR DLL、Java 示例、PP-OCRv6 Tiny 模型、字典以及相关 和校验文件。

Linux 包则提供对应的 .so。

Linux 版本还专门检查了 $ RPATHC OCR 又补齐 Java 生态了！lw.PPOCR.C v0.1.0-preview.7 发布，使 JNI .so 可以从自身目录找到核心 .so。

所以对于普通 Java 用户来说，这一版已经可以做到：

下载 → 解压 → 编译 Java 示例 → 直接运行。

三、 也补上了完整 Java 接入

上一版 示例主要使用 。

虽然 AAR 本身可以被 Java 项目调用，但对于纯 Java 项目来说，使用体验还不够直观。

所以 .7 又补了一层。

现在 AAR 增加了 Java 更容易调用的同步接口，例如：

LwPpocrEngine.createBlocking(...)

以及：

engine.recognizeBlocking(...)

同时仓库新增：

android/demo-java/

这是一个真正的纯 Java Demo 模块。

Demo 中没有为了“Java 示例”再重新写一套 JNI。

Java 和 最终仍然共用：

Android API
    ↓
JNI
    ↓
lw.PPOCR.C

这意味着底层 只有一份。

Java Demo 目前包含图片选择、后台解码、EXIF 方向处理、大图片采样、 转换、CLS、阅读顺序、OCR 调用以及 生命周期管理。

所以现在 端已经可以比较明确地说：

可以用java wrapper，Java 也可以用。

四、单文件 HTML 现在可以直接 Ctrl+V 粘贴截图

这个功能其实很小，但我个人觉得是 .7 里非常实用的一项改进。

以前使用 HTML OCR，通常是：

截图
↓
保存图片
↓
打开 HTML
↓
选择图片
↓
开始识别

现在可以变成：

Win + Shift + S
↓
截图
↓
Ctrl + V
↓
开始识别

macOS 则可以直接：

V

粘贴。

也就是说java wrapper，剪贴板里的截图可以直接进入 HTML 页面。

不需要先保存文件。

而且这个功能没有引入新的服务器、 权限或者网络请求。

实现链路仍然是：

系统剪贴板
    ↓
Browser File / Blob
    ↓
Canvas
    ↓
WASM
    ↓
lw.PPOCR.C

所有内容继续在浏览器本地处理。

图片不会上传到网络。

五、为什么粘贴后没有自动 OCR？

这里我们特意保留了一个设计：

Ctrl + V
↓
加载图片
↓
显示预览
↓
点击“开始识别”

而不是：

Ctrl + V
↓
立即 OCR

原因是用户识别之前可能还需要修改：

CLS
阅读顺序

同时也与当前：

选择图片
拖入图片
打开 PDF

的交互方式保持一致。

所以目前单文件 HTML 支持的输入方式已经变成：

选择图片
拖入图片
粘贴截图
打开 PDF

对于日常截图 OCR 来说，操作已经非常接近一个桌面小工具。

但它本质上仍然只是：

一个 HTML 文件。

六、一个 HTMLjava wrapper，依然完全离线

这是 lw.PPOCR.C Web 方案一直比较强调的一点。

下载：

lw.PPOCR.C-0.1.0-ocr-demo.html

以后直接双击即可使用。

里面已经包含：

OCR WASM Runtime
PP-OCRv6 Tiny 模型
字典
Web UI
PDF.js
PDF 解码组件

所以不需要：

Python
Node.js
Web Server
OpenCV
ONNX Runtime
Paddle Runtime

也不需要安装浏览器插件。

一个现代浏览器即可运行。

现在又增加了粘贴截图以后，我觉得这个定位更加清晰了：

“随身携带的离线 OCR”——一个 HTML，图片、截图和扫描 PDF 都能识别。

七、这一版更像是在完善“接入生态”

v0.1.0-.7 并没有去增加新的 OCR 模型。

核心仍然是：

PP-OCRv6 Tiny
FP32
CPU
DET + optional CLS + REC

这一版主要解决的是：

怎样让不同技术栈的开发者更方便地使用这一套 。

现在整个项目的接入关系已经逐渐变成：

                 lw.PPOCR.C
                     │
        ┌─────────┼────────┐
        │            │           │
        C           C#            Java
                                  │
                          ┌─────┴─────┐
                          │               │
                          Desktop JVM          Android
                          │               │
                          JNI DLL/SO           AAR
        │
        ├──────── WebAssembly
        │
        └──────── Standalone HTML

底层始终还是同一套：

纯 C OCR Runtime

这也是我比较希望 lw.PPOCR.C 最终形成的形态：

OCR 本身尽量小、稳定、独立；不同平台只负责提供最薄的一层集成。

八、v0.1.0-.7 下载内容

目前 中已经包括：

其中这一次新增的 Java/JNI 两个平台包，可以直接在 页面下载。