HttpServletRequest InputStream 已损坏？

Posted 2023-03-15

【中文标题】HttpServletRequest InputStream 已损坏？

【英文标题】：HttpServletRequest InputStream corrupted?

【发布时间】：2011-09-17 01:14:49

【问题描述】：

我通过 java servlet 接收 SOAPMessage，其附件部分包含多部分 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();

为我提供多部分 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。

【问题讨论】：

“比较message.txt的十六进制数据和一个.snoop文件，发现十六进制数据有细微的差别，导致失真”。你能扩展这些扭曲吗？另外，如果你有网络监听/捕获，你能用客户端发送的 Content-Encoding 标头更新问题吗？

内容编码未发送，所以假设它是二进制的。失真，你可以看到图片一开始看起来是正确的，但一段时间后它开始看起来很奇怪，因为十六进制值是错误的。例如： 06 04 04 04 04 04 06 04 04 06 0a 在我执行上述操作后，来自客户端的变为 06 04 04 04 04 04 06 04 04 06 0D。

0A 是 LF，0D 是 CR。我认为这是 unix vs windows 行尾的问题。

我正在将文件写入 Linux 系统。使用 WINSCP 我将文件复制到 Windows 机器上以查看它。这会导致数据发生变化吗？不只是 0A 和 0D，其他一些数据也发生了变化，然后它们看起来又一样了。

可能（假设您最初将文件命名为 .txt）。阅读 WinSCP 站点中的this FAQ。 编辑：使用二进制方式传输，看看有没有区别。

【参考方案1】：

根据 cmets，看来文件正在正确写入磁盘（这是我的解释）。

WinSCP 用于将文件从 (Linux/Unix) 机器传输到 Windows 机器。传输过程中采用的传输模式可能会导致 WinSCP 将所有 unix 样式的行尾转换为 Windows 样式的行尾，反之亦然，具体取决于传输的来源。当使用文本模式传输文件时，或者当允许 WinSCP 确定它应该使用文本模式还是二进制模式来传输文件时，就会发生这种情况。您可能已将其设置为默认模式，因此强制以二进制格式传输文件；如果这不起作用，您需要进一步调查。

如果 WinSCP 似乎是导致此问题的原因，您可以通过查看两个平台上文件的二进制内容来确认它。你可以使用xxd on Linux/Unix。在 Windows 上，this question 中列出的实用程序之一会有所帮助。

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

【参考方案2】：

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

Apache Fileupload download path

Starter tutorial

【讨论】：

你读过这个问题吗？ OP指的是在服务器端解析请求的差异，而不是如何解析请求。此外，multipart post 使用 base64 编码，而不是二进制附件。