2

所以我目前正在研究 HTTP 文件上传（在使用 aHttpWebRequest将一些文件上传到外部 API 的上下文中），通常我看到几十个破折号被用作边界。浏览器似乎通常也会在破折号中添加一个随机选择的十六进制数字。

至少可以说这似乎非常笨拙（我敢说协议中的缺陷吗？）。由于我的特定用例涉及的数据很可能包含我使用的边界（无论我选择什么；数据都是某种转储），我需要 100% 确定我上传的文件不会破坏事情。随机选择一个数字对我来说根本是不可接受的，即使实际碰撞的可能性是十亿分之一。如果目标脚本检测到一些错误，我也不喜欢使用不同的随机选取的边界重试。

避免这种情况的唯一方法是扫描我的整个文件（通常是几兆字节）以查看我选择的边界是否不存在？我需要通过上传执行许多不同的请求，因此为了避免 I/O 损失，我想避免扫描整个文件。

或者是否有某种尺寸参数我可以传递，这样边界就变成了一种形式？

我错过了什么？更改远程 API 不是一种选择，因此无法使用 Base64 编码或添加某种转义字符。

4

4 回答 4

2

我个人不知道比扫描边界数据更快的方法。对于大多数应用程序，我相信他们就是这样做的（下载 Firefox 的源代码并查看一下？）。

  1. 创建的随机边界（理想情况下不太可能出现在数据中，例如 --------saDad8g3--------）
  2. 搜索包含在其中的边界的数据
  3. 如果找到边界，则返回 1。

我的猜测是，如果找到边界，代码会更改创建的随机边界并再次扫描。

您可以通过将步骤 3 更改为：如果找到边界，则将一个字节附加到边界的末尾，该字节不是数据中的下一个字节，然后继续搜索数据。

如果您真的认为您的应用程序具有如此高的性能要求以至于扫描您的上传边界是一个问题，我会推荐这个替代方案：

  1. 创建的随机边界（同样，理想情况下不太可能出现在数据中）
  2. 不要检查您的数据是否发生（并且只是假设碰撞机会非常低）并上传。
  3. 如果您收到服务器错误，请返回到步骤 1，这将创建一个新边界，希望该边界不会在数据中再试一次。

不过我的猜测是，最好在上传之前简单地扫描数据，而不是必须解决来自服务器的 400 错误是否是您的上传边界的错误或其他原因。

于 2010-11-29T09:06:39.777 回答
0

为确保唯一性，请使用 UUID/GUID 作为边界字符串，如以下代码所示：https ://wqweto.wordpress.com/2011/07/12/vb6-using-wininet-to-post-binary-文件/

在线 GUID 生成器：https ://guidgenerator.com/online-guid-generator.aspx

于 2015-07-14T10:45:51.670 回答
0

当使用所有70 个字符作为随机字母数字边界和 1GB 数据时，您发生碰撞的机会不是十亿分之一，而是更像是十分之一¹¹⁷。由于流星撞击，你有更多机会在下一秒内失去左小脚趾。如果这不能给你信心，我怕什么都不会:)。请在此处阅读我对几乎相同问题的回答。

于 2018-02-13T20:16:44.510 回答
-1

“我错过了什么？”

常识？:P

这是一种方法-读入要上传的文件，然后修改随机字节，瞧，您已经为自己制作了一个边界，该边界肯定不会在要上传的文件中重复出现。但实际上，这是没有意义的。例如，设置一个 10k 的边界会使冲突的概率变暗，以至于人类更有可能在字节冲突发生之前消失。

于 2010-11-28T01:27:31.427 回答