IRONSOFTWAREHOME
与其他组件比较

IronOCR 和 Aspose.OCR 之间的比较

Kannaopat Udonpant
Kannapat Udonpant
Updated: 2026年6月28日

Asprise OCR 首先提供Java库,并将 。网 视为次要目标——这种设计决策体现在产品的每一层,从用Java示例编写的文档到需要平台特定 DLL 的本机二进制部署模型(libaocr.dylib)在运行软件的每台机器上。 线程模型加剧了这种情况: Lite和 STANDARD 许可证在合同上被限制为单线程、单进程执行,这意味着每个调用这些层级上的 Asprise 的ASP.NET Core终结点、Windows 服务或 Azure 函数都违反了许可协议。 对于构建生产系统的.NET团队来说,这些并非理论上的问题——它们是部署障碍,迫使他们在投入生产之前要么支付昂贵的Enterprise许可费用,要么更换库。

了解 Asprise OCR

Asprise OCR 是 Asprise 公司出品的一款商业 OCR 产品。该产品最初是一个JavaOCR 引擎。后来,通过本地库封装器实现了对.NET 的支持,这些封装器将托管的 C# 代码与底层的非托管 OCR 二进制文件连接起来。 这种桥接架构是该库对.NET开发人员而言最具代表性的特征。

主要架构特征:

  • **Java优先设计:**所有主要文档、示例代码和SDK示例均以Java编写。 .NET开发人员要么在脑海中将Java代码翻译成 。网 代码,要么依赖稀少的辅助文档。 -**本地二进制依赖项:**平台特定的非托管 DLL 必须存在于部署目录或系统路径中。 正确的二进制文件必须与进程架构匹配——32 位进程需要 aocr.dll,64 位进程需要 aocr_x64.dll
  • **手动引擎生命周期:**该库公开了一种 C 风格的初始化模式(ocr.StopEngine()),继承自其Java起源。 没有 IDisposable 实现。 忘记 StopEngine() 会泄露本机内存。 -许可层级线程限制: Lite (约 299 美元)和 STANDARD(约 699 美元)层级仅允许单线程、单进程执行。 多线程需要Enterprise,而企业版需要联系销售部门。
  • **错误代码,而不是异常:**识别失败表现为返回 null 或以 "ERROR:" 开头的字符串,与 C/Java 错误代码约定一致,而非 。网 异常模式。 -**支持 20 多种 OCR 语言:**远少于为.NET生态系统构建的替代方案。

发动机生命周期问题

每次Asprise OCR调用都需要明确的引擎管理。 该模式包含四个必要步骤:静态全局设置、实例创建、使用语言字符串启动引擎以及完成后停止引擎。 跳过引擎停止操作会导致本地资源泄漏,因为垃圾回收器无法释放未托管内存:

// Asprise: four required steps before reading a single image
Ocr.SetUp();                              // Static global init
Ocr ocr = new Ocr();
try
{
    ocr.StartEngine("eng", Ocr.SPEED_FAST);   // Allocates native engine
    string text = ocr.Recognize(
        imagePath,
        Ocr.RECOGNIZE_TYPE_TEXT,
        Ocr.OUTPUT_FORMAT_PLAINTEXT);
    return text;
}
finally
{
    ocr.StopEngine();                         // Must call — no IDisposable fallback
}

这种模式在三种常见情况下会静默失败:StopEngine() 被调用前未处理的异常、跳过清理的重构代码路径、在 Lite/Standard 上的并发使用,其中许可证禁止允许并行的线程使用。 finally 块减轻了第一个问题,但许可证限制使该模式在服务器工作负载中无意义。

了解IronOCR

IronOCR是一个专为.NET从零开始构建的商业 OCR 库。 它封装了一个优化的 Tesseract 5 引擎,具有自动预处理、原生 PDF 支持以及完全遵循标准.NET约定的托管 API。

主要特点:

  • 单个 NuGet 包: dotnet add package IronOcr 安装所有内容——没有本机二进制管理,没有 tessdata 文件夹,没有平台特定配置。
  • IDisposable 资源管理: OcrInput 实现 IDisposableusing 语句自动处理清理。 -**所有许可级别均线程安全:**没有人工线程限制。 在 $999 Lite 许可证上,IronTesseract 实例可安全地并行使用。
  • **自动预处理:**内置 Binarize()EnhanceResolution() 方法消除了对外部图像处理库的需求。 -**原生 PDF 输入:**直接传递 PDF 路径 — 无需外部渲染库先将页面转换为图像。
  • **125+ 种语言:**作为单独的 NuGet 包提供(IronOcr.Languages.French 等),仅在需要时安装。
  • 可搜索的 PDF 输出: result.SaveAsSearchablePdf() 从任何 OCR 结果生成符合 PDF/A 的输出。 -**结构化数据访问:**结果显示单词级、行级和段落级文本,以及像素坐标和每个单词的置信度分数。

功能对比

特征Asprise OCRIronOCR
主要平台Java。网
NuGet部署包装器 + 原生 DLL单一套餐,无额外费用
线程(所有层级)仅限Enterprise所有级别
服务器/Web应用程序使用仅限Enterprise所有级别
原生 PDF 输入
内置预处理
OCR语言20岁以上125+
可搜索的 PDF 输出

详细功能对比

特征Asprise OCRIronOCR
架构
设计起源Java、 .NET次要.NET原生
API 风格C 风格,使用整数常量流畅的 C#
IDisposable / using 模式未实施是 (OcrInput)
错误处理返回空字符串/错误字符串.NET 例外情况
原生异常传播互操作性差距托管异常
线程和服务器使用
多线程 —Lite版禁止允许
多线程 — 标准层禁止允许
多线程 —Enterprise级/上层允许允许
ASP.NET Core Web API需要Enterprise任何级别
Azure Functions / AWS Lambda需要Enterprise任何级别
并行.每个批次需要Enterprise任何级别
输入支持
图像文件(JPG、PNG、TIFF)
原生 PDF 输入否(需要外部库)
受密码保护的PDF
字节数组/流输入有限的
多页 TIFF 文件有限的
预处理
德斯丘手动/外部内置
降噪手动/外部内置
对比度增强手动/外部内置
二值化手动/外部内置
分辨率缩放(DPI)手动/外部内置
输出
纯文本
可搜索的 PDF 输出
词坐标有限的
逐词置信度得分
hOCR导出
语言
语言数量20岁以上125+
语言安装捆绑式NuGet包
强类型语言枚举否(字符串代码)是 (OcrLanguage)
部署
需要本地二进制文件是的(平台特定的 DLL)
Tessdata 文件夹管理
多克手动二进制配置开箱即用
Linux需要 libaocr.soNuGet句柄
定价
入门价格联系Asprise以获取定价(LITE,仅限单线程)$999 (Lite,所有功能)
服务器使用入口价格Enterprise(联系销售)$999 (Lite)

原生.NET与Java桥接架构

对于.NET团队来说,根本问题不在于哪个库在纸面上功能更多,而在于哪个库在他们实际使用的部署和运行环境中能够像一流.NET公民一样运行。

Asprise 方法

Asprise 通过 P/Invoke 封送在托管的.NET代码与其非托管的 OCR 引擎之间进行通信。 asprise-vs-ironocr-examples.cs 源代码显示了底层机制:

// Asprise interop layer — bridging managed C# to native OCR engine
[DllImport("aocr.dll")]
private static extern IntPtr OCR(string imagePath, int type);

public string ExtractText(string imagePath)
{
    // P/Invoke call into unmanaged DLL
    IntPtr result = OCR(imagePath, 0);
    return Marshal.PtrToStringAnsi(result);  // Manual string marshal
}

在更高级别的 API 中,开发人员通过类包装器调用同一个桥接程序,但部署要求并没有改变:每个目标机器都需要正确的本地二进制文件,位于正确的路径中,与正确的进程架构相匹配。 一个随 aocr.dll 发行的 64 位部署而不是随 aocr_x64.dll 发行的 64 位部署会在运行时抛出 libaocr.so 中没有 LD_LIBRARY_PATH 的 Linux多克容器会抛出 DllNotFoundException。 这两个错误在构建时都无法捕获。

IronOCR方法

IronOCR以单个NuGet引用的形式安装。 该软件包通过 NuGet 的平台特定软件包选择机制在内部处理所有原生依赖项:

// Installation — one command, all platforms
// dotnet add package IronOcr

// License setup
IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY";

// Basic OCR — no native binary setup, no tessdata, no config files
var text = new IronTesseract().Read("document.jpg").Text;

using 语句在 OcrInput 上替换了手动引擎生命周期调用。 没有 StartEngine() 可调用,也没有 StopEngine() 会被遗忘。 垃圾收集器和 IDisposable 模式在异常场景中正确处理清理,而无需在每个 OCR 调用周围搭建 try/finally 脚手架。

有关详细的设置指导,请参阅IronTesseract 设置指南

螺纹模型

线程限制是 Asprise 与.NET服务器开发人员的其他替代方案之间最重要的区别。 这不是性能问题,而是许可证合规问题。

Asprise 方法

Lite和 STANDARD 许可证明确禁止多线程和多进程执行。 任何从多个线程同时调用 Asprise 的代码都违反了这些层级的许可协议。 ASP.NET Core默认使用线程池处理请求。 这使得每个调用 Asprise 的标准 Web API 控制器都违反了Lite/STANDARD 的许可协议:

// ASPRISE LITE/STANDARD — violates license in ASP.NET Core context
// Web server thread pool = multiple concurrent threads = prohibited
[ApiController]
public class OcrController : ControllerBase
{
    [HttpPost("extract")]
    public IActionResult ExtractText(IFormFile file)
    {
        // Two concurrent requests = two threads = license violation
        var ocr = new Ocr();
        ocr.StartEngine("eng", Ocr.SPEED_FAST);
        var text = ocr.Recognize(tempPath, Ocr.RECOGNIZE_TYPE_TEXT, Ocr.OUTPUT_FORMAT_PLAINTEXT);
        ocr.StopEngine();
        return Ok(text);
    }
}

Lite/STANDARD 上的批处理强制顺序执行,而不管有多少 CPU 核心可用:

// ASPRISE LITE/STANDARD — sequential only (100 docs at 2 sec each = 3+ minutes)
Ocr.SetUp();
Ocr ocr = new Ocr();
try
{
    ocr.StartEngine("eng", Ocr.SPEED_FAST);
    foreach (var path in imagePaths)  // Cannot use Parallel.ForEach — license violation
    {
        string text = ocr.Recognize(path, Ocr.RECOGNIZE_TYPE_TEXT, Ocr.OUTPUT_FORMAT_PLAINTEXT);
        results.Add(text);
    }
}
finally
{
    ocr.StopEngine();
}

ENTERPRISE取消了线程限制,但ENTERPRISE需要联系Asprise销售,未发布价格。

IronOCR方法

IronTesseract 是线程安全的,并且在任何许可证级别上都没有线程限制。 在 $999 Lite 许可证上完全支持并行批处理:

//IronOCR— parallel batch on any license tier
// 100 docs at 2 sec each, 8 cores = ~25 seconds vs 200 seconds sequential
var results = imagePaths
    .AsParallel()
    .Select(path => new IronTesseract().Read(path).Text)
    .ToList();
C#

ASP.NET Core控制器无需任何特殊配置即可工作:

//IronOCR— concurrent requests on any license tier
[ApiController]
public class OcrController : ControllerBase
{
    [HttpPost("extract")]
    public IActionResult ExtractText(IFormFile file)
    {
        // Thread-safe on Lite, Plus, Professional, Unlimited — all tiers
        var text = new IronTesseract().Read(tempPath).Text;
        return Ok(text);
    }
}
C#

有关批处理工作负载中的并行吞吐量模式,请参阅 多线程示例

图像预处理

Asprise 直接将图像传递给其原生引擎,无需预处理。 低质量扫描(例如页面倾斜、噪声伪影、对比度低)会直接降低 OCR 的准确性,因为在识别运行之前没有预处理层来纠正图像缺陷。

Asprise 方法

预处理需要外部图像库。 使用 Asprise 的开发人员会添加 ImageMagick、SkiaSharp 或 System.Drawing 等依赖项,手动运行预处理操作,将处理后的图像保存到临时文件,然后将该文件传递给 Asprise:

// Asprise preprocessing: external dependency required
// 1. Load with external library
// 2. Apply corrections (deskew, denoise, contrast) with external library
// 3. Save to temp file
// 4. Pass temp file to Asprise

var ocr = new Ocr();
ocr.StartEngine("eng", Ocr.SPEED_FAST);
// preprocessedImagePath comes from your external preprocessing pipeline
string text = ocr.Recognize(preprocessedImagePath, Ocr.RECOGNIZE_TYPE_TEXT, Ocr.OUTPUT_FORMAT_PLAINTEXT);
ocr.StopEngine();

这会增加构建依赖项,增加额外库带来的运行时开销,并且要求开发人员对图像处理有足够的了解才能实现有效的校正。

IronOCR方法

预处理内置于 OcrInput。 原本需要 50-100 行代码,并借助外部库和精心的参数调优才能实现的同一流程,现在只需 5 次方法调用即可完成:

//IronOCR— preprocessing built in, no external dependencies
using var input = new OcrInput();
input.LoadImage("low-quality-scan.jpg");
input.Deskew();               // Correct page rotation
input.DeNoise();              // Remove scanner artifacts
input.Contrast();             // Improve text/background separation
input.Binarize();             // Convert to black/white for cleaner engine input
input.EnhanceResolution(300); // Scale to optimal DPI

var result = new IronTesseract().Read(input);
Console.WriteLine($"Confidence: {result.Confidence}%");
C#

对于旋转不可预测的扫描,自动偏斜校正可以处理任意角度,而无需开发人员检测或指定旋转值。 图像质量校正指南涵盖了所有滤镜及其应用时机。

PDF处理

PDF 输入是文档处理流程中的常见需求。 Asprise 不提供原生 PDF 支持——该库处理的是图像文件。 使用 Asprise 处理 PDF 需要先使用外部库将每一页转换为图像,然后再单独处理每个图像文件。

Asprise 方法

// Asprise PDF workaround — external library required to render PDF pages
var images = ExternalPdfLibrary.RenderPages("invoice.pdf");

Ocr.SetUp();
Ocr ocr = new Ocr();
try
{
    ocr.StartEngine("eng", Ocr.SPEED_FAST);
    var allText = new System.Text.StringBuilder();
    foreach (var imagePath in images)
    {
        string pageText = ocr.Recognize(imagePath, Ocr.RECOGNIZE_TYPE_TEXT, Ocr.OUTPUT_FORMAT_PLAINTEXT);
        allText.Append(pageText);
    }
    return allText.ToString();
}
finally
{
    ocr.StopEngine();
}
// Also: clean up temp image files

这种方法添加了PDF渲染依赖(通常是iText、PDFSharp或商业渲染器),需要管理临时文件,并失去了可由原生PDF阅读器保留的PDF元数据和结构。 受密码保护的 PDF 文件需要第三个组件。

IronOCR方法

IronOCR可以直接读取 PDF 文件。 OcrInput.LoadPdf() 方法内部处理渲染,包括多页文档和受密码保护的文件:

//IronOCR— native PDF input, no external rendering library
using var input = new OcrInput();
input.LoadPdf("invoice.pdf");
var result = new IronTesseract().Read(input);
Console.WriteLine(result.Text);

// Password-protected PDFs — same API, one parameter
using var secureInput = new OcrInput();
secureInput.LoadPdf("confidential.pdf", Password: "secret");
var secureResult = new IronTesseract().Read(secureInput);

// Generate searchable PDF from a scanned document
var scanResult = new IronTesseract().Read("scanned-contract.pdf");
scanResult.SaveAsSearchablePdf("searchable-contract.pdf");
C#

PDF OCR 指南涵盖页面范围选择、处理混合 PDF 类型以及用于归档工作流程的可搜索 PDF 输出

API 映射参考

Asprise OCRIronOCR当量
Ocr.SetUp()不要求
new Ocr()new IronTesseract()
ocr.StartEngine("eng", Ocr.SPEED_FAST)无需手动初始化(引擎会在首次使用时初始化)
ocr.Recognize(path, type, format)ocr.Read(path)
Ocr.RECOGNIZE_TYPE_TEXT默认行为
Ocr.RECOGNIZE_TYPE_BARCODEocr.Configuration.ReadBarCodes = true
Ocr.RECOGNIZE_TYPE_ALLocr.Configuration.ReadBarCodes = true
Ocr.OUTPUT_FORMAT_PLAINTEXTresult.Text
Ocr.OUTPUT_FORMAT_XMLresult.Words / 结构化结果
Ocr.OUTPUT_FORMAT_PDFresult.SaveAsSearchablePdf()
Ocr.SPEED_FASTESTocr.Configuration 速度设置
Ocr.SPEED_FAST默认配置
Ocr.SPEED_SLOW更高精度的配置
ocr.StopEngine()不需要 (using 处理清理)
语言字符串 "eng+fra"ocr.Language = OcrLanguage.English; ocr.AddSecondaryLanguage(OcrLanguage.French)
手动尝试/最终清理using var input = new OcrInput()
错误字符串返回值.NET Standard例外情况

当团队考虑从 Asprise 迁移到IronOCR

生产准备障碍

线程限制对于大多数生产环境中的.NET工作负载来说都是一个棘手的障碍。 开发过程中,团队使用 Asprise Lite构建 OCR 功能——单线程测试通过,一切正常。 然后,该功能被部署到ASP.NET Core API 后面的测试环境中,并发测试请求到达,应用程序要么抛出错误,要么以技术上不合规的状态运行。 解决方案要么是升级到Enterprise(但需要支付相关费用并进行销售洽谈),要么是更换库。 在排练阶段而不是正式制作阶段达到这一阶段的团队是幸运的; 那些在发布后才发现它的人将面临更紧迫的迁移。IronOCR消除了这一类问题——$999 Lite 许可证支持并发请求处理、批处理并行、Windows 服务和云功能,没有限制。

部署复杂性税

在现代部署环境(Docker 容器、Linux 虚拟机、Kubernetes pod)中运行的团队,使用 Asprise 需要支付持续的维护费用,而使用纯NuGet包则不存在这种费用。 每个容器镜像构建都必须包含目标架构的正确本地二进制文件。 每个面向多个平台的 CI/CD 流水线都必须处理特定于平台的文件包含。 生产环境的Linux容器缺少本地库属于运行时发现问题,而不是构建时错误。 那些花费数小时调试加载到 64 位进程中的 32 位 DLL 的团队,对其中的成本有着切身的体会。IronOCR仅使用 NuGet 进行部署,彻底消除了此类部署失败。

Java文档问题

开发.NET应用程序的团队需要的是 C# 示例,而不是Java示例。 Asprise 的主要文档、API 参考和社区资源面向Java开发人员。 .NET开发人员阅读 Asprise 文档时,会将Java语法、Java 包约定和Java特有的模式转换为 C# 等效项——但有时转换并不直接,因为.NET包装器并未公开所有Java端功能。IronOCR的文档、教程和代码示例都是为 C# 开发人员编写的。 从图像中读取文本教程和完整的教程中心为每个功能提供了可运行的 C# 示例,而无需翻译开销。

PDF管道缺口

处理 PDF 格式的扫描文档、发票、合同或表格的团队,如果不向其依赖关系图中添加 PDF 渲染库,就无法使用 Asprise。 该渲染库引入了自身的许可问题、维护负担和潜在的不兼容性。 对于需要在单一技术栈中同时处理 OCR 和 PDF 的团队来说, IronOCR可以原生处理这两项功能。 从扫描输入创建可搜索的 PDF 的功能(这是归档和合规工作流程的常见要求)在 Asprise 的任何许可级别中都没有类似的功能。

语言覆盖率差距

Asprise 支持 20 多种 OCR 语言。 IronOCR支持125+种插件,每种插件都可以作为独立的NuGet包进行安装。 处理阿拉伯语、印地语、泰语或IronOCR支持但Asprise不支持的其他数十种语言文档的团队,无法通过Asprise获得多语言支持。多语言指南涵盖了语言包的安装和组合,包括跨多种文字的同步识别。

常见迁移注意事项

更换发动机生命周期代码

迁移中最大的机械变化是删除 Asprise 引擎生命周期模式,并将其替换为直接 IronTesseract 实例化。 SetUp() / StartEngine() / Recognize() / StopEngine() 序列的每次出现都变成单个 Read() 调用:

// Before: Asprise lifecycle (15 lines, manual cleanup)
Ocr.SetUp();
Ocr ocr = new Ocr();
try
{
    ocr.StartEngine("eng", Ocr.SPEED_FAST);
    string text = ocr.Recognize(
        imagePath,
        Ocr.RECOGNIZE_TYPE_TEXT,
        Ocr.OUTPUT_FORMAT_PLAINTEXT);
    return text;
}
finally
{
    ocr.StopEngine();
}

// After:IronOCR(1 line)
return new IronTesseract().Read(imagePath).Text;
C#

对于处理大量文档的性能敏感代码,重用 IronTesseract 实例,而不是每次调用都创建一个新实例——引擎初始化会带来开销,顺序使用单个实例比为每个文档创建和释放一个更有效率。

替换基于字符串的语言代码

Asprise 使用字符串参数进行语言选择("eng+fra")。IronOCR使用强类型的 OcrLanguage 枚举,带有次要语言 API。 多语言指南涵盖了可用的语言标识符以及每种语言所需的NuGet包:

// Before: Asprise string-based language
ocr.StartEngine("eng+fra", Ocr.SPEED_FAST);

// After:IronOCRstrongly-typed language enum
var ocr = new IronTesseract();
ocr.Language = OcrLanguage.English;
ocr.AddSecondaryLanguage(OcrLanguage.French);
var result = ocr.Read(imagePath);
C#

替换错误字符串检查

Asprise 在识别失败时返回 null 或带有错误前缀的字符串。 IronOCR会抛出.NET异常。 用标准的 try/catch 块替换 null 和字符串前缀检查。 这样,OCR 错误处理就与.NET异常处理模型的其他部分保持一致,并提供了对完整堆栈跟踪和异常类型层次结构的访问,而不是对已解析的错误字符串的访问。

启用并行处理

迁移后,现有的 foreach 批循环可以转换为 Parallel.ForEach 或 PLINQ,而无需担心许可。 对于以前在Lite/STANDARD 上按顺序处理的文档批次,并行处理直接提高了吞吐量。 异步 OCR 指南涵盖了 Web 应用程序上下文中的异步模式,在这些上下文中,非阻塞 OCR 比线程池饱和更可取。

其他IronOCR功能

除了本次对比中涵盖的领域之外, IronOCR还提供了一些 Asprise 所不具备的功能:

  • **OCR 期间的条码读取:**启用 ocr.Configuration.ReadBarCodes = true 以在与文本识别相同的过程中从文档中提取条码和二维码——不需要第二个库。
  • **基于区域的 OCR使用 CropRectangle 从文档的特定区域提取文本,适用于发票标题、表单字段和结构化数据区域。 -置信度评分访问每个单词和整体识别置信度值,以标记置信度低的提取结果,供人工审核。 -结构化数据提取:**按页、段落、行和单词浏览结果对象,每个对象都带有像素坐标——实现超越平面文本输出的布局感知文档解析。
  • **hOCR 导出将识别结果导出为 hOCR 格式,以便与下游文档处理工具集成。 -专用文档识别专为护照、MICR 支票、车牌和手写而构建的工作流程,超越了 Tesseract 的一般识别。 -进度跟踪:**订阅长时间运行的批处理操作期间的进度事件,以便进行 UI 反馈和监控。

.NET兼容性和未来准备情况

IronOCR 的目标平台是.NET Standard 2.0,涵盖.NET Framework 4.6.1+、. 。网 Core 2.0+ 以及.NET 5 到.NET 9 及更高版本的所有版本。 该库会根据.NET发布周期定期更新,并在 Windows x64、Windows x86、Linux x64、macOS、Docker、Azure 应用服务和 AWS Lambda 上进行测试。 Asprise 的.NET兼容性受其原生二进制模型的限制——新的平台目标(ARM64、WASM)需要 Asprise 公司提供新的原生版本,而Java优先的发布节奏意味着.NET平台更新可能会滞后。 对于目前以.NET 8 和.NET 9 为目标,并计划在 2026 年迁移到.NET 10 的团队而言,IronOCR 的托管NuGet架构提供了一条简单的兼容路径,无需考虑原生二进制文件的问题。

结论

Asprise OCR 是一个带有.NET封装的JavaOCR 库。Java的传承并非偶然——它定义了部署模型(特定于平台的本地 DLL)、API 风格(带有整数常量的 C 风格生命周期方法)、文档语言(需要翻译的Java示例)以及线程限制(根据许可合同, Lite/STANDARD 单线程)。 对于恰好有.NET项目的Java团队来说,Asprise 的跨语言定位就显得很有意义了。 对于构建生产系统的.NET团队来说,这些特性会在每个阶段都带来摩擦。

穿线限制值得特别重视。 Asprise 最经济实惠的两个级别(涵盖了大多数评估该产品的团队)禁止多线程和多进程执行。 每个 ASP.NET Core Web API、每个带有工作队列的 Windows 服务、每个处理并发触发器的 Azure 函数:这些都是标准的 。网 生产模式,它们都需要 Asprise 的 ENTERPRISE 许可。IronOCR 的 $999 Lite 许可证涵盖所有这些,没有限制。

部署复杂性是第二个实际问题。 运行多克容器、Linux 构建或跨平台 CI/CD 管道的团队必须管理带有 Asprise 的平台特定的本机二进制文件。这些失败——BadImageFormatException ——出现在目标基础设施的运行时,而不是在构建时。IronOCR 通过标准 NuGet 包管理进行部署,包选择机制在内部处理平台特定的二进制文件。 部署界面是一个单独的NuGet引用。

对于开始新的 OCR 集成的 。网 团队,起点明确:一个 dotnet add package IronOcr,一个一行的许可证密钥分配,以及 new IronTesseract().Read("document.jpg").Text 得到第一个结果。 无需引擎初始化,无需本地二进制文件加载,无需线程许可证审核。

请注意: Asprise OCR、PDFSharp、Tesseract和iText是他们各自所有者的注册商标。 本网站未与Asprise、Google、empira Software GmbH或iText Group关联、未授权或赞助。所有产品名称、徽标和品牌均为其各自所有者的财产。 比较仅供参考,反映撰写时公开可用的信息。

相关文章

Key in blue circle

立即获取免费的 30 天试用版密钥

Your trial license will be sent to your email address

无任何限制。100% 解锁。无需信用卡。

bullet_checked无需信用卡或创建账户无任何限制。100% 解锁。无需信用卡。
  • Logo Aetna
  • Logo NASA
  • Logo GE
  • Logo Porsche
  • Logo USDA
  • Logo Qatar
Join Millions of Engineers who’ve tried IronPDF
获取您的无义务咨询
填写下面的表格或通过sales@ironsoftware.com
您的资料将始终保密。
深受全球数百万工程师信赖
Iron Software 的客户徽标
立即获取您的免费30 天试用密钥
无需信用卡或创建账户