使用Microsoft Graph API(Objective-C)上传PDF至OneNote遇413错误求助

我之前也碰到过类似的问题，结合微软官方文档和实际调试的经验，给你几个可行的解决思路：

1. 使用官方推荐的**上传会话（Upload Session）**处理大文件 #

这是Graph针对OneNote大附件上传的标准解决方案，能完美规避单请求大小限制的问题，具体步骤如下：

步骤1：创建上传会话 #

先发送POST请求到会话创建端点，获取专属的上传URL：

POST https://graph.microsoft.com/v1.0/me/onenote/pages/createUploadSession

请求体JSON（替换成你的section ID和页面标题）：

{
  "sectionId": "XXX", // 你原本使用的section ID
  "pageInfo": {
    "title": "带大PDF附件的新页面"
  }
}

响应会返回uploadUrl和会话过期时间，后续所有分块上传都使用这个URL。

步骤2：分块上传PDF #

把你的PDF文件分割成单块不超过25MB的二进制数据块（建议每块控制在5MB-25MB之间，平衡传输效率和请求次数），然后对每个块发送PUT请求到uploadUrl：

• 必须设置Content-Range请求头，格式为 bytes start-end/totalSize，比如第一个5MB块（总大小40MB）的请求头就是：Content-Range: bytes 0-5242879/41943040
• 请求body直接放当前块的二进制数据，不要做base64编码（会额外增加33%的体积，容易触发隐藏限制）

步骤3：完成上传 #

当最后一块上传成功后，Graph会自动完成会话并创建包含PDF附件的OneNote页面。如果最后一块上传后没有自动触发页面创建，也可以发送一个空的PUT请求到uploadUrl，并设置Content-Range: bytes */totalSize来手动完成会话。

2. 检查并调整客户端请求的编码/格式问题 #

如果暂时不想切换到上传会话，也可以排查当前请求的潜在问题：

• 避免base64编码附件：如果你的代码把PDF转成base64后放到multipart请求里，4MB的PDF会变成约5.3MB，可能触发某些中间层的隐性限制，直接用二进制形式作为multipart的独立部分上传即可。
• 拆分multipart部分：确保PDF所在的multipart块（含头部）大小不超过25MB，不要把页面HTML内容和PDF合并到同一个部分里。

3. 排查客户端网络库的默认限制 #

虽然你收到的是服务器返回的413错误，但还是可以检查下Objective-C网络库的配置：

• 如果用AFNetworking，确认AFHTTPRequestSerializer的maximumContentLength没有被手动设置过小（默认是64MB，一般没问题，但如果改过就需要调整）。
• 如果用原生NSURLSession，确保没有自定义的请求大小限制逻辑。

这个问题的核心是直接POST大文件时，即使总大小没到70MB，也可能因为单请求的传输方式或中间层限制被拦截，而上传会话是官方专门为大文件设计的方案，兼容性和稳定性都更有保障。

内容的提问来源于stack exchange，提问作者Imanou Petit