以下是8 位干净含义的概述。
在 Web 应用程序的上下文中，为什么将图像保存为 Base64？有 33% 的开销与 8 位干净相关。
如果传输方法是安全的，则不需要这样做。
但基本上，我的图片是在服务器上保存为Base64的，然后传输到客户端，众所周知，客户端可以读取Base64。
这是 SO Post 中 Base 64 的客户端版本。
如何在 JavaScript 中将字符串编码为 Base64？
http/https 8 位干净吗？
参考
http://www.princeton.edu/~achaney/tmve/wiki100k/docs/8-bit_clean.html
你在问两个不同的事情。
问：http 8 位干净吗？
答：是的，HTTP 是“bit 8 clean”。
问：在 web 应用的上下文中，为什么图片保存为 Base64？
A：图片通常不保存在 Base64 中。事实上，他们几乎从来没有。它们通常以压缩二进制格式（PNG 或 JPG 或类似格式）保存、传输或流式传输
Base64 用于在 HTML中嵌入图像。
所以，你得到了一个图像logo.png。您将其静态包含在您的页面中作为<img src='logo.png'>. 图像以二进制形式通过 HTTP 传输，在浏览器和服务器端都没有编码。这是最常见的情况。
或者，您可能决定将图像的内容嵌入 HTML 中。它有一些优点：浏览器不需要第二次访问服务器来获取图像，因为浏览器已经在 HTML 文件的同一个 HTTP GET 响应中接收到它。但也有一些缺点，因为 HTML 文件是文本，某些字符值可能对 HTML 有特殊意义（不是 HTTP），你不能只在 HTML 文本中嵌入二进制值。您必须对它们进行编码以避免此类冲突。最常用的编码方法是 base64，它只用 33% 的开销就避免了所有的冲突。
RFC 2616的摘要状态：
HTTP 的一个特性是数据表示的类型化和协商，允许独立于正在传输的数据构建系统。
HTTP 始终以纯文本标头开头，并在此标头中指定内容类型。只要发送者和接收者就这个内容类型达成一致，一切皆有可能。
HTTP 依赖于可靠的（识别文字游戏）传输层，例如 TCP。HTTPS 只为传输层（或传输层和 HTTP 之间，不确定这一点）增加了安全性。
所以是的，http(s) 是 8 位干净的。
除了 PA 的回答和您的问题“但是为什么在不需要时使用会增加 33% 开销的编码方法？”：因为这是不同概念的一部分！
HTTP 传输任何类型的数据，http-content 可能是带有嵌入图片的 html 文件。但是在接收到该 html 文件后，浏览器或其他渲染器必须解释 html 内容。这遵循不同的标准，需要对任意数据进行编码。html不是8 位干净的，实际上它甚至不是 7 位干净的，因为对使用的字符及其出现顺序有很多限制。
在 Web 应用程序的上下文中，为什么将图像保存为 Base64？有 33% 的开销与 8 位干净相关。
Base64 用于允许 8 位二进制数据在 ASCII 定义中显示为可打印文本。这只是 7 位，而不是 8 位，因为最后 128 个字符将取决于设置的编码（Latin1、UTF8 等），这意味着如果在客户端/接收器端设置了不同的编码类型，则编码数据可能会被破坏来源。
由于 ASCII 中没有足够的可打印字符来表示所有 8 位值（具有绝对值并且不依赖于编码本身），您需要“浇水”并且 base-64 保持足够高的数字以启用要表示为可打印字符的字节。
这是您看到的 33% 开销，因为表示可打印范围之外的字符的字节值必须转换为可在 ASCII 表中打印的值；Base-64 允许这样做（您也可以使用引用的可打印文件，这在过去很常见，即使用 Usenet、电子邮件等）。
我正在考虑编写另一种编码类型来消除开销。
祝你好运 ：-）
与查询相关
HTTP 协议不完全是一个 8 位的干净协议。
HTTP Entity Body 是 8 位干净的，因为有一个建议内容类型的规定，允许交互实体之间的内容协商，正如该线程中的每个人所指出的那样。
但是请求行、标头和状态行不是 8 位干净的。
为了发送任何二进制信息作为
请求行，作为查询参数/路径段的一部分
标题
必须使用其中一种二进制到文本编码来保留二进制值。
例如，当作为查询参数或标头的一部分发送签名时，这是 CDN 采用的签名 URL 技术的情况，必须对签名二进制信息进行编码以保留其二进制值。