1. IronOCR
  2. 故障排除
  3. 始終使用64位架構搭配IronOCR

始終使用64位架構與IronOCR

Curtis Chau
Curtis Chau
已更新:
This article was translated from English: Does it need improvement?
Translated
View the article in English

IronOCR在背後執行記憶體密集型工作，因此32位（x86）構建會達到約2GB的記憶體上限，並且在處理大型或高容量的文件時開始失敗。 目標為64位（x64）是解決之道。

無論機器有多少RAM，32位進程的可用記憶體大約限制為2GB。 在這個限制下，OCR工作通常會表現為：

System.OutOfMemoryException

同樣上限的其他症狀包括OCR引擎執行期間的死鎖、影像預處理中的資源匱乏、崩潰或未處理的異常，以及OCR結果超時或默默失敗。

壓力來自於IronOCR對每個文件執行的操作：高解析度影像渲染、臨時光柵化、光學字元識別以及使用機器學習模型（由SearchablePDF輸出使用）的深層文字提取。 這些每一個都可能需要數百MB的文件記憶體，多頁面PDF、多頁面TIFF和300+DPI圖片會進一步推高這個需求。

請注意IronOCR也會調用本地程式庫進行OCR、影像渲染和PDF光柵化。 這些會配置非管理記憶體，.NET垃圾收集器無法察覺，這在32位進程中增加了更多壓力。

解決方案

選項1：在Visual Studio中設定平台目標

通過構建設置將專案切換到x64：

  1. 右鍵單擊您的專案並打開屬性。
  2. 打開構建標籤。
  3. 將平台目標設為x64。
  4. 保持偏好32位未勾選。

選項2：從CLI或.csproj中設置目標

針對64位運行時進行發布，以在構建時強制執行架構：

dotnet publish -c Release -r win-x64
dotnet publish -c Release -r win-x64
SHELL

或者直接在您的.csproj中設定目標：

<PropertyGroup>
  <PlatformTarget>x64</PlatformTarget>
  <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup>
  <PlatformTarget>x64</PlatformTarget>
  <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
XML

當專案為<Prefer32Bit>false</Prefer32Bit>行格外重要：開啟該設定後，應用程式仍會作為32位進程啟動，並繼承相同上限。

警告避免使用"AnyCPU"，啟用了"偏好32位"的情況。 這會在即使是64位機器上悄悄重新引入2GB的限制。

何時懷疑為架構問題

如果您發現OCR工作無法前進或意外崩潰、偶發性的記憶體不足異常，或在高容量文件上的性能下降，首先檢查架構。 如果您是在x86上運行，請先切換到x64，再進行其他調查。

保持一些生產習慣：

  • 生產以x64為目標：這是支持重度OCR工作負荷的唯一配置。
  • 在x64上開發：在x64上進行測試反映真實世界的記憶體行為，並能提前揭露問題。
  • 構建64位Docker映像：確保基礎映像為linux/amd64。

請注意，同時進行的OCR工作會快速增加記憶體，即使是小型文件，多執行緒或異步操作也會迅速增加。

如果您無法更改架構

當x64不是選項時，將大型文件分解為小塊並以較低的解析度處理。 預期性能和準確性會有所折衷。 32位專案的穩定支持目前正在調查中。

Curtis Chau
Curtis Chau
  立即與工程團隊聊天
技術作家

Curtis Chau擁有Carleton大學的電腦科學學士學位，專精於前端開發，擁有Node.js、TypeScript、JavaScript和React的專業知識。Curtis熱衷於建立直觀且美觀的使用者介面，喜愛使用現代框架並建立結構良好、視覺吸引力的手冊。

除了開發，Curtis對物聯網（IoT）有濃厚的興趣，探索創新的方法來整合硬體和軟體。在空閒時間，他喜歡玩遊戲和建立Discord機器人，結合他對技術的熱愛與創造力。

準備開始了嗎？
Nuget 下載 6,136,090 | 版本： 2026.7 剛剛發布
Still Scrolling Icon

還在滾動？

想要快速證明？ PM > Install-Package IronOcr
執行範例 觀看您的圖像轉變為可搜尋文字。