文件太大、格式不支持？上传失败的逐项排查方法
从实际字节数、文件真实格式、图片像素、PDF 页数与文件名这几个线索入手，判断上传失败时该用哪个工具处理。
报错只有短短一句"文件太大"。可你的文件是 200KB，你自己看过。
网站说的和你电脑显示的，中间那道缝就是排查真正发生的地方。重新压缩之前，先拿到两样东西：完整准确的报错，和它对应的那条具体规定。然后把两者对上。
这篇文章按你实际会看到的报错文字组织。找到你那一条，先弄清它到底什么意思，再动手。
"文件太大"——以及 KB 和 KiB 的坑
"我的文件明明没超"这类投诉，最常见的原因就是两个软件用同样的字母表示不同的数字。
十进制里 1 KB = 1,000 字节；二进制里 1 KiB = 1,024 字节。按二进制口径写的软件，界面上照样标成"KB"。所以照片编辑器显示"195 KB"的那张图，实际可能是 195 KiB，也就是 199,680 字节——比那个严格按 200,000 字节卡的网站允许的多，尽管它看起来比表单上的数字小。
具体数字：
| 标注 | 按哪种口径解释 | 实际字节 |
|---|---|---|
| 200 KB（十进制） | 200 × 1,000 | 200,000 |
| 200 KiB（二进制） | 200 × 1,024 | 204,800 |
| 1 MB（十进制） | 1 × 1,000,000 | 1,000,000 |
| 1 MiB（二进制） | 1 × 1,024 × 1,024 | 1,048,576 |
如果网站写着 200 KB，却拒了你那张软件显示 199 KB 的图，那它多半是在严格按字节数算，而你的文件超过了 200,000。AttachReady 的 200KB 预设就是 200,000 bytes——刻意取两种读法里更严的那个，这样按哪种解释都能过。
先查什么： 实际字节数，用会给出字节数的工具看，别看四舍五入之后的千字节。材料预检报告的是整数字节，不会凭文件名猜。
怎么修： 压到一个留有余量的目标，而不是贴着上限。大小单位混乱也会反向坑人——瞄着 200,000 字节可以满足那个其实要求 204,800 的网站；但瞄着 204,800 就一定过不了那个要求 200,000 的。另外注意，文件管理器里显示的"占用空间"不是文件大小，那是它在磁盘上占的块。
"格式不支持"——扩展名骗人的时候
扩展名只是文件名结尾的几个字母，没有任何机制保证它和里面的字节一致。
一个叫 photo.jpg 的文件，内容可能是 HEIC 数据——把 iPhone 照片改个后缀去骗表单，是经常发生的事。网站读的是真实字节，认出 HEIC，照样退回。改名什么都没解决。
还有更隐蔽的一种。聊天软件——微信、WhatsApp、Telegram 之类——在传输时经常重新编码图片。你上传时那张 JPEG 是 3MB，朋友收到并转发出来的那张，可能是画质更低的 JPEG 或 WebP，分辨率变了，文件名也变了。如果你手上是别人发来的文件，那你可能根本不是在跟原件打交道。
先查什么： 真实文件类型。图片属性检查读取解码后的文件，报告格式、尺寸和元数据，而不是相信文件名。
怎么修： 老老实实转换。图片格式转换会生成一份符合网站要求格式的新文件，扩展名与新字节一致。改名不是转换，它只改变了文件的标签。
还有一个格式边界值得知道：把带透明通道的 PNG 或 WebP 转成 JPEG 会压掉透明，因为 JPEG 没有 alpha 通道，透明区域会变成一块纯色背景。如果透明本身承载信息，就保留支持透明的格式。
"图片尺寸不符"——大小和形状是两个问题
像素尺寸和文件体积是两回事。把图片在字节上变小，完全不会改变它的宽和高。真正的压缩通常反过来：先降尺寸或丢细节，字节数才跟着降。
写明尺寸要求的网站要的是准确值：600 × 800 像素，或者 3:4 这样的长宽比。它检查的是解码后的图像，不是文件大小。
先查什么： 真实的宽、高和长宽比，以及是否对宽和高分别有上限——有些表单是分开卡的。
怎么修： 用图片缩放调到规定尺寸。不要为了凑长宽比去拉伸图片，人脸和文字会变形，审核的人看得出来。形状不对就先用裁剪裁成正确比例，再缩放。也别把 DPI 掺进来——像素和 DPI是两个属性，改一改 DPI 元数据字段并不会增加像素。
"页数超限"
页数限制管的是你提交的那份文档，不是你每一个来源文件。这一点在合并的时候最容易踩。
表单允许 100 页，你把一份 60 页的文档和另一份 60 页的合并，结果是 120 页。每个输入都合格，产物不合格。
先查什么： 成品文件的页数，不是输入的页数。
怎么修： 如果接收方确实需要全部内容，没有什么技术技巧可用——你要么换个组织方式，要么直接问清楚对方到底要什么。如果它并不需要每一页，就用 PDF 选页留下有用的、去掉其余的。这是内容层面的决定，要有意识地做，别顺手从后面砍掉几页了事。
合并出来的文件为什么比预想的大
顺带一提：合并不做压缩，它是首尾相接。两份 8MB 的文档合并后大约 16MB。如果真正卡住你的是体积上限，合并只会让它更糟，你得压缩成品，或者用更小的部件重做一遍。延伸阅读：把图片合成 PDF。
"文件似乎已损坏""无法读取""已加密"
这一条要分开回答，因为这两种情况的修法完全不同。
加密或带密码的 PDF，这些工具打不开。 如果一份 PDF 打开时要你输密码，或者它的元数据标着已加密，就当它不在处理范围内。AttachReady 拒绝加密 PDF，也没有"解除密码保护"这个开关。唯一的出路是拿到一份未加密的副本——从生成它的应用里导出，或者找发给你的人要。你从银行下载、用密码打开过的对账单，很可能文件本身就是锁着的，只是阅读器替你记住了密码。
一个实用细节：很多阅读器只问一次密码，之后就一直记着，所以一份双击就能打开的文档，磁盘上仍然是加密的。想确认，就打开它的属性，或者用 PDF 检查跑一遍，它会报告文档的结构性事实。
真正损坏的文件同样没法在这里修。 没有 PDF 修复功能。一份文件在两个不同阅读器里都打不开，那它多半就是坏了。回到源头：重新下载、重新导出，或者再要一份。
"似乎已损坏"有时是误报。 有些校验器会拒绝含有它不支持的 PDF 特性——内嵌附件、JavaScript、某些外部动作。这些文档本身完全能读，但它们带有主动内容，AttachReady 一样会拒绝。从源应用里导出普通 PDF 通常就能解决。
有一项不在这个清单上：数字签名。带签名的 PDF 能正常打开、正常处理。但压缩、合并和选页都会重写文件，而重写会让签名失效。把签名原件原样留着，在副本上操作。
该查的都查了，还是传不上去
有时候文件本身没问题，上传照样失败。按顺序过一遍：
- 对方网站的会话。 登录过期或表单超时，表现得就像一个普通的"上传失败"，这种情况多得超出预期。先刷新、重新登录、再试一次，改文件放到后面。
- 浏览器。 有些网站只在很窄的浏览器范围内做过验证。用它推荐的浏览器，先禁用扩展再试。
- 文件名。 过长的名字、带音标的字符、空格，以及
#、&这类符号，会让部分上传处理程序出错。按网站公布的规则改成简单名字，比如身份证扫描.jpg换成id-scan.jpg。 - 网络。 上传中途断流看起来也像被拒绝。看它是立刻失败还是等了一会儿才失败：立刻失败通常是校验，延迟失败往往是传输。
- 要求变了。 网站会更新限制。你上个月抄下来的数字，今天未必还是那个。
不该做的事，是反复重新压缩。每压一遍都会丢细节；如果体积本来就不是问题，你只是在白白损耗自己的材料。
AttachReady 报错时怎么求助
如果失败来自 AttachReady 而不是接收网站，错误码与排查那页覆盖了不支持的格式、未达标的体积目标、文件过期、额度报错和 API 鉴权失败。
联系 support@attachready.com 时，请附上工具地址、大概时间，以及错误码或 requestId。不要发送 API Key、密码或证件原文。一份能复现问题、但不含个人信息的示例，比你的真实材料更有用，对你也更安全。
最后记住这条边界：这些工具核验的是技术要求。当文件通过了所有可测量的检查、对方仍然拒收时，剩下的原因在他们那边——一条政策、一个表单字段，或者一条没有公开的规则。那是去问他们的事，不是再压一遍的事。