维基百科上说
当需要对二进制数据进行编码时，通常使用Base64编码方案，这些数据需要通过设计用于处理文本数据的媒体存储和传输。这是为了确保数据在传输过程中保持完整而不被修改。
但是，数据不总是以二进制存储/传输吗?因为我们机器的内存存储二进制，这只是取决于你如何解释它?因此，无论您将位模式010011010110000101101110编码为ASCII中的Man还是Base64中的TWFu，最终都将存储相同的位模式。
如果最终的编码是用0和1表示的，并且每台机器和媒体都可以处理它们，那么数据是用ASCII还是Base64表示有什么关系呢?
“设计用于处理文本数据的媒体”是什么意思?他们可以处理二进制=>他们可以处理任何东西。
谢谢大家，我想我现在明白了。
当我们发送数据时，我们不能确定数据将以与我们预期的相同格式进行解释。因此，我们发送以双方都能理解的某种格式(如Base64)编码的数据。这样，即使发送方和接收方对相同内容的解释不同，但由于他们对编码格式达成一致，数据也不会被错误地解释。
来自Mark Byers的例子
如果我想发送
Hello
world!
一种方法是用ASCII码发送
72 101 108 108 111 10 119 111 114 108 100 33
但是字节10在另一端可能不能被正确地解释为换行符。因此，我们使用ASCII的一个子集来像这样编码
83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61
以传输相同数量信息的更多数据为代价，确保接收者能够以预期的方式解码数据，即使接收者对其余字符集有不同的解释。
更重要的是，媒体验证字符串编码，因此我们希望确保处理应用程序可以接受数据(例如，不包含表示EOL的二进制序列)。
假设您希望在编码为UTF-8的电子邮件中发送二进制数据——如果1和0的流创建的序列不是有效的UTF-8编码的Unicode，则电子邮件可能无法正确显示。
当我们想在URL中编码对URL本身无效的字符时，同样的事情也会发生在URL中:
http://www.foo.com/hello我的朋友-> http://www.foo.com/hello%20my%20friend
这是因为我们想在一个系统上发送一个空间，这个系统会认为这个空间很臭。
我们所做的只是确保在已知的良好、可接受且无害的比特序列与另一个比特文字序列之间存在1对1的映射，并且处理应用程序不会区分编码。
在你的例子中，man可能是第一种形式的有效ASCII;但通常你可能想要传输随机二进制值(例如在电子邮件中发送图像):
MIME-Version: 1.0
内容描述:"Base64编码的。gif"
内容类型:/ gif图像;name = " a.gif "
Content-Transfer-Encoding: Base64
附加:附件;文件名= " a.gif "
在这里，我们看到GIF图像以base64编码为电子邮件的一个块。电子邮件客户端读取标题并解码。由于编码，我们可以确保GIF不包含任何可能被解释为协议的内容，并且我们避免插入SMTP或POP可能认为重要的数据。
“媒体是”是什么意思
设计用于处理文本数据”?
这些协议被设计用来处理文本(通常只有英文文本)，而不是二进制数据(如.png和.jpg图像)。
他们可以处理二进制=>他们可以
处理任何事情。
但反过来就不对了。为表示文本而设计的协议可能不恰当地处理恰好包含以下内容的二进制数据:
字节0x0A和0x0D，用于行结束，因平台而异。
其他控制字符，如0x00 (NULL = C字符串结束符)，0x03(文本结束)，0x04(传输结束)，或0x1A (DOS文件结束)，可能过早地表示数据结束。
大于0x7F的字节(如果协议是为ASCII设计的)。
无效的UTF-8字节序列。
所以你不能仅仅通过基于文本的协议发送二进制数据。您只能使用表示非空格非控制ASCII字符的字节，其中有94个。选择64进制的原因是，它可以更快地计算2的幂，而64是最大的。
但有一个问题。这是怎么回事
系统仍然没有达成共识
像这样的编码技术很常见
utf - 8 ?
至少在网络上，他们大多是这样做的。大多数站点使用UTF-8。
在西方的问题是，有很多旧的软件，1字节= 1个字符，不能与UTF-8工作。
东方的问题在于他们对GB2312和Shift_JIS等编码的依赖。
事实上，微软似乎仍然没有从选择错误的UTF编码中恢复过来。如果您想使用Windows API或Microsoft C运行时库，则只能使用UTF-16或区域设置的“ANSI”编码。这使得使用UTF-8非常痛苦，因为您必须一直进行转换。
