scribeocr/scribe.js 是什么？

Scribe.js 是一个面向开发者的 JavaScript OCR 库，能从图片和 PDF 中提取文本，并能生成带隐形文本层的可搜索 PDF。它无需构建步骤即可在浏览器和 Node.js 中运行，但 AGPL-3.0 许可和同源限制需要仔细评估。

scribeocr/scribe.js 可以商用吗？

可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。

scribeocr/scribe.js 还在维护吗？

在维护。仓库最近一次提交在 3 天前。

scribeocr/scribe.js 是用什么编程语言写的？

主要是 JavaScript（依据 GitHub 的语言统计）。

Scribe.js OCR 库评测：图片与 PDF 文本提取方案

Q: scribeocr/scribe.js 还在维护吗？

在维护。仓库最近一次提交在 3 天前。

秒懂

它是什么？: Scribe.js 是一个面向开发者的 JavaScript OCR 库，能从图片和 PDF 中提取文本，并能生成带隐形文本层的可搜索 PDF。它无需构建步骤即可在浏览器和 Node.js 中运行，但 AGPL-3.0 许可和同源限制需要仔细评估。
适合谁用？: Scribe.js 适合需要在浏览器或 Node.js 中直接处理图片和 PDF 文本提取的开发者，尤其是希望避免传统 OCR 服务端依赖、且能接受 AGPL-3.0 许可约束的项目。它不适合需要从 CDN 加载或跨域使用的情况，也不适合对商业闭源集成有严格要求的团队。
能商用吗？: 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
还在维护吗？: 在维护。仓库最近一次提交在 3 天前。
用什么语言写的？: 主要是 JavaScript（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年8月8日 · scribeocr/scribe.js

解决什么问题：OCR 从服务端搬到前端

Scribe.js 解决的是在 JavaScript 环境中直接完成 OCR 和文本提取的问题。传统做法是把图片或 PDF 上传到服务器，调用云端 OCR 接口，再把结果返回前端。Scribe.js 把这一过程压缩到浏览器或 Node.js 进程中，没有网络请求，也没有服务端依赖。它的目标用户是开发者，而不是终端用户。终端用户有官方 GUI 前端 Scribe OCR，但库本身只面向编程调用。它支持三种场景：从图片识别文字、从 PDF 提取已有文本或对图片型 PDF 做 OCR、以及向 PDF 写入隐形文本层使其可搜索。最后一点是它区别于简单 OCR 库的关键，因为生成可搜索 PDF 通常需要额外的 PDF 处理能力。

核心机制：openDocument 与文档对象模型

Scribe.js 的 API 围绕文档对象展开。最简入口是 scribe.extractText，接受文件路径或 URL 数组，返回识别后的文本。但 README 明确说这个函数只适合测试，不适合生产。生产用法是调用 scribe.openDocument 创建文档对象，然后调用其方法。文档对象可以加载图片、PDF 或已有的 OCR 文件。识别时调用 doc.recognize({ langs: ['eng'] })，语言参数是数组，说明支持多语言，但 README 没有列出支持的语言表。识别完成后可以调用 doc.download('pdf', 'receipt.pdf') 导出带隐形文本层的 PDF。整个流程是同步式的异步调用，最后必须调用 scribe.terminate() 释放资源，否则 Node 进程不会退出。这个设计把资源管理显式化，避免了后台线程残留，但也意味着每次用完都要记得清理。

运行方式：npm 安装与 ESM 导入的限制

安装命令是 npm i scribe.js-ocr，注意包名带后缀，与 GitHub 仓库名 scribe.js 不同。Scribe.js 使用 ESM 模块，可以在 Node.js 或浏览器中直接导入，无需构建步骤。Node 中直接 import scribe from 'scribe.js-ocr'，浏览器无打包器时需要用相对路径指向 node_modules 里的 scribe.js 文件。但有一个硬性限制：所有文件必须与导入 Scribe.js 的页面同源，不能从 CDN 加载，也没有 UMD 版本。这意味着如果你用 CDN 分发静态资源，Scribe.js 无法工作。README 提供了四个框架模板：纯 ESM 浏览器、Next.js、Webpack 5、Vue 2。这个列表本身说明不同构建系统可能需要特殊配置，不是开箱即用。

与 Tesseract.js 的差异：文档里有一篇对比文章

README 专门链接了一篇对比文档 scribe_vs_tesseract.md，说明项目方清楚自己与 Tesseract.js 的竞争关系。虽然我们没有看到那篇文章的全文，但可以从已知事实推断差异。Tesseract.js 是 Tesseract OCR 引擎的 JavaScript 移植，通常需要加载语言训练数据，而 Scribe.js 的包名带 ocr 后缀，且支持 PDF 文本层写入，说明它可能集成了 PDF 处理能力，而不只是做像素识别。另外 Scribe.js 的许可为 AGPL-3.0，而 Tesseract.js 是 Apache-2.0，这是许可层面的重大区别。对于商业项目，AGPL 要求提供源代码，这可能成为采用障碍。读者应该阅读那篇对比文档，但至少许可差异是明确的。

真正的局限：同源限制与 AGPL 许可

Scribe.js 的局限在 README 中直接写明。第一，浏览器中所有文件必须同源，不能从 CDN 导入，这排除了很多常见的静态托管场景。第二，没有 UMD 版本，意味着不支持传统的 script 标签加载方式，只支持 ESM。第三，许可为 AGPL-3.0，这是一个强 copyleft 许可，要求任何通过网络提供服务的修改版本都必须开放源代码。对于内部工具或开源项目，这可能没问题，但商业闭源产品需要谨慎。还有一个隐含的局限：extractText 函数被明确说成不适合生产，这意味着你需要学习 openDocument 的完整 API，文档中提到了 API 参考，但我们在 README 中看不到具体的错误处理机制，比如识别失败如何捕获、PDF 损坏会怎样，这些都没有说明。

维护与升级成本：活跃发布但需关注包名变化

仓库最近有频繁的版本发布，v0.12.0 在 2026 年 5 月 27 日推送，之前 v0.11.3 和 v0.11.0 都在同月发布，说明项目处于活跃开发期。版本号都在 0.x 阶段，意味着 API 可能不稳定，升级到新版本时可能需要调整代码。安装包名是 scribe.js-ocr，与仓库名不一致，搜索时容易混淆。项目要求克隆时使用 --recurse-submodules，说明依赖子模块，这增加了构建复杂度。测试命令是 npm run test，贡献者需要先跑测试。这些细节表明项目有基本的工程规范，但 0.x 版本和子模块依赖意味着维护成本不低。

谁该用，谁不该用：一个具体的判断

如果你的项目完全基于 ESM，且能接受同源部署，Scribe.js 提供了一条简单的 OCR 路径。特别是需要生成可搜索 PDF 的场景，它把识别和 PDF 写入合并为一个调用。如果你的项目依赖 CDN 或需要兼容旧浏览器，Scribe.js 直接不可用。如果对许可敏感，AGPL-3.0 可能让你转向 Tesseract.js，后者许可更宽松。在决定前，应该先运行 README 中的最小示例，确认识别质量满足你的需求，因为没有任何基准数据。还要检查你是否需要多语言支持，因为 README 只展示了 eng 语言。最后，确认你的构建系统是否在官方模板列表中，否则你可能要自己调试。

编辑结论

Scribe.js 适合需要在浏览器或 Node.js 中直接处理图片和 PDF 文本提取的开发者，尤其是希望避免传统 OCR 服务端依赖、且能接受 AGPL-3.0 许可约束的项目。它不适合需要从 CDN 加载或跨域使用的情况，也不适合对商业闭源集成有严格要求的团队。在采用前，应验证目标框架（如 Vue 2、Webpack 5）的模板是否匹配，并测试 PDF 中既有文本层的提取质量，因为文档并未说明对扫描版 PDF 的识别准确率。如果项目对许可敏感，应优先考虑 Tesseract.js 的 Apache-2.0 许可，或评估自建 OCR 服务的成本。最终，Scribe.js 的价值在于其简单的 API 和免构建的 ESM 导入，但许可和部署限制决定了它只适合特定场景。

官方来源

社区笔记