一份 PDF 明明看得见中文字，输入页面上的词却搜不到，鼠标也只能选中整块页面：它可能保存的是扫描图片，而不是可以检索的文字。不过， 搜不到一次，不能直接证明文件没有文字层 ；即使能够复制，复制出来的字也不一定正确。 本文由 FreeToolBox 编辑部依据 NAPS2 官方 OCR 说明 整理，帮助你先判断问题，再决定是否需要识别文字。OCR 就是把图片中的字识别成文字。本文是来源型指南，没有进行 NAPS2 实际识别测试，不提供识别准确率、处理速度或格式兼容性的实测结论。 先用一页、三个动作排查 找一小段确定出现在页面上的文字。 先搜其中两三个清楚的字，而不是整句带标点、空格或换行的文字。若整句找不到但短词能找到，应继续检查复制结果，不要立刻重做整份文件。 尝试选取这段文字并复制到本地纯文本编辑器。 查看是否得到可读的文字，以及字序是否正确；别只看 PDF 画面。不要把私人文件内容贴到公开网页来测试。 换一页再查。 同一份 PDF 可能混有不同来源的页面。一页能搜到，不等于每一页都能；应覆盖正文页、扫描页以及你真正需要检索的内容。 这些动作是排查方法，不是对你的文件作出的诊断。只处理自有或已获授权的文件；如果阅读器提示禁止复制，或者文件需要密码，先向文件提供者确认权限，不要把权限限制误当成识别失败，也不要尝试绕过。 把观察结果分成三种情况 能够选字、复制内容正确： 至少这一段已有可用文字，未必需要 OCR。再检查搜索词是否包含多余空格、标点或换行，并确认阅读器的搜索范围。 能选字，但复制结果乱码或错字： 说明“有文字”不等于“文字可用”。如果是已有识别文字错误，不能假设再导入一次就会自动替换；保留原件，并先验证工具如何处理已有文字页。 只能选整页图片，找不到任何文字： 扫描图片是可能原因，但这还不是完整证明。在确认文件权限和阅读器行为后，OCR 才是值得尝试的方向。 一个具体例子：能搜到正文，还要核对编号 假设你自建一页样本，内容为“FreeToolBox 样例记录：编号 AB00123，日期 2026-09-30”。先搜索“样例”，再复制整行，逐字符对照 AB00123 和日期。 这只是排查用的假设样例，不是本次 OCR 的实测输出。 检索成功只能说明这一搜索词能匹配；它不能替你证...

把照片拖进文档，再拉小到页面的一角，保存后的文件却仍然很大：问题可能不在图片“看起来有多大”，而在文档里保留了多少原始图像数据。继续拖小边框，不一定能让附件更容易发送。 本文由 FreeToolBox 编辑部依据 LibreOffice Writer 官方资料整理，回答一个具体问题： 什么时候只调整显示尺寸，什么时候才需要压缩文档内的图片？ 下面的像素计算是说明性例子，不是软件实测；本文不提供实际压缩率、画质或跨软件兼容性结论。 先分清三件事：页面尺寸、像素和文件字节 Writer Guide 24.2 第 11 章 说明：插入大图后，即使把它缩小以适应页面布局，完整原图仍会保存在文档里，以保留其内容。因此，页面里只有一张“小照片”，并不代表文档已经保存了一张“小文件”。这个说明针对 Writer，不能直接当作所有编辑器的结论。 页面显示尺寸： 决定图片在文档中占多大位置，首先影响排版。 图像像素： 例如 4000 × 3000，表示宽、高各有多少像素；减少像素会减少可保留的细节。 文件字节： 决定附件是否超过大小限制；还受编码方式、图像内容和文档中其他资源影响。 一个计算：像素少了 91%，不等于附件小了 91% 假设一张 4000 × 3000 像素的照片，交付要求只需要宽 1200 像素，并且保持原来的 4:3 比例，那么目标高度就是 1200 × 3000 ÷ 4000 = 900 像素。 原图像素总数：4000 × 3000 = 12,000,000。 目标像素总数：1200 × 900 = 1,080,000。 像素减少比例：1 − 1,080,000 ÷ 12,000,000 = 91%。 这里只能得出“像素数量减少了 91%”。不能据此说 10 MB 的文档会变成 0.9 MB，也不能说图片一定仍然清晰。 1200 像素是这个假设例子的交付要求，不是适合所有文件的推荐值。 含小字的截图、需要放大的图表、用于印刷的照片，可能需要保留更多细节。 在 Writer 中，按这条顺序判断和处理 先保存副本，并记下原文件大小。 保留原文档和原始照片；后续只在副本中尝试。若只是版面太拥挤，而附件大小没有问题，调整显示尺寸就够了，不必为了“优化”额外损失细节。 确认真正的交...

CSV 打开后出现中文乱码，或客户编号 00123 变成 123 ，看起来像同一个“导入失败”，其实常常是两个不同层次的问题：前者要先检查文件使用的字符集，后者要检查导入列的类型。把所有问题都改成 UTF-8，或者只把整份文件当成文字，未必能解决问题。 本文由 FreeToolBox 编辑部依据 LibreOffice Calc 的官方 Text Import 帮助 整理，提供一个不依赖特定文件的判断顺序。示例中的编号和电话号码都是虚构内容；FreeToolBox 没有在你的文件上进行实测，也没有把这个来源型说明写成 Excel 或其他软件的兼容承诺。 先判断：乱码还是数字被重新解释 中文变成奇怪符号： 先怀疑读取文件时选择的 Character Set（字符集）与文件实际编码不一致。 每行被切成错误的列： 检查分隔符。逗号、分号、Tab 或自定义分隔符必须与文件的实际结构一致。 中文正常，但 00123 变成 123： 这更像是列类型或数字自动识别问题，不是中文字符集问题。 日期、金额或科学计数法被改写： 还要检查 Language、Detect special numbers 和 Detect scientific notation 等导入选项。 这几个症状可以同时出现。例如，字符集选错会让中文乱码；即使中文已经正常，编号仍可能因为列被判断为数字而丢掉前导零。排查时应把“文字怎么解码”和“字段怎么转换”分开记录。 官方导入对话框里，应该分别看哪些设置 1. Character Set 只负责读取字符 LibreOffice 的官方说明把 Character Set 定义为导入文件时使用的字符集。它是读取文字的入口，不等于“所有数据都按文字保存”。当中文乱码时，先找出文件实际使用的编码，再选择相符的字符集；不要因为看到乱码就无条件把每个文件改成 UTF-8。 2. Separator Options 决定列边界 在预览中确认每行被切成预期的列数。逗号分隔的文件要选 Comma，Tab 分隔的文件要选 Tab，使用分号或其他分隔符时要对应选择。若分隔符本身出现在字段内容中，还要留意 String delimiter 和引用规则，否则“看起来像多出一列”可能是字段边界没有按原结构解析。 3. Co...

WhatsApp 二维码放进宣传图后，验收的对象应该是哪一个文件？FreeToolBox 这次把生成器下载的 QR 放进自制卡片，导出整张 PNG 后再独立解码。原始 QR 和卡片都能读出消息 A；但在生成器改成消息 B 后，旧卡片仍然读出 A。 所以需要分开问两件事：这张最终图片能否解码，以及解出的号码和消息是不是这次要交付的版本。只检查生成器里的新 QR，会漏掉已经保存到旧卡片里的内容。 这次检查的范围与安全号码 输入号码为 12025550100 ，第一条预填消息为 FreeToolBox 演示 A 。根据 NANPA 的 555 号码说明 ，555-0100 至 555-0199 为保留的虚构非工作号码范围。本例只用于文件演示，不代表该号码有 WhatsApp 账户，也不是供读者联系的客服号。 卡片为 FreeToolBox 自制人工样本，没有客户资料。本次只生成、保存和离线解码文件，未打开目标链接、调用 WhatsApp、拨号或发送消息；也没有手机相机、纸张打印或聊天平台重压缩测试。 从生成器到真正的交付 PNG 在 FreeToolBox WhatsApp 链接与二维码生成器 填入国家代码 1、号码 2025550100 和消息 A，生成并保存 QR PNG。 在 Photopea 打开自制卡片，将 QR 置入为智能对象并定位，再导出整张 PNG。本次实际使用官方文档支持的数据 URI 导入及内置 File → Script 置入、移动对象；没有验证常规鼠标“打开并置入”路线。 用独立的 ZXing-C++ 3.1.1 文件解码器分别读取原始 QR 和完整卡片。检查的是导出的 PNG，不是编辑器预览或生成器页面上的链接文字。 消息 A 的实际生成界面；截图底部没有包含整个 QR，文件解码使用下载的完整图片。 实际导出的完整 PNG，原始尺寸 1200 × 800，49,824 字节；独立解码读取的是这整张卡片。 原始 QR A 为 270 × 270 像素、4,509 字节。它与最终整卡解出的完整内容一致： https://wa.me/12025550100?text=FreeToolBox%20%E6%BC%94%E7%A4%BA%20A 将网址中的 text 参数进行百分号...

三张图片变成一个 PDF，文件就会自动变小吗？FreeToolBox 这次保存并重新检查的三页 PDF 为 6,459,134 字节，约 6.46 MB，反而比三张原始 JPG 的合计多了 1,752 字节。原因在这份文件里很明确：嵌入的三份 JPEG 数据与输入逐字节相同，转换并没有重新压缩它们。 本文用人工制作的 FreeToolBox 样本说明如何判断结果；它们不是实拍照片或真实扫描件，也没有个人资料。重点是分开验收容量、页数与小字，不能拿单张图片的压缩比例代替最终 PDF 的检查。 先看这次完成了什么 将三张 2480 × 3508 像素的 JPG，按 PAGE 1、PAGE 2、PAGE 3 顺序生成并下载三页 PDF。 只读检查 PDF 结构，再将全部页面以 130 dpi 渲染，在桌面图像查看器核对十个预定字段。 另用第一页原图制作两档 JPG 样本，记录文件大小与可读性；没有把这些样本重新组成压缩版 PDF。 本次自行设定的容量目标是 2,000,000 字节，便于演示验收。它不是任何报名、政务或邮件系统的实际限制。文中 MB 按 1,000,000 字节换算，精确结果以字节数为准。 原图转 PDF：页数正确，容量仍不达标 在 FreeToolBox JPG／PNG 转 PDF 选择三张原图，检查列表顺序后建立 PDF，并保存实际下载文件。不能只凭页面出现“PDF 已建立”就认定附件合格。 实际工具界面的三张图片顺序与建立完成提示；文件内容还需下载后核对。 检查对象 实测结果 这代表什么 三张原始 JPG 合计 6,457,382 字节 每张均为 2480 × 3508 像素 下载的三页 PDF 6,459,134 字节 超过本次 2,000,000 字节演示目标 嵌入图片与封装差额 JPEG 数据不变；增加 1,752 字节 本次是图片封装，不是图片再压缩 页面与字段 三页纵向 A4，顺序正确；十项字段均读出 此桌面检查条件下，完整性和读字检查通过 三页尺寸均为约 595.28 × 841.89 点，未见空白页或明显裁切。十项字段包括第一页的 MAPLE24、A1047、B2086、C3095，以及第二页带前导零的 0128。PDF...