HttpServletRequest InputStream损坏？

Question

我通过java servlet收到了一个包含多部分mime的附件。可以这样处理:

 InputStream inputStream = request.getInputStream();           
 byte[] data = IOUtils.toByteArray(inputStream);

 File file = new File("/usr/local/user/message.txt");
 FileOutputStream fos = new FileOutputStream(file);
 fos.write(data);
 fos.close();

在multipart mime中，二进制代码给我提供了损坏的数据。有人知道为什么会发生这种情况吗？我将二进制数据复制到文件中，并将文件扩展名更改为适当的图像扩展名，但是我得到了一个损坏的图像。比较message.txt和.snoop文件的十六进制数据表明，十六进制数据存在轻微差异，导致失真。ASCII数据没有任何更改。谢谢。

就像你可以看到图片在开始时看起来正确，但是它开始变得奇怪，因为十六进制值是错误的。例如：客户端的06 04 04 04 04 04 06 04 04 06 0a变成了上述操作后的06 04 04 04 04 04 06 04 04 06 0D，这就是失真。

- Maurice

---

比较 message.txt 和 .snoop 文件的十六进制数据表明，十六进制数据存在轻微差异导致了扭曲。能否详细说明这些扭曲？此外，如果您拥有网络嗅探/捕获，能否更新问题并提供客户端发送的 Content-Encoding 标头信息？ - Vineet Reynolds

Content-Encoding未发送，因此假定为二进制。扭曲是指您可以看到图片在开始时看起来正确，但由于十六进制值错误，它开始变得奇怪。例如：客户端的06 04 04 04 04 04 06 04 04 06 0a在我执行上述操作后变为06 04 04 04 04 04 06 04 04 06 0D。 - Maurice

0A代表LF，0D代表CR。我认为这是Unix和Windows换行符的问题。 - Vineet Reynolds

正在发生的是我将文件写入Linux系统。使用WINSCP将文件复制到Windows机器上查看。这会导致数据发生变化吗？不仅仅是0A和0D，还有一些其他数据也会发生变化，然后它们会再次看起来相同一段时间。 - Maurice

很可能（因为您最初将文件命名为.txt）。请阅读WinSCP网站上的此FAQ。编辑：使用二进制模式进行传输，看看是否有区别。 - Vineet Reynolds

Answer 1

根据评论，看起来文件已经被正确地写入磁盘了（这是我的理解）。

WinSCP 用于将文件从（Linux/Unix）机器传输到 Windows 机器。在传输过程中使用的传输模式可能会导致 WinSCP 将所有 Unix 样式的换行符转换为 Windows 样式的换行符，或者反之，这取决于传输起源的位置。当文本模式用于传输文件时，或者当允许 WinSCP 确定是否应使用文本模式还是二进制模式来传输文件时，就会发生这种情况。你可能已经将其设置为默认模式，因此强制以二进制方式传输文件；如果这没有起作用，你需要进一步调查。

如果 WinSCP 看起来是这个问题的原因，则可以通过查看两个平台上文件的二进制内容来确认它。你可以在 Linux/Unix 上使用 xxd。在 Windows 上，this question 中列出的其中一个实用工具将有所帮助。

您也可以使用其他文件复制协议，如FTP、SFTP，甚至使用NFS或Samba来传输文件，并将WinSCP作为原因。

- Vineet Reynolds

Answer 2

对于多部分 MIME，您可以使用 Apache Fileupload 库。您可以在此处找到它：

Apache Fileupload 下载路径

起步教程

- Asad Rasheed

---

你看过问题了吗？OP指的是在服务器端解析请求时出现的差异，而不是如何解析请求。此外，多部分POST使用Base64编码，而不是二进制附件。 - Vineet Reynolds