base64

by 夏泽民 Aug 10, 2020

图片处理在前端工作中可谓占据了很重要的一壁江山。而图片的 base64 编码可能相对一些人而言比较陌生，本文不是从纯技术的角度去讨论图片的 base64 编码。标题略大，不过只是希望通过一些浅显的论述，让你知道什么是图片的 base64 编码，为什么我们要用它，我们如何使用并且方便的使用它，并让你懂得如何去在前端的实际工作中运用它。

什么是 base64 编码?　　

我不是来讲概念的，直接切入正题，图片的 base64 编码就是可以将一副图片数据编码成一串字符串，使用该字符串代替图像地址。

这样做有什么意义呢？我们知道，我们所看到的网页上的每一个图片，都是需要消耗一个 http 请求下载而来的（所有才有了 csssprites 技术的应运而生，但是 csssprites 有自身的局限性，下文会提到）。

没错，不管如何，图片的下载始终都要向服务器发出请求，要是图片的下载不用向服务器发出请求，而可以随着 HTML 的下载同时下载到本地那就太好了，而 base64 正好能解决这个问题。

那么图片的 base64 编码长什么样子呢？举个栗子。www.google.com 的首页搜索框右侧的搜索小图标使用的就是base64编码。我们可以看到：
//在css里的写法
#fkbx-spch, #fkbx-hspch {
background: url(data:image/gif;base64,R0lGODlhHAAmAKIHAKqqqsvLy0hISObm5vf394uLiwAAAP///yH5B…EoqQqJKAIBaQOVKHAXr3t7txgBjboSvB8EpLoFZywOAo3LFE5lYs/QW9LT1TRk1V7S2xYJADs=) no-repeat center;
}
//在html代码img标签里的写法

上面分别是图片的 base64 编码在 css 里面的写法和在 html 标签里的写法。base64 编码长得就是这个样子，当然 base64 编码不仅仅运用在图片编码，还可以：

thunder://QUFodHRwOi8vZG93bi5zYW5kYWkubmV0L3RodW5kZXI3L1RodW5kZXI3LjEuNS4yMTUyLmV4ZVpa（不要复制我我真的不是种子）

嘿嘿没错，迅雷的“专用地址”也是用 Base64 加密的，有兴趣自行 google，不做赘述。

为什么要使用 Base64 编码？　　

那么为什么要使用 base64 传输图片文件？上文也有提及，因为这样可以节省一个 http 请求。图片的 base64 编码可以算是前端优化的一环。效益虽小，但却缺能积少成多。

说到这里，不得不提的是 CssSprites 技术，后者也是为了减少 http 请求，而将页面中许多细小的图片合并为一张大图。那么图片的 base64 编码和 CssSprites 有什么异同，又该如何取舍呢？

所以，在这里要明确使用 base64 的一个前提，那就是被 base64 编码的图片足够尺寸小。以博客园的 logo 为例：

如图所示，博客园的 Logo 只有 3.27KB，已经很小了，但是如果将其制作转化成 base64 编码，生成的 base64 字符串编码足足有 4406 个,也就是说，图片被编码之后，生成的字符串编码大小一般而言都会比原文件稍大一些。即便 base64 编码能够被 gzip 压缩，压缩率能达到 50% 以上，想象一下，一个元素的 css 样式编写居然超过了 2000个字符，那对 css 整体的可读性将会造成十分大的影响，代码的冗余使得在此使用 base64 编码将得不偿失。

那么，是不是表示 base64 编码无用武之地呢？不然。当页面中的图片满足以下要求，base64 就能大显生手。

如果图片足够小且因为用处的特殊性无法被制作成雪碧图（CssSprites），在整个网站的复用性很高且基本不会被更新。

那么此时使用 base64 编码传输图片就可谓好钢用在刀刃上，思前想后，符合这个规则的，有一个是我们经常会遇到的，就是页面的背景图 background-image 。在很多地方，我们会制作一个很小的图片大概是几px*几px，然后平铺它页面当背景图。因为是背景图的缘故，所以无法将它放入雪碧图，而它却存在网站的很多页面，这种图片往往只有几十字节，却需要一个 http 请求，十分不值得。那么此时将它转化为 base64 编码，何乐而不为？

下面是一个只有 50 字节的2*2的的背景图。将其转化成 base64 编码，只有 100 多个字符，相比一个 http 请求，这种转换无疑更值得推崇。

CssSprites与Base64编码　　

简单陈述一下我对何时这使用这两种优化方法的看法。

使用CssSprites合并为一张大图：

页面具有多种风格，需要换肤功能，可使用CssSprites
网站已经趋于完美，不会再三天两头的改动（例如button大小、颜色等）
使用时无需重复图形内容
没有 Base64 编码成本，降低图片更新的维护难度。（但注意 Sprites 同时修改 css 和图片某些时候可能造成负担）
不会增加 CSS 文件体积
使用base64直接把图片编码成字符串写入CSS文件：

无额外请求
对于极小或者极简单图片
可像单独图片一样使用，比如背景图片重复使用等
没有跨域问题，无需考虑缓存、文件头或者cookies问题

更便捷的将图片转化为Base64编码　　

将图片转化为 base64 编码有许多工具，例如本文中我所使用的 http://www.pjhome.net/web/html5/encodeDataUrl.htm ，但是很多这些网站是国外网站，经常被墙登陆不了。这里介绍一个更为快捷的方法，就是利用 Chrome 浏览器（我想 FEer 都应该有Chrome 浏览器吧=。=）。

在 chrome 下新建一个窗口，然后把要转化的图片直接拖入浏览器，打开控制台，点 Source，如下图所示，点击图片，右侧就会显示该图片的 base64 编码，是不是很方便。

一些误区（2017.03.30更新）
Base64 虽有优点，但是缺点也很明显，在使用上存在一些明显的缺陷。

使用 Base64 不代表性能优化

是的，使用 Base64 的好处是能够减少一个图片的 HTTP 请求，然而，与之同时付出的代价则是 CSS 文件体积的增大。

而 CSS 文件体积的增大意味着什么呢？意味着 CRP 的阻塞。

CRP（Critical Rendering Path，关键渲染路径）：当浏览器从服务器接收到一个HTML页面的请求时，到屏幕上渲染出来要经过很多个步骤。浏览器完成这一系列的运行，或者说渲染出来我们常常称之为“关键渲染路径”。

通俗而言，就是图片不会导致关键渲染路径的阻塞，而转化为 Base64 的图片大大增加了 CSS 文件的体积，CSS 文件的体积直接影响渲染，导致用户会长时间注视空白屏幕。HTML 和 CSS 会阻塞渲染，而图片不会。

页面解析 CSS 生成的 CSSOM 时间增加
Base64 跟 CSS 混在一起，大大增加了浏览器需要解析CSS树的耗时。其实解析CSS树的过程是很快的，一般在几十微妙到几毫秒之间。

CSS 对象模型 (CSSOM)：CSSOM是一个建立在web页面上的 CSS 样式的映射，它和DOM类似，但是只针对CSS而不是HTML。

CSSOM 生成过程：

CSSOM 生成过程大致是，解析 HTML ，在文档的 head 部分遇到了一个 link 标记，该标记引用一个外部 CSS 样式表，下载该样式表后根据上述过程生成 CSSOM 树。这里我们要知道的是，CSSOM 阻止任何东西渲染，（意味着在CSS没处理好之前所有东西都不会展示），而如果CSS文件中混入了Base64，那么（因为文件体积的大幅增长）解析时间会增长到十倍以上。

而且，最重要的是，增加的解析时间全部都在关键渲染路径上。

所以，当我们需要使用到 Base64 技术的时，一定要意识到上述的问题，有取舍的进行使用。

https://www.cnblogs.com/coco1s/p/4375774.html

BASE64 搞出来的图片通常尺寸会大上 30% 左右。然而我认为这不是致命伤，用 BASE64 来传输图片最大的问题是，你之所以会这么用是因为你想以字符串来传输二进制。这个影响是很大的，尤其是你把它包进个什么 JSON 或者 XML 或者什么东西里。由于变成了需要解析的字符串对后端的压力会陡增，你可以明显看到处理速度的显著下滑。以及你还需要去调 nginx 配置文件以避免 nginx 觉得你字符串过长直接把包 Entity Too Large 拒掉。

https://gist.github.com/ghostcode/1f3c56d25417b30898e1

//获取数组最后一个元素
let hasFiles = files[Object.keys(files).pop()] // 参考上面的图片
let file = hasFiles.url
let name = hasFiles.file.name
let type = hasFiles.file.type

  function base64ToBlob(urlData, type) {

    let arr = urlData.split(',');

    let mime = arr[0].match(/:(.*?);/)[1] || type;

    // 去掉url的头，并转化为byte

    let bytes = window.atob(arr[1]);

    // 处理异常,将ascii码小于0的转换为大于0

    let ab = new ArrayBuffer(bytes.length);

    // 生成视图（直接针对内存）：8位无符号整数，长度1个字节

    let ia = new Uint8Array(ab);

    for (let i = 0; i < bytes.length; i++) {

      ia[i] = bytes.charCodeAt(i);

    }

    return new Blob([ab], {

      type: mime

    });

  }

  if (hasFiles.file.size > 1024 * 1024 * 10) {

    throw '文件超过10M'

  }

  let conversions = base64ToBlob(file, type)

  let param = new FormData()

  param.append('file', file, name)

  param.append('chunk', '0')

https://segmentfault.com/q/1010000012560812

什么是 base64 编码?　　

我不是来讲概念的，直接切入正题，图片的 base64 编码就是可以将一副图片数据编码成一串字符串，使用该字符串代替图像地址。

那么图片的 base64 编码长什么样子呢？举个栗子。www.google.com 的首页搜索框右侧的搜索小图标使用的就是base64编码。我们可以看到：

https://img4.sycdn.imooc.com/5ae2cb740001c75408390208.jpg

https://img4.sycdn.imooc.com/5ae2cb780001b0ee04410085.jpg

//在css里的写法
#fkbx-spch, #fkbx-hspch {
background: url(data:image/gif;base64,R0lGODlhHAAmAKIHAKqqqsvLy0hISObm5vf394uLiwAAAP///yH5B…EoqQqJKAIBaQOVKHAXr3t7txgBjboSvB8EpLoFZywOAo3LFE5lYs/QW9LT1TRk1V7S2xYJADs=) no-repeat center;
}
//在html代码img标签里的写法

上面分别是图片的 base64 编码在 css 里面的写法和在 html 标签里的写法。base64 编码长得就是这个样子。

为什么要使用 Base64 编码？　　

所以，在这里要明确使用 base64 的一个前提，那就是被 base64 编码的图片足够尺寸小。以博客园的 logo 为例：

那么，是不是表示 base64 编码无用武之地呢？不然。当页面中的图片满足以下要求，base64 就能大显生手。

如果图片足够小且因为用处的特殊性无法被制作成雪碧图（CssSprites），在整个网站的复用性很高且基本不会被更新。

下面是一个只有 50 字节的2*2的的背景图。将其转化成 base64 编码，只有 100 多个字符，相比一个 http 请求，这种转换无疑更值得推崇。

CssSprites与Base64编码　　

简单陈述一下我对何时这使用这两种优化方法的看法。

使用CssSprites合并为一张大图：

页面具有多种风格，需要换肤功能，可使用CssSprites

网站已经趋于完美，不会再三天两头的改动（例如button大小、颜色等）

使用时无需重复图形内容

没有 Base64 编码成本，降低图片更新的维护难度。（但注意 Sprites 同时修改 css 和图片某些时候可能造成负担）

不会增加 CSS 文件体积

使用base64直接把图片编码成字符串写入CSS文件：

无额外请求

对于极小或者极简单图片

可像单独图片一样使用，比如背景图片重复使用等

没有跨域问题，无需考虑缓存、文件头或者cookies问题

更便捷的将图片转化为Base64编码　　

一些误区
Base64 虽有优点，但是缺点也很明显，在使用上存在一些明显的缺陷。

使用 Base64 不代表性能优化

是的，使用 Base64 的好处是能够减少一个图片的 HTTP 请求，然而，与之同时付出的代价则是 CSS 文件体积的增大。

而 CSS 文件体积的增大意味着什么呢？意味着 CRP 的阻塞。

页面解析 CSS 生成的 CSSOM 时间增加
Base64 跟 CSS 混在一起，大大增加了浏览器需要解析CSS树的耗时。其实解析CSS树的过程是很快的，一般在几十微妙到几毫秒之间。

CSS 对象模型 (CSSOM)：CSSOM是一个建立在web页面上的 CSS 样式的映射，它和DOM类似，但是只针对CSS而不是HTML。

CSSOM 生成过程：

而且，最重要的是，增加的解析时间全部都在关键渲染路径上。

所以，当我们需要使用到 Base64 技术的时，一定要意识到上述的问题，有取舍的进行使用。

http://www.imooc.com/article/27804

1.主要：减少了HTTP请求

我们都知道，我们的网站采用的都是HTTP协议，而HTTP协议是一种无状态的链接，就是连接和传输后都会断开连接节省资源。此时解决的方法就是尽量的减少HTTP请求，此时base64编码可以将图片添加到css中，实现请求css即可下载下来图片，减少了在此请求图片的请求。当然减少HTTP请求次数的方法还有很多，如css sprite技术，将网页中的小图片拼在一张大图片中，下载时只需要一次完整的HTTP请求就可以，减少了请求次数。

2、提前加载图片的应用

这个大家可以去看一下天猫主页的css代码，大家可能没注意到，在我们使用网速不好时候的网络去访问天猫的时候，在页面没有完全加载出来的时候就会出现一个“小猫”的等待图标，增加了用户体验。其实现的原理就是将那张图片使用base64编码放到css中，因为我们都知道，css是在html头部引用的，要优先于下面的内容被加载，所以在网速不好的时候就会出现这种效果。
https://developer.qiniu.com/kodo/kb/1326/how-to-upload-photos-to-seven-niuyun-base64-code
https://tool.chinaz.com/tools/imgtobase

https://www.matools.com/image-base64

https://www.zhihu.com/question/36306744

作者：老鸟python
链接：https://www.zhihu.com/question/36306744/answer/931187310
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

我们知道在计算机中任何数据都是按字节存储的，有的复杂的数据（比如汉字）可能由多个字节表示，简单（比如单个英文字符）的由 1 个字节表示，字节是内存中基本的存储单位。我们知道一个字节可表示的范围是 0 ～ 255（十六进制：0x00 ～ 0xFF），其中 ascii 值的范围为 0 ～ 127（十六进制：0x00 ～ 0x7F）；而超越 ascii 范围的 128～255（十六进制：0x80 ～ 0xFF）之间的值是不可见字符。当然也并不是所有的 ascii 都是可见的，ascii 中只有 95 个可见字符（范围为 32 ～ 126），其余的 ascii 为不可见字符，本节后面我们会列出所有可见的 ascii 和不可见的 ascii。当不可见字符在网络上传输时，比如说从 A 计算机传到 B 计算机，往往要经过多个路由设备，由于不同的设备（特指老的路由设备）对字符的处理方式有一些不同，这样那些不可见字符就有可能被处理错误，这是不利于传输的。所以就先把数据先做一个 base64 编码，统统变成可见字符，也就是 ascii 码可表示的可见字符，确保数据可靠传输。base64 的内容是有 0 ～9，a ～z，A ～Z，+，/组成，正好 64 个字符，这些字符是在 ascii 可表示的范围内，属于 95 个可见字符的一部分。对于现在路由设备，只要是文本字符（无论是否是可见字符）都可以直接在网络上传输。注意，由于二进制格式的数据（图片，音频，视频，语音等非文本字符），无法直接在网络上传输，我们一般都要把这些二进制数据转为文本字符后进行网络传输。而 base64 可以把这些二进制数据转为文本字符，并且 base64为了兼容早期的老的路由器，还转化为了可见的文本字符，当然，对于现在的路由器来说，只要是文本字符就可以通过网络传输。在企业开发中，我们只要遵守一个好的习惯就可以了：对于文本字符传输，我们先序列化，然后再通过网络发送；对于二进制数据（图片，音频，视频，语音等非文本字符），我们先用 base64 编码成文本字符，然后序列化后再通过网络发送。大家可能要问，只要是文本字符不就可以直接通过网络传输了吗，为什么还要序列化？在此，我再告诉大家，你项目中要传输的数据不只有字符串吧，应该还需要包容其它类型的数据，通信双方约定的就是发送的东西都是序列化后数据，这样方便对通信双方的数据类型进行还原。你没必要只对其它类型的数据序列化，对字符串不序列化，这样反而增加了业务逻辑。base64 的使用base64 是 Python 内建模块，我们只需要 import 导入模块就可以使用，我们可以把超越 ascii 范围的字符用 base64 编码为可见字符。import base64

mystr = b”\x80” # \x80 换成十进制为 128，超越了 ascii 范围，为不可见字符
strb64 = base64.b64encode(mystr) # 编码为 base64 的可见字符
print(strb64)

mystr = base64.b64decode(strb64)
print(mystr) # 解码为不可见字符 \x80base64 自己有一套算法可以把我们的字符编码成 ascii 范围内的字符，当然它不关心我们给的字符是不是可见字符，如果是可见字符同样要编码，如果是不可见字符则会编码成可见字符。import base64

strone = “p”.encode(“utf8”) # 可见字符
strtwo = “鸟”.encode(“utf8”) # 不可见字符

print(base64.b64encode(strone)) # 编码可见字符
print(base64.b64encode(strtwo)) # 编码不可见字符为可见字符base64 编码会把 3 字节的二进制数据编码为 4 字节的文本数据，如果要编码的二进制数据不是 3 的倍数，最后会剩下 1 个或 2 个字节，base64 会在编码的末尾加上 1 个或 2 个 = 号，表示补了多少字节，解码的时候，会自动去掉。import base64

strone = “p”.encode(“utf8”) # 1个字节
strtwo = “py”.encode(“utf8”) # 2 个字节
strthree = “pyt”.encode(“utf8”) # 3 个字节
strfour = “pyth”.encode(“utf8”) # 4 个字节
strfive = “pytho”.encode(“utf8”) # 5 个字节
strsix = “python”.encode(“utf8”) # 6 个字节
strseven = “老鸟”.encode(“utf8”) # utf-8 编码，每个汉字一般占 3 个字节
streight = “老鸟python”.encode(“utf8”) # utf-8 编码，每个汉字一般占 3 个字节，英文占 1 个字节

print(base64.b64encode(strone)) # 按 3 个字节（缺 2 个，补齐 2 个 =）编码成 4 个字节 cA==
print(base64.b64encode(strtwo)) # 按 3 个字节（缺 1 个，补齐 1 个 =）编码成 4 个字节 cHk=
print(base64.b64encode(strthree)) # 按 3 个字节编码成 4 个字节 cHl0
print(base64.b64encode(strfour)) # 按 6 个字节（缺 2 个，补齐 2 个 =）编码成 8 个字节 cHl0aA==
print(base64.b64encode(strfive)) # 按 6 个字节（缺 1 个，补齐 1 个 =）编码成 8 个字节 cHl0aG8=
print(base64.b64encode(strsix)) # 按 6 个字节编码成 8 个字节 cHl0aG9u
print(base64.b64encode(strseven)) # 按 6 个字节编码成 8 个字节 6ICB6bif
print(base64.b64encode(streight)) # 按 12 个字节编码成 16 个字节 6ICB6bifcHl0aG9u我们可以对用 base64 编码后的字符进行解码。import base64

strone = “python”.encode(“utf8”) # 可见字符
strtwo = “老鸟”.encode(“utf8”) # 不可见字符

dataone = base64.b64encode(strone) # 编码可见字符 “python”
datatwo = base64.b64encode(strtwo) # 编码不可见字符 “老鸟” 为可见字符

print(base64.b64decode(dataone)) # 解码 base64 编码后的字符串
print(base64.b64decode(datatwo)) # 解码 base64 编码后的字符串由于 base64 编码后可能出现字符 + 和 /，在网页上传输数据，我们用 get 方式传输字符串时，字符 + 和 / 在 URL 中有特殊用途，就不能直接作为参数，所以又有一种 “url safe” 的 base64 编码，其实就是把字符 + 和 / 分别变成 - 和 _。import base64

mystr = b”\xfb\xef\xff”
print(base64.b64encode(mystr)) # 编码为 ++//，但是 + 和 / 在 url 中有特殊用途，不能作为参数
print(base64.urlsafe_b64encode(mystr)) # 编码为 –__，很好。在互联网上传输图片，音乐，视频，语音等等这些二进制数据是常用的需求，我们可以用 base64 把这些二进制数据转为文本字符进行网络传输。本节开头部分，我们说过，最好要对文本字符进行序列化后再进行网络传输。所以，正规的流程是首先需要先用 base64 把图片数据编码为文本字符，然后序列化，最后通过网络发送出去；另一端机器拿到这些数据，先进行反序列化，然后用 base64 进行解码还原。# coding:utf-8
import base64
import json

f = open(“d:/test.png”, “rb”) # 确保你计算机中存在 d:/test.png
imgdata = f.read() # 二进制图片数据
f.close()

imgdatab64 = base64.b64encode(imgdata)
print imgdatab64 # 我们发现都被编码成了 base64 的可见文本字符
jsdata = json.dumps(imgdatab64)

’’’
通过网络传输……，
对方机器收到后，先反序列化，最后用 base64 进行解码
‘’’

jsdata_recv = jsdata
imgdatab64 = json.loads(jsdata_recv)
imgdata = base64.b64decode(imgdatab64)注意：base64 仅仅是把二进制数据安装一定的算法转化为 ascii，但不要作为加密行为。

https://www.zhihu.com/question/36306744

https://www.jianshu.com/p/4f4e7288c90e

Category algorithm