【发布时间】:2017-06-07 09:30:53
【问题描述】:
我正在开发一个程序,该程序接受一个字符串,将字符串的每个字符转换为一种颜色,然后在图像上从左到右、自上而下绘制颜色。然后可以使用相同的程序对图像进行解码,以获取原始消息。例如,这里是clojure.core,编码为图像:
我只是把它写成一个玩具,但我注意到它产生的图像有一个有趣的特性:它们比作为文本的原始消息要小。对于clojure.core,它是 259kb 作为文本,但只有 88.9kb 作为图像(上图)(两个值都是“磁盘大小”)。为了确保数据不会丢失,我对图像进行了解码,并取回了原始消息。
这怎么可能?我认为图像(png 格式)会有标题和其他额外信息,会扩大尺寸。
整个clojure.core包含265486个字符(根据Notepad++),也就是说每个字符基本上占一个字节。
从使用 BufferedImage 类 (Java) 来看,颜色似乎存储为 4 字节整数,所以每个像素不应该需要大约 4 倍的内存吗?
这是它的编码方式:
字符串的第一个字符被弹出
通过获取它的 ASCII 值,将其乘以一个大数字(因此它更好地覆盖可能的颜色范围)将其转换为颜色,然后将该数字转换为 3 位,基数为 256 的数字(@ 987654329@)。
每个数字都被视为红色、绿色和蓝色通道,这些通道被赋予
BufferedImage的setRGB方法。position指示符前进,弹出下一个字符,并重复该过程,直到对整个消息进行编码。
算法现在有点复杂。 @Thumbnail 在 Code Review 上提出了一个更好的方法,但我还没有实现它。由于结果是相同的,所以这不应该对问题产生影响。
【问题讨论】:
-
尽管答案有些明显,但我仍然喜欢阅读您的发现。遇到这样的事情总是很有趣。
标签: encryption clojure compression bufferedimage