Centre de services

Gestion de fichiers

L'ajout de fichiers signale une erreur car fileKey n'existe pas, signalant «File cannot be found.

Veuillez vérifier si, après avoir utilisé l'interface pour obtenir l'adresse du fichier, vous avez utilisé l'URL d'upload de fichier obtenue pour uploader le flux de fichiers en utilisant la méthode HTTP PUT. Si vous ne l'avez pas uploadé, veuillez appeler l'URL pour uploader le fichier.

 

Quelle est la durée de validité de l'adresse d'upload de fichier ?

Adresse d'upload de fichier, lienLa durée de validité de la connexion est de 60 minutes.

 

 

Le site d'upload de fichiers lors de l'intégrationhttps://file-sml.esignglobal.com/Est particulièrement lent, l'upload de fichiers est lent

Il est important de noter que l'environnement sandbox pour l'upload de fichiers est situé à Singapour. L'accès direct depuis la Chine entraîne souvent une instabilité du réseau, avec des problèmes tels que des blocages, des chargements lents ou un accès impossible. Par conséquent, il est recommandé d'accéder via un proxy à Singapour, ce qui contribue à améliorer l'instabilité du réseau et à faciliter l'utilisation de ce service de fichiers.

 

 

L'appel openapi pour obtenir l'adresse du fichier réussit, mais l'upload du fichier échoue ensuite

Étape 1 : Obtenir l'adresse de téléchargement du fichier Lors de l'opération, vous devez fournir les informations pertinentes dans le format suivant pour obtenir l'adresse de téléchargement du fichier : { "fileName": "fengniantest.pdf", "contentType": "application/pdf" } Veuillez noter que bien que le nom du fichier soit ici « fengniantest.pdf », le type de contenu (contentType) est spécifié comme « application/pdf ». Vous devez vous assurer que les paramètres pertinents sont exacts. 

Étape 2 : Ajouter des informations d'en-tête de requête lors du transfert direct de fichiers Lors de l'exécution d'une opération de téléchargement direct de fichiers, vous devez ajouter l'information 'Content-Type: application/pdf' à l'en-tête (headers) pour spécifier le type de fichier téléchargé et garantir le bon déroulement de l'opération de transfert direct de fichiers.

 

 

Quels formats de fichiers sont pris en charge par le téléchargement de fichiers openapi ?

Les formats de fichiers suivants sont pris en charge : PDF (.pdf), Word (.docx, .doc), RTF (.rtf), Excel (.xlsx, .xls), PowerPoint (.pptx, .ppt), WPS 文字 (.wps), WPS 表格 (.et), WPS 演示 (.dps), JPEG (.jpeg, .jpg), PNG (.png), BMP (.bmp), TIFF (.tiff), GIF (.gif), HTML (.html, .htm) et CSV (.csv).

 

 

 

La requête de tâche de synthèse de fichiers via taskId affiche « Échec de la conversion de fichier : échec de l'accès à l'adresse réseau »

Lorsqu'un document met trop de temps à être converti, cela entraîne souvent l'échec de la synthèse du fichier. Dans ce cas, vous pouvez rappeler le modèle pour générer le fichier, puis appeler l'interface de requête de tâche de synthèse de fichier pour voir si la synthèse du fichier a réussi cette fois. Si la synthèse du fichier échoue toujours après les opérations ci-dessus, vous pouvez contacter directement le personnel technique, qui vous aidera à résoudre ce problème.

 

 

L'appel pour obtenir l'adresse de téléchargement du fichier et les paramètres de transfert direct du fichier sont corrects, mais le transfert direct du fichier signale toujours "403 Forbidden: "<?xml version="1.0" encoding="UTF-8"?><EOL><Error><EOL> <Code>SignatureDoesNotMatch</Code><EOL> <Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><EOL> <RequestId>68440537821143343409E1E9</RequestId><EOL>"

Si le paramètre de l'étape 1 estcontentTypeCorrespondant à celui transmis dans l'en-tête de l'étape 2Content-Typeet appelé via PostmanfileUploadUrlLe transfert direct de fichier réussit, mais une erreur se produit toujours lors de l'appel de code. Après avoir vérifié les paramètres par point d'arrêt, la transmission des paramètres est correcte, il peut y avoir un problème de compatibilité avec l'application du framework. Il est recommandé de se référer à l'exemple de code suivant pour le transfert direct de fichiers :

Code de référence :

// 调用方式(以Java为例)
Response response = HttpUtil.sendRequest(
    "uploadUrl",                // 上传接口URL
    new File("文件路径/xxx.pdf"), // 待上传文件
    "application/pdf",          // 内容类型
    new HashMap<>()             // 可选请求头参数(若无则传空)
);

Explication clé :

  1. Vérification de la cohérence des paramètres : assurez-vous que dans le codeContent-Typeles paramètres (tels que"application/pdf") sont complètement cohérents avec les exigences de l'interface, y compris la casse et le format (par exemple,application/jsondoit être strictement distingué deapplication/JSON).
  2. Dépannage de la compatibilité du framework : si la logique du code est correcte mais qu'une erreur se produit toujours, vous pouvez essayer de contourner le framework client et d'utiliser directement un client HTTP natif (tel queURLConnectionde Java, ourequestsde Python) pour vérifier si le problème vient de la compatibilité du framework avec le traitement des en-têtes de requête et des flux de fichiers.
  3. Localisation des journaux d'erreurs : il est recommandé aux clients de capturer et d'enregistrer les informations d'erreur complètes (telles que le code d'état HTTP, le message de réponse du serveur) afin d'enquêter plus avant sur la cause spécifique de l'erreur au niveau de la couche réseau ou du serveur.

Cette solution, en normalisant la transmission des paramètres et en simplifiant la chaîne d'appel, peut isoler efficacement les problèmes de framework et localiser rapidement la cause première de l'échec du transfert direct de fichiers.