Actuellement, les URL des archives téléchargées semblent être indirectes et n'incluent pas l'extension du nom de fichier (par exemple, wget) - idéalement, le nom de fichier de l'archive doit être conservé lors du téléchargement à l'aide d'un outil sur la ligne de commande. Est-il possible de changer cela?
Merci pour le signalement. AFAIK c'est déjà pris en charge. Exemple:
$ wget https://zenodo.org/api/files/4f53dd1f-df5f-4a9c-8b46-6eacfc4b8840/results.zip
--2018-10-24 08:33:10-- https://zenodo.org/api/files/4f53dd1f-df5f-4a9c-8b46-6eacfc4b8840/results.zip
Resolving zenodo.org... 137.138.76.77
Connecting to zenodo.org|137.138.76.77|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 309980977 (296M) [application/octet-stream]
Saving to: 'results.zip'
Avez-vous un exemple où ce n'est pas le cas?
Salut @lnielsen ,
https://zenodo.org/record/51405
Cet enregistrement, par exemple, contient des fichiers au format
https://zenodo.org/record/<record number>/files/<filename>?download=1
,
qui est différent du
https://zenodo.org/api/files/<UID>/<filename>
format que vous donnez ci-dessus. En ce qui concerne la demande de @bbarker , l'utilisation wget
sur le premier n'est pas possible.
C'est peut-être de l'ignorance de ma part. Y a-t-il une méthode qui me manque pour obtenir le permalien de style API ?
@benjaminhwilliams Dans les deux cas, c'est le même morceau de code qui sert le fichier, la seule différence est que vous obtiendrez un joli message d'erreur humaine sur https://zenodo.org/record/<record number>/files/<filename>?download=1
pour par exemple 404 pages.
En termes de wget
et de ?download=1
, c'est à mon avis un mauvais comportement wget
. Vous pouvez cependant simplement supprimer les ?download=1
pour satisfaire wget
.
wget
se comporte mal car nous envoyons en fait le nom de fichier correct dans les en-têtes HTTP. Voir ci-dessous:
$ curl -I "https://zenodo.org/record/51405/files/l-cyst_01.tar.gz?download=1"
HTTP/1.1 200 OK
...
Content-Disposition: attachment; filename=l-cyst_01.tar.gz
...
Cela dit, si vous avez besoin de téléchargements automatisés, mieux vaut utiliser notre API REST où vous obtenez des liens directs vers les fichiers :
$ curl https://zenodo.org/api/records/51405
{
...
"files": [
{
"bucket": "cbc7d513-2359-47fe-a9c6-f826de7776c5",
"checksum": "md5:780a7b23320307ae8b6cf2d6e99ade1f",
"key": "l-cyst_fast_04.tar.gz",
"links": {
"self": "https://zenodo.org/api/files/cbc7d513-2359-47fe-a9c6-f826de7776c5/l-cyst_fast_04.tar.gz"
},
"size": 140654635,
"type": "gz"
},
{
"bucket": "cbc7d513-2359-47fe-a9c6-f826de7776c5",
"checksum": "md5:c04800ec8ffaaad867ee54a3a1688ac5",
"key": "l-cyst_very_fast_01.tar.gz",
"links": {
"self": "https://zenodo.org/api/files/cbc7d513-2359-47fe-a9c6-f826de7776c5/l-cyst_very_fast_01.tar.gz"
},
"size": 63254814,
"type": "gz"
},
...
}
Merci @lnielsen. Curl'api/records/record_id a fonctionné pour récupérer des URL wget'able. Il serait utile de faire apparaître ces URL wget'able directement sur le site, si possible.
Commentaire le plus utile
Merci @lnielsen. Curl'api/records/record_id a fonctionné pour récupérer des URL wget'able. Il serait utile de faire apparaître ces URL wget'able directement sur le site, si possible.