假设我有一个HTTP POST方法，简单地回应请求的正文，并且我这样做：
curl -X POST -d "test non-binary data" "https://endpoint/path/to/resource"
正如预期的那样，这将导致以下回调：
"test non-binary data"
现在让我说我将这些数据传递为二进制文件，如下所示：
curl -X POST --data-binary "test binary data" "https://endpoint/path/to/resource"
这将给我以下内容：
"dGVzdCBiaW5hcnkgZGF0YQ=="
但我可以让我的API解码base64数据并将其解释为ASCII以返回以下内容：
"test binary data"
正如预期的那样，这与非二进制请求相同。因此，结果是相同的，传递二进制文件与非二进制请求体之间的区别究竟是什么？使用二进制数据有什么好处吗？如果是这样，当我想要使用二进制数据时，有哪些例子呢？
答案 0 :(得分：2)
正如预期的那样，这与非二进制请求相同。因此，结果是相同的，传递二进制文件与非二进制请求体之间的区别究竟是什么？使用二进制数据有什么好处吗？如果是这样，当我想要使用二进制数据时，有哪些例子呢？
一次有很多问题，让我们解读一下：
因此，如果结果相同，那么传递二进制文件与非二进制请求体之间究竟有什么区别？
评论和答案中都提到了这一点。不同之处在于，当不使用“二进制数据”时，可能会发生解析，将数据的含义（作为原始二进制数据）更改为不同的内容，例如要上载的文件或shell的字符编码（这可能也适用于二进制数据）但后来不那么出乎意料了。）
使用二进制数据有什么好处吗？
是的，它更具表现力。您可以更准确地说明在任何情况下您要传输哪些数据（仍然可以根据您的shell规则修改选项参数）。
如果是这样，当我想要使用二进制数据时会有哪些例子呢？
我懒得提供这些，所以只做两个测试，一个有一个，一个没有。当你正在测试时，从你的问题开始，你期望两者都是一样的。如果您在同一测试用例中对该期望进行编码，则可以添加数据提供程序，然后在运行它们时添加回归。这些更改将随着时间的推移回答您的问题。如果您不能回答问题，甚至在Stackoverflow和其他资源的反馈之后，您需要确保满足您的期望，即使这些是一次性的。
这些是你的测试。按照你的理解写下它们。如果有错误，请稍后修复。这是版本控制的用途。如果您遇到错误，您的测试会告诉您。根据自己的需要使用测试。基本上就是这样。您可能需要在将来做出更改，因为您错了。但是，测试通常反映了您编写时的心态。所以在这种情况下，你的测试应该指出你不明白这两个选项之间的区别，所以只断言两者都做同样的事情。通过编写测试来记录（但不要跳过一个选项，而你认为它是相同的，但你不确定它是什么），并且你将编写正确的测试。如果您意识到错误，可以稍后修复测试，此时更改应完整记录您应该完成的操作。不要隐瞒你的问题，而是通过测试来确定答案。测试很容易再次运行，因此您可以轻松检查您的期望。
答案 1 :(得分：1)
- data-binary
（HTTP）这完全按照指定发布数据，无需额外处理 任何。
如果你用字母@开始数据，其余的应该是a 文件名。数据以与-d相似的方式发布， - 数据， 除了新线和回车被保留和 转换从未完成。
如果多次使用此选项，则第一次使用此选项 将按照-d， - data。
中的描述附加数据
您不应使用--data-binary选项接收base64编码数据。如果你这样做，那就不是curl相关的。
直接提出问题 - 我看到的唯一好处是curl不会处理传递的数据。如果您需要来保留换行符等，则使用它是有意义的。
答案 2 :(得分：1)
是的，这是关于可靠性，安全性和上传文件的能力。当你总是希望curl发送你提供的字符串时，请使用--data-binary。如果您希望curl支持上传文件，请使用--data
现在在可以为--data选项提供任何文本字符串的程序中，如果您的字符串以@开头，它可能会出现意外行为，然后它可能会开始上传文件而不是上传您要求它上传的字符串！ - 至于安全性，想象一下黑客可以选择--data选项中的内容（但它是正确的shell转义，因此黑客无法注入shell命令），然后黑客可以欺骗curl上传任何敏感文件，例如{ {1}} - curl实际上会上传passwd，而不是发送字符串本身。但是如果使用--data-binary，curl将按原样上传字符串，对于以--data '@/etc/passwd'开头的字符串不会有不同的行为。