我正在使用云端硬盘 API 列出集合中标题中不包含特定字符串的文件。
我的查询如下所示： files().list(q="'xxxxx' in parents and not title contains 'toto'")
在我的驱动器集合中，我有 100 个文件，除了 10 个文件外，所有文件都在其标题中包含字符串"toto"。
我正在使用分页来检索结果 20 x 20，所以我预计只得到一个页面，其中包含与我的请求对应的 10 个文件。令人惊讶的是，API 返回 5 页，前 4 页没有结果，但带有 nextToken 页面，符合我请求的文件仅随第五页一起提供。
我仍在尝试一些用例，但似乎与"not"运算符有关。就像请求是在没有它的情况下发出的，因此返回 5 页，但结果与从响应中删除的请求不对应。这对我来说非常令人不安，因为我在这里寻找最佳性能，显然必须向 Drive 发出 5 个请求而不是一个请求对我来说并不好。我还注意到结果并不总是出现在最后一页。我用另一个集合进行了测试，结果显示在第二页，但之后我仍然得到 3 个空白页。
我在这里错过了什么吗？这种行为"正常"吗？我的意思是想象一下，如果我的收藏中有 1000 个文档，那么必须提出 50 个请求才能找到几个文档并不是我所期望的。
我在files.list API中也有类似的问题。我尝试接收根文件夹下的所有三个文件夹。我只在第 342 页上收到结果。经过几个小时的研究，我发现这种奇怪的行为有一些规律性。
据我了解，Drive API 的工作方式如下：
- 检测与查询最匹配的索引等内容
- 使用步骤 1 中的索引选择前 20 条记录
- 应用筛选器：删除与查询不匹配的记录
- 其余部分使用下一页令牌返回给您（可能是空的）。
nextPageToken看起来只是在决定索引中下一页上的第一条记录OFFSET，也许它包含一些有关查询或索引的信息。
在 base64 解码此令牌后，我在解码令牌的第 121 个位置找到了下一个结果的适当记录号。以前我使用 maxResults=1 构建代币索引。
这太疯狂了，但我对可观察的行为没有其他解释。
它对服务器非常有用，因为服务器对搜索的工作非常小。从另一方面来看，此算法必须生成大量对页面整个列表的请求。但是每秒请求数的限制可以解决此问题。
只有你能做的是调页并跳过空结果。不要忘记请求数量的限制。
不要试图在你这边发现错误。这就是Google Drive API的工作方式。
contains运算符目前正在充当前缀匹配器。title contains 'toto'将匹配"totolong"和"toto"，但不会匹配"blahtoto"。