UTF8,base64格式
大家好,
这是我的问题..我想了解通过multipart / form-data上传时文件内容如何或以何种格式传输到服务器..
当我尝试从我的代码[Salesforce - Apex]将文件和少量参数上传到服务器[Alfresco]时,服务器似乎没有从我的请求中识别出来。同时当我尝试使用任何REST客户端测试程序上传时,我工作正常,文档将上传到服务器中。
我设法在服务器端放置一个嗅探器,并跟踪来自Salesforce-Apex代码和REST客户端测试程序的传入http数据包。两者似乎都是相同的,但仍然服务器响应REST Client 200 200 OK和我的代码400 Bad Request。
下面是从String中显示的我的嗅探器中获取的示例跟踪。我想知道下面的HTTP请求的主体到底是多少,即以边界字符串开头的多部分/表格数据是在线路中遍历。
是 String,Blob,UTF-8,Base64编码还是任何其他格式
任何人都能为我提供相关的深度知识。还有关于这些格式,因为我发现很难理解这些格式究竟是什么以及这些格式是如何形成和解密的。
POST /alfresco/service/api/upload?alf_ticket=TICKET_f1fbae39901a12ce8e33a75b84b5931661f0acbb HTTP/1.0
SFDC_STACK_DEPTH: 1
User-Agent: SFDC-Callout/31.0
Accept: application/json
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarynwLnClZSXCKQvu3H
Pragma: no-cache
Host: myAlfrescoServer:8080
Content-Length: 581
Via: 1.1 proxy-was.net.salesforce.com:8080 (squid)
X-Forwarded-For: 10.236.12.23
Cache-Control: no-cache, max-age=259200
Connection: keep-alive
------WebKitFormBoundarynwLnClZSXCKQvu3H
Content-Disposition: form-data; name="filename"
12.txt
------WebKitFormBoundarynwLnClZSXCKQvu3H
Content-Disposition: form-data; name="description"
PPPPPPPPP
------WebKitFormBoundarynwLnClZSXCKQvu3H
Content-Disposition: form-data; name="siteid"
edms
------WebKitFormBoundarynwLnClZSXCKQvu3H
Content-Disposition: form-data; name="containerid"
documentLibrary
------WebKitFormBoundarynwLnClZSXCKQvu3H
Content-Disposition: form-data; name="filedata"; filename="12.txt"
Content-Type: text/plain
123
------WebKitFormBoundarynwLnClZSXCKQvu3H--
答案 0 :(得分:0)
如果您需要在服务器端解码表单数据,那么您真的应该考虑使用您选择的语言中的相关帮助程序。在PHP $_POST
中,在Java中类似FileItem
的文件,或Perl的CGI->param
等。
特别是,Alfresco的WebscriptServletRequest助手应该能够解决大部分的痛苦,并且通过它的声音,这对你来说很好。为什么不通过嗅探器发送REST请求并将其与Salesforce进行比较?你在Alfresco上遇到了什么样的错误?
但是,对于您的信息,multipart/form-data
很复杂,但缺点是它使用7-bit。
进一步阅读:
您可以在RFC2045的第六部分找到相关部分:
6.1. Content-Transfer-Encoding Syntax
The Content-Transfer-Encoding field's value is a single token
specifying the type of encoding, as enumerated below. Formally:
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
These values are not case sensitive -- Base64 and BASE64 and bAsE64
are all equivalent. An encoding type of 7BIT requires that the body
is already in a 7bit mail-ready representation. This is the default
value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.