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...