【问题标题】:Upload to google drive using cURL and set name and location使用 cURL 上传到谷歌驱动器并设置名称和位置
【发布时间】:2017-08-26 00:22:53
【问题描述】:

我正在尝试使用 cURL 将文件上传到 Google 云端硬盘。文件被上传,但仅在根目录中,并且始终命名为“Untitled”。

我的基本脚本如下所示:

curl 
    --silent 
    --request POST 
    --data-binary "@c:\temp\myfile.jpg"         
    -H "Authorization: Bearer abcdefg" 
    -H "Content-Type: image/jpeg
    "https://www.googleapis.com/upload/drive/v2/files?uploadType=media" 

使用这些链接作为参考:

Upload file to Drive and set file name

https://gist.github.com/deanet/3427090

https://developers.google.com/drive/web/manage-uploads

我注意到这可能是必需的,这是在 Google 的文档中定义的(参见链接)

-H "Slug: myfile3.jpg" 

但这不管我有没有放进去都没有效果。

使用 cURL 帮助,我注意到这可能会有所帮助:

 -OL MyFolder\myfile2.jpeg

...但这也没有效果。

我还注意到字符串 {title:file title} 可能是必需的,但我不知道如何使用 cURL 将其嵌入。基于上面的链接,我想我可以将它附加在一个标题的末尾,就在正文之前。因此,我尝试变得聪明,并将内容类型规范更改为:

-H "Content-Type: image/jpeg {"title":"myfile4"}" 

...但它也没有效果。

奇怪的是,谷歌自己的文档是不正确的,所以,我怀疑他们曾经使用的方法现在已经过时了。链接中的授权规范是错误的。您必须使用 Bearer 令牌,而不是“GoogleLogin”。我参考了这个链接:

https://developers.google.com/gdata/articles/using_cURL

我的整个脚本看起来像这样。它会上传,但不是在我想要的地方,也没有按照我想要的方式命名。

curl 
    --silent 
    --request POST 
    --data-binary "@c:\temp\myfile.jpg"         
    -OL MyFolder\myfile2.jpeg
    -H "Slug: myfile3.jpg" 
    -H "Authorization: Bearer abcdefg" 
    -H "Content-Type: image/jpeg {"title":"myfile4"}" 
    "https://www.googleapis.com/upload/drive/v2/files?uploadType=media" 

我意识到我在一个地方指定了“myfile2.jpg”,在另一个地方指定了“myfile3.jpg”,在另一个地方指定了“myfile4”。它们是否匹配或完全指定都没有区别。

任何帮助将不胜感激!

【问题讨论】:

    标签: curl google-drive-api


    【解决方案1】:

    您的问题是您正在制作没有元数据的媒体内容。你有两种前进的方式:-

    1. POST 元数据以创建空文件并捕获其文件 ID。然后使用 file-id 进行内容上传
    2. 在单个 POST 中创建一个包含元数据和内容的多部分 mime 正文

    就个人而言,我会选择选项 1,因为它将两个问题分开,但两者都同样有效。选项在https://developers.google.com/drive/web/manage-uploads

    中进行了描述

    【讨论】:

    • 但是如果服务器以某种方式无法发布第二个帖子,选项#1 不需要更多的往返和留下半生不熟的文件的机会吗?为什么你更喜欢选项 1?
    • Google 云端硬盘中没有半生不熟的文件。它要么存在,要么不存在,它要么有内容,要么没有内容。使用选项 1,如果第二个帖子失败,您只需重试即可。如果您使用分段上传,Drive API 规范中没有任何内容可以确认这是作为单个原子操作处理的。可能是这样,但如果它不在规范中,那么您将面临因错误或行为改变而绊倒的风险。使用选项 1 的另一个原因是您可以轻松升级代码以进行可恢复或分块上传。
    • 酷。我剩下的唯一挑剔的评论是我确实认为该文件可能是半生不熟的。我的意思是一个包含元数据但没有内容的文件。服务器不能总是重试,因为甚至可能没有收到/保存返回的文件 ID(比如它在步骤之间崩溃或失去连接),而在情况 2 中驱动器会更好地处理
    • 没有内容的文件在云端硬盘中比较常见。文件夹是具有特定 MIME 类型的无内容文件,快捷方式也是如此。应用程序可以有各种专有原因来创建无内容文件,例如特定于应用程序的标记机制(想想文件夹,但没有奇怪的级联删除)。服务器崩溃在这两种情况下都会留下同样不确定的情况。对于除非常小的文件之外的所有文件,建议进行可恢复或分块上传,这是选项 1 的变体。我没有测试过,但我怀疑选项 1 也为批量上传提供了更好的吞吐量
    • 在链接中,它说有两种方法,一种简单的方法和一种多部分。以简单的方式,通过 JSON 返回一个响应,该响应指示标题 - 但没有说明它是如何在请求中指定的。在多部分方式中,标题嵌入在正文中,但没有给出如何执行此操作的示例(我使用的是 cURL)。响应中返回的元数据包括标题(表面上是请求中的一组)。如何在这两种方法中指定标题?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-11-21
    • 1970-01-01
    • 1970-01-01
    • 2013-09-28
    • 2013-12-08
    相关资源
    最近更新 更多