問題添加文檔使用Unicode文件名

Question

---更新了清晰&解決方案---

，因爲它涉及到對文檔添加到我們注意到我們有上傳包含文檔的問題，現有的信封的能力Unicode文件名中的字符。我們的調用是對/ restapi/v2/accounts/[account id]/envelopes/[envelope id]/documents端點的多部分PUT請求，它將文檔數據作爲二進制內容在消息的其中一部分內發送，而不是base64對文檔進行編碼並將其嵌入爲json有效負載的一部分。

我們很快發現，寫入請求流的代碼部分使用的是Encoding.Ascii，應更改爲使用Encoding.UTF8。

using (var writer = new StreamWriter(stream, Encoding.ASCII, 1024, true)) 
{ 
    // write boundary, content type, content disposition & json content 
} 

但是，這種變化產生了一些錯誤信息，這取決於我們試過了，例如：

{ 
    "errorCode": "ENVELOPE_IS_INCOMPLETE", 
    "message": "The Envelope is not Complete. A Complete Envelope Requires Documents, Recipients, Tabs, and a Subject Line. Envelope definition missing." 
} 

---

{ 
    "envelopeId": "XXXXXXX-1869-4555-8831-eb3ed90850c2", 
    "envelopeDocuments": [ 
    { 
     "documentId": "1", 
     "order": "1", 
     "errorDetails": { 
      "errorCode": "NO_DOCUMENT_RECEIVED", 
      "message": "Bytes for document corresponding to documentId 1 not found in request." 
      } 
     } 
    ] 
} 

使用諸如Fiddler &郵差工具，我們現在可以看到出站REST調用，除了現在允許使用Unicode字符外，其他所有意圖和用途都與以前的調用幾乎相同。

PUT https://demo.docusign.net/restapi/v2/accounts/xxxxx/envelopes/xxxxxx-f772-48af-82ac-f0c2e95eaac1/documents HTTP/1.1 
Content-Type: multipart/form-data; boundary=soucecode 
Accept: application/json 
X-DocuSign-Authentication: [Creds Here] 
Host: demo.docusign.net 
Content-Length: 11691 
Expect: 100-continue 

--soucecode 
Content-Type: application/json 
Content-Disposition: form-data 

{ 
    "documents": [ 
    { 
     "order": 1, 
     "name": "Specíal Character.docx", 
     "documentId": "1" 
    } 
    ] 
} 
--soucecode 
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document 
Content-Disposition: file; filename="Specíal Character.docx"; documentid=1 

[binary content removed for brevity] 
--soucecode-- 

Answer 1

衆多紅鯡魚後的DocuSign支持終於能夠爲我們提供一個工作示例調用，它我們可以從菲德勒/郵差重播就在我們身邊。他們再次看起來幾乎相同。使用WinDiff顯示在正常編輯器中不可見的內容，我們可以看到細微的差異。在非功能性呼叫的邊界周圍注意到以下字符。這些字符被稱爲BOM（字節順序標記）。默認情況下，當使用UTF8編碼時，默認情況下，.net框架中的大多數Stream Writers會輸出這些BOM標記，因此不清楚它們是否存在或如何關閉它們。 DocuSign服務期望它們不在請求中，並且在它們出現時會失敗。

解決：實例化UTF8Encoding的新實例，將false傳遞給構造函數，如下所示。這將防止BOM被寫入到流中。

using (var writer = new StreamWriter(stream, new UTF8Encoding(false),1024, true)) 
{ 
    // new UTF8Encoding(false) 
    // the false flags instructs the writer to NOT emit the UTF8 Preamble (BOM) 
} 

難以置信的簡單修復一個非常難以捉摸的問題。

Answer 2

Docusign Rest Api還有一個額外的選項，以base64編碼方式傳遞文檔字節。這是您使用的多部分HTTP請求的替代方案。

從Documentation：

documentBase64：這個字段可以用來包括文檔字節的包絡定義內一個base64版本，而不是使用一個多部分的HTTP請求發送的文檔的。如果由於base64編碼的開銷而使用此字段，則文檔的最大尺寸會更小。

下面是一個示例updateEnvelopeDocuments請求

PUT /restapi/v2/accounts/{acccountId}/envelopes/{envelopeId}/documents HTTP/1.1 
Host: demo.docusign.net 
X-DocuSign-Authentication: <DocuSignCredentials><IntegratorKey>{key}</IntegratorKey><Username>{userName}</Username><Password>{pwd}</Password></DocuSignCredentials> 
Content-Type: application/json 

{ 
    "documents": [ 
     { 
      "documentId": "1", 
      "name" : "Doc Name", 
      "fileExtension": "pdf", 
      "documentBase64": "Add your Base64 encoded document bytes here" 
     } 
    ] 
} 

Answer 3

文檔名稱，和的DocuSign數據的任何其它部分處理Unicode字符就好，包括左到右。

關鍵是使用UTF-8編碼。這裏是JSON和在文檔名稱中使用希伯來文的快速測試的截圖。

JSON請求：在發送者的DocuSign網絡工具中顯示

{ 
    "documents": [ 
     { 
      "documentId": "1", 
      "name": "שלום Agreement", 
      "fileExtension": "html", 
      "documentBase64": "[Contents elided]" 
     } 
    ], 
    "emailSubject": "NewCo agreement for signature", 
    "status": "sent", 
    "recipients": { 
     "signers": [ 
      { 
       "recipientId": "1", 
       "name": "Larry", 
       "email": ... etc 

結果：

Answer 4

我剛剛完成了使用多部分MIME與使用希伯來語文件名的考驗。在一些問題之後，它運行良好。

問題來檢查：

1. 確保每個分隔行用「\ r \ n」個結束（這是根據本說明書中）
2. 檢查頭中的boundary設定，正確匹配的請求主體中使用的分隔符。請注意，boundary設置中不使用（分隔符格式的）破折號！
3. 檢查每個零件的每個「定義」行是否有「\ r \ n」行結尾。
4. 檢查每個分離後的空白行由「\ r \ n」
5. 你應該給你的請求的文件部分正確的內容類型，並給你的JSON的documents部分文件擴展名。例如："fileExtension": "docx"
6. 請確保documents對象和MIME部分的標題中的文件名（包括任何UTF-8字符）相同。 （見下）
7. 請記住包含該文件的mime部分是以二進制形式發送的。不需要base64編碼。

一旦我超過了上述，它一切正常。見下文。

Headers 
{ 
    "Authorization": "Bearer eyJ0eXAQXzvHysYca9V_47SUsBlahBlahBlah", 
    "Accept": "application/json", 
    "Content-Type": "multipart/form-data; boundary=AA1234" 
} 

Body Pretty-printed 
--AA1234 
Content-Disposition: form-data 
Content-Type: application/json 

{ 
    "emailSubject": "NewCo agreement for signature", 
    "status": "sent", 
    "recipients": { 
     "signers": [ 
      { 
       "recipientId": "1", 
       "name": "Joe Testor", 
       "email": "bvbv@gfg.ccvb", 
       "routingOrder": "1", 
       "tabs": { 
        "signHereTabs": [ 
         { 
          "documentId": "1", 
          "optional": "false", 
          "recipientId": "1", 
          "name": "Please sign here", 
          "tabLabel": "signer1sig", 
          "xPosition": "100", 
          "yPosition": "100", 
          "pageNumber": "1" 
         } 
        ] 
       } 
      } 
     ] 
    }, 
    "documents": [ 
     { 
      "name": "שלום Agreement.docx", 
      "documentId": "1", 
      "order": "1", 
      "fileExtension": "docx" 
     } 
    ], 
    "eventNotification": { 
     "includeDocumentFields": "false", 
     "envelopeEvents": [ 
      { 
       "envelopeEventStatusCode": "Completed" 
      }, 
      { 
       "envelopeEventStatusCode": "Declined" 
      }, 
      { 
       "envelopeEventStatusCode": "Voided" 
      } 
     ], 
     "url": "http://20f52d5f.proxy.webhookapp.com", 
     "requireAcknowledgment": "true", 
     "includeSenderAccountAsCustomField": "true", 
     "loggingEnabled": "true", 
     "includeDocuments": "false", 
     "signMessageWithX509Cert": "true" 
    } 
} 
--AA1234 
Content-Disposition: file; filename="שלום Agreement.docx"; documentId=1 
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document 

[Contents elided] 
--AA1234--