Base64转图片工具 - 解码Data URI并保存文件

不必。带前缀粘贴或不带前缀粘贴都可以。前缀属于data URI语法的一部分，而不属于被编码的图片，它的作用是告诉浏览器该如何解读后面的载荷。如果有前缀，本工具会读出来并告诉您它声称的是什么；如果没有，也不会丢失任何信息，因为无论如何格式都是从解码后的字节判断出来的。

因为前缀是文本，不是数据。任何人都可以在PNG字节前面敲上`data:image/jpeg;base64,`，而且不少生成程序确实会不小心这么干——套用了模板、把MIME类型写死了，或者图片重新导出后仍沿用旧字符串。轻信它的结果，是给您存下一个任何JPEG解码器都打不开的.jpg文件。本工具改为读取开头的字节，当两者冲突时会明确指出，并按字节来命名文件。

几乎总是因为复制不完整。长data URI动辄几万个字符，一段停在视口边缘的选区、一个自动换行并插入了反斜杠的终端、一个每行开头都加了加号的diff视图，都会产生无法解码的字符串。其他常见原因还有：HTML实体&没有还原成&，以及用-和_代替+和/的URL安全变体——后者必须先转换才能解码。

没有。格式化工具和压缩工具的输出经常把长data URI折行，邮件客户端还会在76个字符处硬换行。空白字符不属于Base64的一部分，所以解码前会被清除。您也可以把周围的语法一起原样粘贴——整段`background-image: url("data:…");`声明、一个`img src="…"`标签，或者一个加了引号的JSON字符串——载荷会从里面提取出来。

完全不会。Base64是一种可逆编码，既不是压缩，也不是重新编码。解码出的字节和当初被编码的那个文件完全相同，包括EXIF元数据、ICC色彩配置文件和任何内嵌缩略图。如果结果看起来比您预期的差，那损失发生在编码之前——例如图片本来就是以低质量JPEG保存的，或者事先被缩小过。

可以。SVG是XML，没有二进制签名，所以要靠它的标记来识别：解码后的文本必须以一个标签开头，并且在跳过XML声明或注释之后，靠前的位置要出现一个`svg`元素。它会以.svg下载，可以用文本编辑器打开。反方向也值得一提：SVG本身就是文本，把它编码成Base64只会白白让体积增加约三分之一。

PNG、JPEG、GIF、WebP、AVIF、BMP、ICO和SVG，各自依据文件开头的签名判断。如果Base64能干净地解码，却对不上其中任何一种，您会看到一条明确的提示而不是下载——那通常意味着载荷是PDF、字体、zip包，或者恰好被Base64编码过的纯文本。

不会。解码就是本页面里运行的几行JavaScript：字符串留在标签页的内存中，图片预览是本地创建的blob URL，下载文件在您的设备上生成。这里没有任何服务端组件，没有携带载荷的请求，断网之后页面照样能用。这一点在这里格外重要，因为被粘贴进来的data URI往往是来自私密场合的截图、扫描件或文档。