Gzip 压缩的二进制数据或未压缩的文本是否可以安全地通过 https 传输，或者它是否应该在发送之前的最后一步进行 base 64 编码？
Is Gzip compressed binary data or uncompressed text safe to transmit over https, or should it be base 64 encoded as the final step before sending it?
我的问题在标题中，这提供了上下文来帮助您理解我的困惑。一切都通过 https 发送。
我对 base 64 编码的理解是，它是一种将二进制数据表示为文本的方式，这样文本就可以安全地在网络或互联网上传输，因为它避免了任何可能被解释为控制代码的内容在某些时候可能涉及的各种可能的协议。
鉴于这种理解，我很困惑为什么通过 Internet 发送的所有内容都不是 base 64 编码的。什么时候在发送之前不对某些内容进行 base 64 编码是安全的？我知道并不是所有的东西都理解或期望以 base 64 接收东西，但我的问题是如果它是发送数据的唯一方式而不可能被解释为控制代码，为什么不是所有的东西都期望并使用它？
我正在设计 Android 应用程序和服务器 API，以便应用程序可以使用 API 向服务器发送数据。客户端将向服务器发送一些可能很大的 SQLite 数据库文件（我知道这听起来很奇怪，是的，它需要发送整个数据库文件）。它们在上传之前被 gzip 压缩。我知道还有一个header可以用来表示这个：Content-Encoding: gzip。压缩数据并用 header 发送它而不用 base 64 编码是否安全？如果不是，为什么使用不安全为什么会存在这样的header？我的意思是，如果您先对它进行 base 64 编码，然后再对其进行压缩，那么您撤消了 base 64 编码的点，并且在那个点上它不是 base 64 编码的。如果您先压缩它然后对其进行 base 64 编码，则 header 将不再有效，因为此时它不是压缩格式。我们实际上不想使用 header 因为我们想以压缩状态保存文件，并且使用 header 会导致服务器在我们的 API 代码之前解压缩它运行。我问这个只是为了进一步澄清为什么我对发送 gzip 压缩数据而不用 base 64 编码是否安全感到困惑。
我最好的猜测是，这取决于您发送的内容是否为二进制数据。如果您要发送二进制数据，上传前的最后一步应该是 base 64 编码。但如果您要发送文本数据，则可能不需要这样做。然而，在我看来，这仍然取决于所使用的字符编码。也许某些字符编码会导致发送可解释为控制代码的数据？如果这是真的，哪些字符编码可以安全发送，而无需将 base 64 编码作为发送前的最后一步？如果我对此是正确的，这意味着如果您要发送未经 base 64 编码的压缩文本，则只应使用 gzip header。压缩它是否会产生可以解释为控制代码的东西？
我意识到这太长了，所以我会在这里重复我的主要问题（标题）：Gzip 压缩二进制数据或未压缩文本是否可以安全传输，或者它应该是 base 64 编码作为之前的最后一步发送吗？好吧，我撒谎了，这里面还有一个问题。发送 gzip 压缩文本是否总是安全的，而不管它在压缩之前使用哪种字符编码，最后没有对其进行 base 64 编码？
My understanding of base 64 encoding is that it is a way of representing binary data as text,
具体而言，文本由 64 个字符集中的字符组成，外加几个用于特殊用途的附加字符。
such that the text is safe to transmit across networks or the internet because it avoids anything that might be interpreted as a control code by the various possible protocols that might be involved at some point.
这有点言过其实了。要让两个端点相互通信，它们需要就 one 协议达成一致。如果在此过程中涉及到另一个协议，那么该传输的端点有责任为其处理任何需要的编码注意事项。
可以成功传送哪些字节和字节组合取决于所使用的协议，并且有很多协议可以很好地处理二进制数据。
曾经还存在一个问题，即某些网络不是 8 位干净的，因此数值大于 127 的字节无法通过这些网络传输，但这在今天并不是一个实际问题。
Given this understanding, I am confused why everything sent to over the internet is not base 64 encoded.
鉴于你所表达的理解存在严重缺陷，你感到困惑也就不足为奇了。
When is it safe not to base 64 encode something before sending it?
当传输的接收者期望不同的东西时，避免使用 base 64 编码不仅安全而且必不可少。给定传输的两方或多方必须就要使用的协议达成一致。这建立了可接受的通信参数。尽管 Base 64 是部分或全部消息的可用选项，但它绝不是唯一的，也不一定是二进制数据的最佳选择，更不用说以文本开头的数据了。
I understand that not everything understands or expects to receive things in base 64, but my question is why doesn't everything expect and work with this if it is the only way to send data without the possibility it could be interpreted as control codes?
因为这绝不是避免数据被误解的唯一方法。
They are being gzipped prior to uploading. I know there is also a header that can be used to indicate this: Content-Encoding: gzip. Would it be safe to compress the data and send it with this header without base 64 encoding it?
预期 传输此类数据而不对其进行 base-64 编码。 HTTP(S) 可以很好地处理二进制数据。 Content-Encoding header 告诉收件人如何解释消息 body，如果它指定二进制内容类型（例如 gzip），则符合该内容类型的二进制数据就是收件人会期待。
My best guess is that it depends on if what you are sending is binary data or not.
没有。如今，出于所有实际意图和目的，它仅取决于您使用什么 application-layer 协议进行传输。如果它指定部分或全部消息要进行 base-64 编码（根据特定的 base-64 方案，因为有不止一个）那么这就是发送者必须做的以及接收者将如何解释消息。如果协议未指定，则发送方不得执行 base-64 编码。一些协议为发送者提供了做出这种选择的选项，但那些协议也为发送者提供了一种在传输中指示已做出什么选择的方式。
Is either Gzip compressed binary data or uncompressed text safe to transmit, or should it be base 64 encoded as the final step before sending it?
在当今的网络上传输都不是天生的不安全因素。数据是否经过base-64编码传输是发送方和接收方之间的协议问题。
Okay I lied there is one more question involved in this. Would sending gzip compressed text always be safe to send without base 64 encoding it at the end, no matter which character encoding it had prior to compression?
未压缩文本的字符编码不是 gzip 版本能否安全成功传送的因素。但对于接收者或他们转发该数据的任何人来说，正确理解未压缩的文本可能很重要。如果您打算容纳多种字符编码，那么您需要提供一种方法来指示适用于每个文本的编码。
我的问题在标题中，这提供了上下文来帮助您理解我的困惑。一切都通过 https 发送。
我对 base 64 编码的理解是，它是一种将二进制数据表示为文本的方式，这样文本就可以安全地在网络或互联网上传输，因为它避免了任何可能被解释为控制代码的内容在某些时候可能涉及的各种可能的协议。
鉴于这种理解，我很困惑为什么通过 Internet 发送的所有内容都不是 base 64 编码的。什么时候在发送之前不对某些内容进行 base 64 编码是安全的？我知道并不是所有的东西都理解或期望以 base 64 接收东西，但我的问题是如果它是发送数据的唯一方式而不可能被解释为控制代码，为什么不是所有的东西都期望并使用它？
我正在设计 Android 应用程序和服务器 API，以便应用程序可以使用 API 向服务器发送数据。客户端将向服务器发送一些可能很大的 SQLite 数据库文件（我知道这听起来很奇怪，是的，它需要发送整个数据库文件）。它们在上传之前被 gzip 压缩。我知道还有一个header可以用来表示这个：Content-Encoding: gzip。压缩数据并用 header 发送它而不用 base 64 编码是否安全？如果不是，为什么使用不安全为什么会存在这样的header？我的意思是，如果您先对它进行 base 64 编码，然后再对其进行压缩，那么您撤消了 base 64 编码的点，并且在那个点上它不是 base 64 编码的。如果您先压缩它然后对其进行 base 64 编码，则 header 将不再有效，因为此时它不是压缩格式。我们实际上不想使用 header 因为我们想以压缩状态保存文件，并且使用 header 会导致服务器在我们的 API 代码之前解压缩它运行。我问这个只是为了进一步澄清为什么我对发送 gzip 压缩数据而不用 base 64 编码是否安全感到困惑。
我最好的猜测是，这取决于您发送的内容是否为二进制数据。如果您要发送二进制数据，上传前的最后一步应该是 base 64 编码。但如果您要发送文本数据，则可能不需要这样做。然而，在我看来，这仍然取决于所使用的字符编码。也许某些字符编码会导致发送可解释为控制代码的数据？如果这是真的，哪些字符编码可以安全发送，而无需将 base 64 编码作为发送前的最后一步？如果我对此是正确的，这意味着如果您要发送未经 base 64 编码的压缩文本，则只应使用 gzip header。压缩它是否会产生可以解释为控制代码的东西？
我意识到这太长了，所以我会在这里重复我的主要问题（标题）：Gzip 压缩二进制数据或未压缩文本是否可以安全传输，或者它应该是 base 64 编码作为之前的最后一步发送吗？好吧，我撒谎了，这里面还有一个问题。发送 gzip 压缩文本是否总是安全的，而不管它在压缩之前使用哪种字符编码，最后没有对其进行 base 64 编码？
My understanding of base 64 encoding is that it is a way of representing binary data as text,
具体而言，文本由 64 个字符集中的字符组成，外加几个用于特殊用途的附加字符。
such that the text is safe to transmit across networks or the internet because it avoids anything that might be interpreted as a control code by the various possible protocols that might be involved at some point.
这有点言过其实了。要让两个端点相互通信，它们需要就 one 协议达成一致。如果在此过程中涉及到另一个协议，那么该传输的端点有责任为其处理任何需要的编码注意事项。
可以成功传送哪些字节和字节组合取决于所使用的协议，并且有很多协议可以很好地处理二进制数据。
曾经还存在一个问题，即某些网络不是 8 位干净的，因此数值大于 127 的字节无法通过这些网络传输，但这在今天并不是一个实际问题。
Given this understanding, I am confused why everything sent to over the internet is not base 64 encoded.
鉴于你所表达的理解存在严重缺陷，你感到困惑也就不足为奇了。
When is it safe not to base 64 encode something before sending it?
当传输的接收者期望不同的东西时，避免使用 base 64 编码不仅安全而且必不可少。给定传输的两方或多方必须就要使用的协议达成一致。这建立了可接受的通信参数。尽管 Base 64 是部分或全部消息的可用选项，但它绝不是唯一的，也不一定是二进制数据的最佳选择，更不用说以文本开头的数据了。
I understand that not everything understands or expects to receive things in base 64, but my question is why doesn't everything expect and work with this if it is the only way to send data without the possibility it could be interpreted as control codes?
因为这绝不是避免数据被误解的唯一方法。
They are being gzipped prior to uploading. I know there is also a header that can be used to indicate this:
Content-Encoding: gzip. Would it be safe to compress the data and send it with this header without base 64 encoding it?
预期 传输此类数据而不对其进行 base-64 编码。 HTTP(S) 可以很好地处理二进制数据。 Content-Encoding header 告诉收件人如何解释消息 body，如果它指定二进制内容类型（例如 gzip），则符合该内容类型的二进制数据就是收件人会期待。
My best guess is that it depends on if what you are sending is binary data or not.
没有。如今，出于所有实际意图和目的，它仅取决于您使用什么 application-layer 协议进行传输。如果它指定部分或全部消息要进行 base-64 编码（根据特定的 base-64 方案，因为有不止一个）那么这就是发送者必须做的以及接收者将如何解释消息。如果协议未指定，则发送方不得执行 base-64 编码。一些协议为发送者提供了做出这种选择的选项，但那些协议也为发送者提供了一种在传输中指示已做出什么选择的方式。
Is either Gzip compressed binary data or uncompressed text safe to transmit, or should it be base 64 encoded as the final step before sending it?
在当今的网络上传输都不是天生的不安全因素。数据是否经过base-64编码传输是发送方和接收方之间的协议问题。
Okay I lied there is one more question involved in this. Would sending gzip compressed text always be safe to send without base 64 encoding it at the end, no matter which character encoding it had prior to compression?
未压缩文本的字符编码不是 gzip 版本能否安全成功传送的因素。但对于接收者或他们转发该数据的任何人来说，正确理解未压缩的文本可能很重要。如果您打算容纳多种字符编码，那么您需要提供一种方法来指示适用于每个文本的编码。