base64 编码知识，一文打尽！

现在网站为了提升用户的浏览体验越来越多的使用了图片，而这些图片通常以 base64 的形式存储和加载。因此各位开发工程师肯定对 base64 毫不陌生了，那么你知道 base64 究竟是什么，为什么要使用 base64，以及 base64 的优缺点吗？

base64 是网络中存储和传输的二进制数据的普遍用法。base64 一个字节只能表示 64 种情况，且编码格式每个字节的前两位都只能是 0，使用剩下的 6 位表示内容。

看到这里相信大家也能够意识到，这种编码格式无法充分利用存储资源，效能较低。那为什么还会成为网络中的普遍用法呢？

其实 base64 最早是应用在邮件传输协议中的。当时邮件传输协议只支持 ASCII 字符传递，使用 ASCII 码来表示所有的英文字符和数字还有一些符号。这里有一个问题，如果邮件中只传输英文数字等，那么 ASCII 可以直接支持。但是如果要在文件中传输图片、视频等资源的话，这些资源转成 ASCII 的时候会出现非英文数字的情况。而且邮件中还存在很多控制字符，这些控制字符又会成为不可见字符。非英文字符和控制字符在传输过程中很容易产生错误，影响邮件的正确传输。为此才有了诞生了一个新的编码规则，把二进制以 3 个字节为一组，再把每组的 3 个字节（24 位）转换成 4 个 6 位，每 6 位根据查表对应一个 ASCII 符号，这就是 base64。

base64 将 8 位为一个单元的字节数据，拆分为 6 位为一个单元的二进制片段。每一个 6 位单元对应 base64 索引表中的一个字符。简单举个例子，下图中 M 的 ASCII 码是 77 , 而转换为二进制后前六位二进制对应值为 19，为 base64 字典中的 T。

当然这里也会有一个问题，如果要编码的二进制数据不是 3 的倍数，那就会剩下一至二个字节。为此 base64 使用 000000 字节值在末尾补足，使其字节数能够被 3 整除，补位用 = 表示，= 的个数可表示补了多少字节，并在解码时自动去除。总体来看相比编码前，base64 编码后的字符增加了约 33%。

前面我们也提到了 base64 编码是现在网站小图片的主要加载方式，那 base64 到底是如何处理图片的呢？

我们都知道图片在网页中的使用方法通常是使用 img 标签的形式，而 img 标签的 src 属性会指定一个远程服务器上的资源。在网页加载到浏览器中时，浏览器会针对每个外部资源都向服务器发送一次拉取资源请求。但是这是非常占用网络资源的，而且因为大多数浏览器都有并发请求数的限制，如果你的网页中嵌入了过多外部请求，就很容易出现页面加载速度过慢的情况。

而 base64 编码可以通过 Data URL 技术让图片以字符串的格式直接嵌入页面，与 HTML 成为一体。这样在加载时就可以避开对外部资源的请求

为什么选择 Data URL

至于为什么选择 Data URL 技术，是因为跟传统的外部资源引用方式相比，它拥有以下优点：

通过这种方式 base64 编码可以更为快捷方便得对前端的各种图片资源进行优化。我们看一个具体的例子：

可以明显看到 base64 编码将一幅图片数据编码成一串字符串，并使用该字符串代替图像地址。尽管乍一眼看上去没有任何图片相关的内容，但它最终渲染出的毫无疑问是一张完整的图片效果。

当然使用 Data URL 来进行 base64 图片编码并不是完美的，它有着两个不容忽视的缺点：

无法被浏览器缓存也就意味着每次访问都需要重新请求资源，这对于服务器压力是比较大的。那有没有办法，能将这些数据也放入浏览器缓存中呢？

加快加载小技巧

其实大部分网站的背景图构成，是一个宽高只有几个像素的小图片，通过将它平铺成为背景图。通常我们将小图片保存成 GIF 或 PNG 格式，然后在 CSS 的 background-image 属性中引用图片地址。但是浏览器本身并不在意 URL里写的是什么，只是需要通过它获取需要的数据。

所以我们完全可以使用 CSS 样式文件，让 Data URL 形式的图片存储在 CSS 样式表中。这样浏览器就会缓存 CSS 文件，也就会缓存图片，能够进一步提高页面加载效率。

上图就是一个简单的使用案例，通过这种方式既避免了让背景图片独自产生一次 HTTP 请求的情况，还让背景图片和 CSS 文件一起被浏览器缓存起来，避免了每次打开网页都加载一次背景图片的情况，让改善用户的浏览体验更为快速流畅。

通过 Date URL 技术与 base64 编码的结合有效减少 HTTP 请求，让用户访问体验更好，这其实是我们一个开发过程中的小技巧，希望看完后能够带给大家一些帮助。

base64介绍

base64是一种基于64个可打印字符来表示二进制数据的表示方法。由于2的6次方等于64，所以每6个比特为一个单元，对应某个可打印字符。三个字节有24个比特，对应于4个base64单元，即3个字节可表示4个可打印字符。在base64中的可打印字符包括字母A-Z、a-z、数字0-9，这样共有62个字符，以及加号“+”，斜杠“/”，一共64个字符，等号“=”用来作为后缀用途。

base64常用于在通常处理文本数据的场合，表示、传输、存储一些二进制数据，完整的base64定义可见RFC 1421和RFC 2045。编码后的数据比原始数据略长，为原来的4/3(在电子邮件中，根据RFC 822规定，每76个字符，还需要加上一个回车换行。可以估算编码后数据长度大约为原长的135.1%)

计算机中任何数据都是按ascii码存储的，而ascii码的128～255之间的值是不可见字符。而在网络上交换数据时，比如说从A地传到B地，往往要经过多个路由设备，由于不同的设备对字符的处理方式有一些不同(如:有些字符被当作控制字符处理掉了，例如传统的邮件只支持可见字符的传送，像ASCII码的控制字符就 不能通过邮件传送)，这样那些不可见字符就有可能被处理错误，这是不利于传输的。***的方法就是在不改变传统协议的情 况下，做一种扩展方案来支持二进制文件的传送。把不可打印的字符也能用可打印字符来表示，问题就解决了，base64编码应运而生，base64就是一种 基于64个可打印字符来表示二进制数据的表示方法。

什么是base64编码？

base64是网络上最常见的用于传输8Bit字节代码的编码方式之一，在发送电子邮件时，服务器认证的用户名和密码需要用base64编码，附件也需要用base64编码。

下面简单介绍base64算法的原理，由于代码太长就不在此贴出

base64要求把每三个8Bit的字节转换为四个6Bit的字节（3*8 = 4*6 = 24），然后把6Bit再添两位高位0，组成四个8Bit的字节，也就是说，转换后的字符串理论上将要比原来的长1/3。

转换后，我们用一个码表来得到我们想要的字符串（也就是最终的base64编码），这个表是这样的：

0 A 17 R 34 i 51 z

1 B 18 S 35 j 52 0

2 C 19 T 36 k 53 1

3 D 20 U 37 l 54 2

4 E 21 V 38 m 55 3

5 F 22 W 39 n 56 4

6 G 23 X 40 o 57 5

7 H 24 Y 41 p 58 6

8 I 25 Z 42 q 59 7

9 J 26 a 43 r 60 8

10 K 27 b 44 s 61 9

11 L 28 c 45 t 62 +

12 M 29 d 46 u 63 /

13 N 30 e 47 v

14 O 31 f 48 w (pad) =

15 P 32 g 49 x

16 Q 33 h 50 y

原文的字节最后不够3个的地方用0来补足，转换时base64编码用=号来代替。这就是为什么有些base64编码会以一个或两个等号结束的原因，但等号最多只有两个。

举一个例子，abc经过base64编码以后的结果是YWJj.

发邮件的时候所写的信息自动在后台转换然后传输...

参考资料：

base64编码是什么意思？

base64是网络上最常见的用于传输8Bit字节码的编码方式之一，base64就是一种基于64个可打印字符来表示二进制数据的方法。

base64编码是从二进制到字符的过程，可用于在HTTP环境下传递较长的标识信息。采用base64编码具有不可读性，需要解码后才能阅读。

base64由于以上优点被广泛应用于计算机的各个领域，然而由于输出内容中包括两个以上“符号类”字符（+, /, =)，不同的应用场景又分别研制了base64的各种“变种”。为统一和规范化base64的输出，base62x被视为无符号化的改进版本。

base64编码可用于在HTTP环境下传递较长的标识信息。例如，在Java Persistence系统Hibernate中，就采用了base64来将一个较长的一个标识符（一般为128-bit的UUID）编码为一个字符串，用作HTTP表单和HTTP GET URL中的参数。

在其他应用程序中，也常常需要把二进制数据编码为适合放在URL（包括隐藏表单域）中的形式。此时，采用base64编码不仅比较简短，同时也具有不可读性，即所编码的数据不会被人用肉眼所直接看到。

然而，标准的base64并不适合直接放在URL里传输，因为URL编码器会把标准base64中的“/”和“+”字符变为形如“%XX”的形式，而这些“%”号在存入数据库时还需要再进行转换，因为ANSI SQL中已将“%”号用作通配符。

为解决此问题，可采用一种用于URL的改进base64编码，它不仅在末尾去掉填充的'='号，并将标准base64中的“+”和“/”分别改成了“-”和“_”，这样就免去了在URL编解码和数据库存储时所要作的转换，避免了编码信息长度在此过程中的增加，并统一了数据库、表单等处对象标识符的格式。

另有一种用于正则表达式的改进base64变种，它将“+”和“/”改成了“!”和“-”，因为“+”,“/”以及前面在IRCu中用到的“[”和“]”在正则表达式中都可能具有特殊含义。

此外还有一些变种，它们将“+/”改为“_-”或“._”（用作编程语言中的标识符名称）或“.-”（用于XML中的Nmtoken）甚至“_:”（用于XML中的Name）。

base64用法和使用场景

base64最开始是邮件的协议出现的。

打开某个邮件的源文件，可以看到邮件的正文部分，使用了base64编码。

Content-Transfer-Encoding：base64

传统电子邮件协议，即RFC822。导致的问题：

电子邮件协议使用MIME（传统电子邮件一系列拓展协议）去拓展的这些功能。

这个编码带来的意义：

所有的二进制文件，都可以因此转化为可打印的文本编码，使用文本软件进行编辑。

使用场景：

1.前边提到的邮件算是一个

2.如果纯文本数据包含不可见字符，就需要使用base64，比如xml文件某节点数据包含可见字符，显示的话就是乱码，不能够编辑操作。使用base64编码后显示，需要还原的地方再解码。（二进制文件图片应用类似）

3.简单加密（所以看到字符串中包含大小写和等号，很可能就是base64编码）

字符集的历史：

文章写的很形象易懂

所有使用不同字符集编码，base64的结果是不同的。

unicode 是字符集，不是编码

utf-8是在unicode的基础上的编码

交换机的原理：

URL编码

网络标准[RFC 1738]做了硬性规定：

所以如果http传输URL中有汉字，就必须编码后使用。但是麻烦的是 标准的国际组织并没有规定具体的编码方法，而是交给应用程序（浏览器）自己决定。 这导致"URL编码"成为了一个混乱的领域。

所以上述两点是url编码的原因。

把要编码的字符转成16进制字符，前加%。所以看到很多%，就可以判断是url编码

参考：

base64算法原理及实现

base64算法最开始是被用于解决电子邮件数据传输问题。在早期，由于历史原因问题，电子邮件只允许使用ASCII字符，如果在邮件中出现了非ASCII字符，在通过某些网关进行数据转发的时候，网关会对这些非ASCII字符做出调整，例如，把ASCII码8位二进制码的***位置为0。此时接收方在收到邮件时就会出现乱码。基于这个原因，产生了base64算法。

base64编码的思路说白了，就是把传输数据的每个字节映射成ASCII码表中的某些字符，这样在传输的过程中，就不会出现乱码的问题了。base64算法定义了一个映射表，如下所示。

由上表可以看出，之所以称为base64编码，实际上是把原数据映射成了ASCII码表中的64个字符。但是，64个字符最多能映射的位数是6bit。但是每个数据是8bit的，那怎么转换呢？base64编码的基本思想： 将原数据每3个字节（24bit）分为一组，然后将这24bit数据按照每6bit一组，重新划分为4组，分组完成之后，再将每每6bit数据为单元进行映射。

base64编码的基本流程如下：

例如，将字符串"ABC"进行base64编码流程如下。

所以，字符串"ABC"经过base64编码后的数据是"QUJD"。

从base64编码的原理可以看到，base64实际上就是把原来数据中的每3个字节一组进行base64编码转换，编码之后变成4个base64字符。但是如果原文数据长度不是3的整数倍的时候该怎么办呢？base64算法规定，如果待加密数据不是3的整数倍，就在原文数据后面补0，直到长度凑够3的整数倍为止，然后再进行base64编码转换。待编码转换完成之后，在结果末尾补充相同个数的"="。

例如，将字符串"ABCD"进行base64编码流程如下。

所以，字符串"ABC"经过base64编码后的字符串是"QUJDRA=="。

其实这里有个规律，当原文的数据长度除以3余数为0时，编码之后后面没有"="；当余数为1时，后面有两个"="，当余数是2时，后面有一个"="，"="的个数也就是补充的字节数。

通过base64的原理可以看到，base64编码实际上是把原数据的3个字节映射成了4个字节，所以相比于原数据长度，编码后的长度会增加1/3。这也会降低传输效率。

Get方式和Post方式是Http请求常用的两种方式，某些情况下会要求使用Get方式来传递二进制数据。这时，可以先通过base64编码来将二进制数据转换成字符串数据。由于符号"+"和符号"/"是不允许出现在Url中的，所以，产生了Url安全的base64算法，所谓的Url安全的base64算法，其实主要包含两个方面。

目前，在Java中，我们可以通过以下方式来是使用base64算法。

在java8之前，JDK官方库中都没有内置base64算法，其实base64实现很简单，这个不知道为什么。但是Java8内置了base64编码器和解码器。

在Java8中，base64工具类提供了三种base64编解码器：

1.基本base64编码

也就是完全按照标准base64的映射规则来编解码，不添加任何行标。

2.Url base64编码

JDK标准类库中的Url base64编码是用"-"和"_"取代了"+"和"/"

3.MIME base64编码

Java类库中还提供了一种格式更友好的base64编码，这种编码输出每行不超过76字符，并且使用'r'并跟随'n'作为分割。

4.去除填充符的base64

在Java标准类库中，还提供了一种方式来去除编码末尾的"="，就是在构建Encoder 对象后调用withoutPadding()方法，例如：

Commons Codec是Apache为Java开发者提供的一个开源软件类库，该类库中主要是一些常用的编码工具类包，例如DES、SHA1、MD5、base64，URL等。在使用该类库之前需要首先在Eclipse中添加依赖。Commons Codec提供了以下base64编码方式。

1.基本base64编码

Commons Codec和Java标准类库提供给的base64编码方式是一样的。

2.Url base64编码

Url base64编码和Java类库也是一样的，把"+"和"/"替换成了"-"和"_"，有一个不同的地方是Commons Codec中的Url base64默认去掉了后面的"="，相当于Java类库中调用了withouPadding方法，例如：

3.类MIME格式输出

Commons Codec中也提供了类似于Java类库中的MIME的格式化输出，在Commons Codec中有一个方法：

这里的isChunked置为true，就表示是按照MIME格式输出编码结果。

h

关于base64和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。