HTTPClient MultipartEntity 似乎正在向 StringBody 部分添加垃圾文本

发布于 2024-11-06 21:09:44 字数 616 浏览 1 评论 0原文

我正在尝试使用 Apache Commons 的 HttpClient 发送带有二进制文件和几个字符串参数的多部分 POST 请求。

然而，似乎在这个过程中的某个地方，一些垃圾文本正在进入我的字符串参数。例如，通过调试器确认，这里的 sizeBody 变量确实保存着值“100”：

StringBody sizeBody = new StringBody("100", Charset.forName("UTF-8"));

但是，如果我使用 Wireshark 监听请求，我会看到以下内容：

--o2mm51iGsng9w0Pb-Guvf8XDwXgG7BPcupLnaa
Content-Disposition: form-data; name="x"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

100
a5

--o2mm51iGsng9w0Pb-Guvf8XDwXgG7BPcupLnaa

注意 a5 在 100 之后。

可能是什么原因造成的？我应该去哪里看？

原文

I am trying to use Apache Commons's HttpClient to send a multipart POST request with a binary file and a couple of string parameters.

However, it seems that somewhere along the line, some garbage text is making its way into my string parameters. For instance, as confirmed through the debugger, the sizeBody variable here is indeed holding the value "100":

StringBody sizeBody = new StringBody("100", Charset.forName("UTF-8"));

However, if I listen to the request with Wireshark, I see this:

--o2mm51iGsng9w0Pb-Guvf8XDwXgG7BPcupLnaa
Content-Disposition: form-data; name="x"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

100
a5

--o2mm51iGsng9w0Pb-Guvf8XDwXgG7BPcupLnaa

Note the a5 after the 100.

What could be causing this? Where should I look?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

醉态萌生 2024-11-13 21:09:44

您所看到的可能是所谓的块传输编码 [1] 使用的块头。查看消息头是否有 Transfer-Encoding: chunked 字段。

[1] http://en.wikipedia.org/wiki/Chunked_transfer_encoding

回复收藏 0 原文

放肆 2024-11-13 21:09:44

我在使用 NanoHTTPD 接收帖子时测试我的帖子时遇到了同样的问题。确实，HttpClient 使用的是分块传输编码，而 NanoHTTPD 不支持这种编码。在我的例子中，它是这样做的，因为二进制文件是通过 InputStreamBody 提供的，并且由于无法确定其自己的内容长度（它只是发回 -1），因此客户端使用分块编码。

我改用 ByteArrayBody 来存储文件内容，并且由于 ByteArrayBody 和 StringBody 可以提供内容长度，因此请求现在不使用分块编码。

ByteArrayOutputStream baos = new ByteArrayOutputStream();
IOUtils.copy (fileInputStream, baos);  // from Apache Commons IO, or roll your own
ContentBody filePart = new ByteArrayBody (baos.toByteArray(), fileName);

当然，如果您的文件很大，则将整个文件加载到上面的字节数组中可能会导致内存问题。

I had this same issue testing my POSTs with NanoHTTPD receiving them. It's indeed that HttpClient is using chunked transfer encoding, which NanoHTTPD doesn't support. It did that in my case because the binary file was supplied via an InputStreamBody, and since that cannot determine its own content length (it just sends back -1), the client uses chunked encoding.

I switched to using a ByteArrayBody for the file contents, and since that and StringBody can supply content lengths, the requests now do not use chunked encoding.

ByteArrayOutputStream baos = new ByteArrayOutputStream();
IOUtils.copy (fileInputStream, baos);  // from Apache Commons IO, or roll your own
ContentBody filePart = new ByteArrayBody (baos.toByteArray(), fileName);

Of course, if your file is huge, loading the whole thing into a byte array as above could cause memory problems.

回复收藏 0 原文

~没有更多了~