base64 压缩数据_base64中的未压缩数据？ 可能不是

base64 压缩数据

The beauty of experimentation is that failures are just as fun as successes. Warning: this post is about a failure, so you can skip it altogether 🙂

实验的好处在于失败和成功一样有趣。 警告：这篇文章是关于失败的，因此您可以完全跳过它🙂

The perf advent calendar was my attempt to flush out a bunch of stuff, tools and experiments I was doing but never had the time to talk about. I guess 24 days were not enough. Here's another little experiment I made some time ago and forgot about. Let me share before it disappears to nothing with the next computer crash.

性能出现日历是我试图清除我正在做的一堆东西，工具和实验，但是却没有时间谈论。 我想24天还不够。 这是我前段时间忘记的另一个小实验。 让我分享下一次计算机崩溃之前它消失不见的一切。

I've talked before about base64-encoded data URIs. I mentioned that according to my tests base64 encoding adds on average 33% to the file size, but gzipping brings it back, sometimes to less than the original.

我之前已经讨论过base64编码的数据URI 。 我提到过，根据我的测试，base64编码平均会增加文件大小的33％，但是gziping会将其恢复，有时会小于原始大小。

Then I saw a comment somewhere (reddit? hackernews?) that the content before base64-encoding better be uncompressed, because it will be gzipped better after that. It made sense, so I had to test.

然后，我在某处(reddit？hackernews？)看到一条评论，指出最好对base64编码之前的内容进行解压缩，因为在此之后它将更好地压缩。 这很有道理，所以我必须进行测试。

“哇，备份它……哔哔，哔哔，哔哔”( G.康斯坦萨) ("Whoa, back it up... beep, beep, beep" (G. Constanza))

When using data URIs you essentially do this:

在使用数据URI时，您基本上可以这样做：

1. take a PNG (which contains compressed data),
   提取一个PNG(包含压缩数据)，
2. base64 encode it
   base64对其进行编码
3. shove it into a CSS
   推入CSS
4. serve the resulting CSS gzipped (compressed)
   提供压缩后的结果CSS(压缩)

See how it goes: compress - encode - compress again. Compressing already compressed data doesn't sound like a good idea, so it sounds believable that skipping the first compression might give better results. Turns out it's not exactly the case.

看看情况如何：compress-编码-再次压缩。 压缩已经压缩的数据听起来并不是一个好主意，因此，听起来似乎可以相信，跳过第一次压缩可能会带来更好的结果。 事实并非如此。

未压缩的PNG？ (Uncompressed PNG?)

The PNG format contains information in "chunks". At the very least there's header (IHDR), data (IDAT) and end (IEND) chunks. There could be other chunks such as transparency, background and so on, but these three are required. The IDAT data chunk is compressed to save space, but it looks like it doesn't have to be.

PNG格式包含“块”中的信息。 至少有标头(IHDR)，数据(IDAT)和末尾(IEND)块。 可能还有其他块，例如透明度，背景等等，但是这三个是必需的。 IDAT数据块经过压缩以节省空间，但看起来并非必须如此。

PNGOut has an option to save uncompressed data, like $ pngout -s4 -force file.png

PNGOut可以选择保存未压缩的数据，例如$ pngout -s4 -force file.png

This is what I tried - took several compressed PNGs, uncompressed them (with PNGOut's -s4), then encoded both with base64 encoding, put them in CSS, gzip the CSS and compared file sizes.

这就是我尝试的方法-提取了多个压缩的PNG，将其解压缩(使用PNGOut的-s4)，然后使用base64编码对它们进行编码，将它们放入CSS中，gzip CSS并比较文件大小。

码 (Code)

<?php
// images to work with
$images = array(
  'html.png',
  'at.png',
  'app.png',
  'engaged.png',
  'button.png',
  'pivot.png'
);
//$images[] = 'sprt.png';
//$images[] = 'goog.png';
//$images[] = 'amzn.png';
//$images[] = 'wiki.png';
 
// css strings to write to files
$css1 = "";
$css2 = "";
 
foreach ($images as $i) {
  
  // create a "d" file, d as in decompressed
  copy($i, "d$i");  
  $cmd = "pngout -s4 -force d$i";
  exec($cmd);
  
  // selector
  $sel = str_replace('.png', '', $i);
 
  // append new base64'd image 
  $file1 = base64_encode(file_get_contents($i));
  $css1 .= ".$sel {background-image: url('data:image/png;base64,$file1');}\n";
  $file2 = base64_encode(file_get_contents("d$i"));
  $css2 .= ".$sel {background-image: url('data:image/png;base64,$file2');}\n";
 
}
 
// write and gzip files
file_put_contents('css1.css', $css1);
file_put_contents('css2.css', $css2);
exec('gzip -9 css1.css');
exec('gzip -9 css2.css');
 
?>

结果 (Results)

I tried to keep the test reasonable and used real life images - first the images that use base64 encoding in Yahoo! Search results. Then kept adding more files to grow the size of the result CSS - added Y!Search sprite, Google sprite, Amazon sprite and Wikipedia logo.

我试图保持测试的合理性并使用真实的图像-首先是在Yahoo!中使用base64编码的图像。 搜索结果。 然后继续添加更多文件以增大结果CSS的大小-添加了Y！Search Sprite，Google Sprite，Amazon Sprite和Wikipedia徽标。

test	with compressed PNG, bytes	with uncompressed PNG, bytes	difference, %
Y!Search images	700	1506	54%
previous + Y!Search sprite	5118	8110	36%
previous + Google sprite	27168	40836	33%
previous + Amazon sprite + Wikipedia logo	55804	79647	29%

测试	带有压缩的PNG，字节	使用未压缩的PNG，字节	区别， ％
Y！搜索图像	700	1506	54％
上一个+ Y！搜索精灵	5118	8110	36％
上一个+ Google Sprite	27168	40836	33％
上一页+ Amazon Sprite + Wikipedia徽标	55804	79647	29％

Clearly starting with compressed images is better. Looks like the difference becomes smaller as the file sizes increase, it's possible that for very big files starting with uncompressed image could be better, but shoving more than 50K of images inline into a CSS file seems to be missing the idea of data URIs. I believe the idea is to use data URIs (instead of sprites) for small decoration images. If an image is over 50K it better be a separate request and cached, otherwise s small CSS tweak will invalidate the cached images.

显然从压缩图像开始会更好。 看起来随着文件大小的增加，差异变得越来越小，对于以未压缩图像开头的超大文件来说可能会更好，但是将超过50K的图像内联到CSS文件中则似乎缺少了数据URI的想法。 我相信这个想法是将数据URI(而不是精灵)用于小型装饰图像。 如果图像超过50K，最好是单独请求并进行缓存，否则，较小CSS调整将使缓存的图像无效。

Tell your friends about this post on Facebook and Twitter

在Facebook和Twitter上告诉您的朋友有关此帖子的信息

翻译自: https://www.phpied.com/uncompressed-data-in-base64-probably-not/

base64 压缩数据