做图片转文字时，很多人第一反应都是：

但真正把 OCR 接进业务系统以后，会发现大量问题其实发生在识别之前。

用户上传了一张手机截图，原图只有 900KB，转成 Base64 后却超过限制；

一部分图片来自用户本地上传，另一部分已经存在对象存储里，到底应该统一转 Base64，还是直接传 URL；

接口明明调用成功了，返回结果却只是一个文字数组，后面的搜索、存储和整理该怎么接；

还有一种很常见的情况：图片过大、格式不支持、查询失败，最后前端全部显示成一句“识别失败”。

这些问题如果不提前设计，OCR 本身能正常工作，整个业务链路依然会很难维护。

所以做通用文字识别时，我更建议先把问题拆成三层：

图片怎么进来 → OCR 返回什么 → 业务系统怎么继续处理。

一、先别急着识别，先判断图片从哪里来

一种是用户刚刚上传的本地图片。

这种图片本身还没有可访问的网络地址，比较自然的处理方式就是读取文件内容，再转换成 Base64。

另一种情况是，图片已经存在服务器、对象存储或其他可访问位置，并且已经有图片 URL。

这种情况下，再把图片下载回来、转成 Base64、重新提交一次，反而增加了一层没必要的数据转换。

所以业务里可以先做一个很简单的判断：

本地临时图片
→ Base64

已经有可访问地址
→ img_url

两种方式解决的是不同的数据来源，不是“哪一种识别效果更好”。

以通用文字识别能力为例，当前支持 

 两种图片输入方式，二者选择其一即可。

这意味着业务代码最好不要把所有图片强行处理成同一种形式，而应该根据当前图片所处的位置决定下一步。

二、Base64 最大的坑，不是编码，而是体积变化

很多 OCR 接入问题都出在这里。

因为 Base64 不是原始二进制图片。

图片经过 Base64 编码以后，数据体积会增加。

if (file.size < 1024 * 1024) {
  // 可以提交
}

并不能保证最终 Base64 一定满足限制。

选择图片
↓
检查格式
↓
读取文件
↓
转换 Base64
↓
计算 Base64 数据大小
↓
满足限制后再进入识别

如果前端使用 JavaScript，可以把“大小校验”单独做成一个步骤，而不是等 OCR 返回错误以后再告诉用户图片太大。

能够在请求发出去之前就拦截明显不符合条件的图片。

三、手机原图为什么特别容易出问题？

手机拍照现在动辄几 MB，甚至十几 MB。

即使图片里只有几行文字，原始文件也可能远远超过 OCR 实际需要的尺寸。

这时候更合理的处理方式不是：

而是把图片预处理放到识别之前。

用户上传
↓
检查文件类型
↓
判断体积
↓
必要时压缩
↓
转换 Base64
↓
再次检查编码后大小
↓
进入 OCR

如果为了满足大小要求，把原本清晰的小字压缩到已经模糊，即使请求能够正常提交，文字识别本身也可能受到影响。

所以图片预处理真正要追求的是：

在满足请求大小的前提下，尽量保留文字可读性。

四、JPG、JPEG、PNG 的检查最好放在客户端前面

如果业务允许用户随意上传图片，最好在文件选择阶段就判断格式。

const allowedTypes = [
  "image/jpeg",
  "image/png"
];

if (!allowedTypes.includes(file.type)) {
  throw new Error("当前图片格式不支持");
}

这里的目的并不是代替服务端校验。

而是让错误尽量发生在离用户最近的位置。

否则用户上传一个不支持的图片以后，系统还要完成：

上传
→ 请求后端
→ 调 OCR
→ 返回格式错误
→ 再回到前端

整个链路更长，错误信息也更难定位。

前端做基础格式和大小检查，服务端继续做最终校验。

五、OCR 返回的是文字列表，不等于“完整文章”

通用 OCR 的返回结果还有一个特别容易被误解的地方。

它并不是一个已经帮你整理好的完整文档。

所以业务系统下一步要做什么，需要根据自己的场景决定。

如果只是全文搜索，可以把数组组合成文本：

如果要逐行展示，可以直接保留数组：

如果后面还要进入分类、关键词提取或者人工校对，也可以继续保留：

原始 OCR 行列表
+
整理后的完整文本

这样以后发现识别结果有问题时，还能回头检查原始结构。

六、不要自行假设有“文字坐标”

还有一个文档接入中很典型的问题。

产品说明中提到文字位置和内容识别，但当前提供的 JSON 示例和返回字段只明确展示了：

所以程序不能因为“听起来 OCR 应该能返回坐标”，就自行按照坐标型 OCR 去设计数据结构。

那就必须先确认实际返回是否存在位置数据。

OCR 接入最容易踩坑的，不是识别率，而是图片怎么传

图片转文字看起来只是一次 OCR 调用，但真正接入业务系统后，问题往往出在图片输入链路：Base64 和图片 URL 该怎么选？Base64 编码后的 1M 限制怎么判断？图片过大时应该在哪一层处理？识别结果只有文字列表时又该怎么设计后续数据结构？本文从实际工程接入出发，拆解通用 OCR 在图片输入、大小校验、结果建模和异常处理中的几个常见问题。

编程语言

做图片转文字时，OCR识别的稳定性取决于图片输入预处理与返回结果的后处理。需优先判断图片来源（本地Base64或已有URL）、严格检查编码后体积（不超过1M）与格式（JPG/JPEG/PNG），并区分错误码（图片过大、格式不支持等）。返回结果为文字数组，需自行拼接为全文，并根据业务需求决定是否保留坐标数据。合理分层设计能显著提升OCR接入效率。

内容识别

对象存储

文字识别

数据转换

数据结构

数据处理

JavaScript

服务器

JSON

文字识别限时特惠，新用户0.7折起


generalocr

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

做图片转文字时，OCR识别的稳定性取决于图片输入预处理与返回结果的后处理。需优先判断图片来源（本地Base64或已有URL）、严格检查编码后体积（不超过1M）与格式（JPG/JPEG/PNG），并区分错误码（图片过大、格式不支持等）。返回结果为文字数组，需自行拼接为全文，并根据业务需求决定是否保留坐标数据。合理分层设计...

OCR 接入最容易踩坑的，不是识别率，而是图片怎么传

OCR 接入最容易踩坑的，不是识别率，而是图片怎么传

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐