C语言打开文件的模式
这篇讲的是作者在处理BMP图像文件时遇到的一个经典坑。他在编写一个读取并保存BMP文件的程序时，发现输出的文件总比原文件大3个字节，而且图像内容完全错乱。问题出在哪里呢？ 经过排查，根源在于打开文件时使用了`fopen(filename,"r+")`这种默认的文本模式。在文本模式下，C语言的文件读写会进行换行符（`\n`）与“回车+换行”（`\r\n`）的自动转换。而BMP文件作为二进制文件，其数据流中恰好包含十六进制值`0a`（等于换行符的ASCII码），这个值在颜色表中出现了三次。结果，每次读取时程序都把`0a`误当作换行符并扩展成两个字节，导致数据读取溢出；写回时又将两字节序列压缩为一字节，最终使得文件大小永久性地多出了3个字节，破坏了图片结构。 解决方法非常直接：将文件打开模式改为二进制模式`"wb"`。这个小bug提醒我们，只要操作的不是纯文本文件，就必须明确使用二进制模式（如`"rb"`、`"wb"`），以避免底层编码转换带来的隐秘错误。
photoshop图像点运算算法揭秘
作者在做图像处理实验时遇到一个奇怪现象：用Photoshop对一张8bit BMP图片调整亮度和对比度后，其直方图竟然没有变化。通过对比十六进制数据，他发现PS并未修改像素值，甚至图片大小只增加了两个字节的尾部填充。进一步检查调色板数据才揭示关键——Photoshop处理这类全局点运算时，实际操作对象是仅包含256项的颜色表，而非每个像素。这种“只改调色板”的做法大幅提升了处理效率，但对传统直方图读取程序则构成了隐蔽陷阱。 文章通过这个意外发现，细致拆解了PS的高效处理逻辑，并指出对于8bit图像，正确的读写函数必须重新适应调色板变化。对于24bit或32bit真彩色图像，这种方法并不适用。作者从一次实验异常出发，最终提炼出对算法优化的实际启发：一个巧妙的处理对象转换，往往能带来性能上的显著提升。