花了不少时间,修复了一个SharpIco生成图标的bug
SharpIco bug修好了?真把自己当回事了,高分辨率图片转ico就崩,这逻辑够清奇。原来是位深度闹的,24转32而已,用点真本事解决?
目录5 个章节
前言
上个月我用 dotnet9 AOT 开发了一个 ico 图标生成工具 SharpIco
这个实用小工具一经发布就受到不少朋友的关注
最近还被做成了网站,有图形化界面来一键生成 ico 图标,更方便普通用户的使用
出现问题
不过有网友在 issues 反馈了问题 「高分辨率图片在转换完成后,图片会损坏导致无法打开」

我测试了一下确实会这样
这个就很诡异了
看代码也可以发现,每个尺寸的图片都是通过 Resize 出来的
这样的话,无论输入的图片是多大的,最终都会缩小成几个指定的尺寸
using var original = Image.Load(sourcePng);
foreach (var size in sizes) {
using var clone = original.Clone(ctx => ctx.Resize(size, size));
using var ms = new MemoryStream();
clone.SaveAsPng(ms);
images.Add(ms.ToArray());
}
而且生成的 ico 并不是真正的损坏,在 Photoshop 里还是能打开的,只不过在系统的图片应用打开看不了,而且也无法正确解析图片元数据
排查问题
起初我求助于大模型爷爷(Claude4)
不过给我的几个方案都没啥用
要不就是叫我低于 256 分辨率使用 BMP 保存
然后还得写入 BIP 头什么的乱七八糟的,麻烦得一批
最后还得是我自己仔细观察
写入每张图片的代码是这样的
foreach (var image in images) {
using var ms = new MemoryStream(image);
using var img = Image.Load(ms);
writer.Write((byte)(img.Width == 256 ? 0 : img.Width)); // width
writer.Write((byte)(img.Height == 256 ? 0 : img.Height)); // height
writer.Write((byte)0); // colors in palette
writer.Write((byte)0); // reserved
writer.Write((ushort)1); // color planes
writer.Write((ushort)32); // bits per pixel
writer.Write(image.Length); // size of image data
writer.Write(offset); // offset of image data
offset += image.Length;
}
其中有一行 writer.Write((ushort)32); // bits per pixel 这个代表了图片的颜色位深度
一般来说 ICO 支持的常见位深度有:
- 1 bit(黑白)
- 4 bit(16 色)
- 8 bit(256 色)
- 24 bit(真彩色)
- 32 bit(真彩色 + Alpha)
我们的代码这里直接使用了 32 位色彩
而我发现那些转换出来无法解析的图片,都是 24 位色彩的
那么到这里就破案了
就是位深度不匹配的问题
解决方法
那么如何解决呢?
一开始我尝试在 clone 不同大小的图片时加上透明背景色
using var clone = original.Clone(ctx => {
ctx.Resize(size, size);
ctx.BackgroundColor(Color.Transparent); // 保证有 alpha 通道
});
然后很遗憾的是,没有效果
感觉可能是原始图片没有 alpha,ImageSharp 仍然用 RGB 来保存 PNG,导致保存出的 PNG 是 24-bit
而 ICO 写的 header 是 32-bit,导致无法解析
最终的解决方法是
foreach (var size in sizes) {
using var clone = original.Clone(ctx => ctx.Resize(size, size));
using var ms = new MemoryStream();
// 强制图像为 Rgba32 格式,确保是 32-bit
var rgbaImage = clone.CloneAs<Rgba32>();
rgbaImage.SaveAsPng(ms);
images.Add(ms.ToArray());
}
使用 clone.CloneAs<Rgba32>(); 强制转换图片位 32 位色彩
之后我测试了大部分图片都没问题了~
小结
我以为只要熟悉了ico文件格式的规范就足够了
没想到这只是个开始
图像处理领域还是有很多坑的
难怪大部分工具都选择使用 Magick 这类老牌成熟的图像处理库来实现这个功能
手写的话一不小心就踩坑了~ 还要花大量时间去排查问题
_EOF_
花了不少时间,修复了一个SharpIco生成图标的bug
- 本文作者:
- 程序设计实验室
- 版权声明:
- 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
相关文章
C#移除字符串中的不可见Unicode字符
背景 最近发现某个数据采集的系统拿下来的数据,有些字段的JSON被莫名截断了,导致后续数据分析的时候解析JSON失败。 类似这样 {title: 你好 或者这样,多了个双引号啥的 {title:你好} 因为数据库是Oracle,起初以为是Oracle这老古董出问题了,结果一番折腾,把每条写入数据的SQL语句都拿出来,看起来里面的JSON格式都没问题。 这也太诡异了吧,看起来没毛病,但就为啥JSON
2023-02-02 · C# · 约 1 分钟
让 C# 也拥有 gofmt 般的体验:用 CSharpier + Roslyn 实现 csfmt
C# 代码长到像答辩?用 CSharpier 自动折行,再用 Roslyn 修正 K&R 花括号,Taskfile 一键收尾。再补上 format-check,省得 CI 反复制造 Git diff。两步流水线并非原生 gofmt,顺序和版本仍得老实锁住。
2026-10-22 · C# · 约 1 分钟
使用C#和MemoryCache组件实现轮流调用APIKey以提高并发能力
本文介绍了如何利用C#语言中的MemoryCache组件,结合并发编程技巧,实现轮流调用多个API Key以提高系统的并发能力。通过示例代码和详细说明,读者将了解如何有效地管理API Key的调用次数限制,并优化系统性能。
2024-03-09 · C# · 约 1 分钟
在.NetCore(C#)中使用ODP-NET-Core+Dapper操作Oracle数据库
前言 虽然一直在说“去IOE化”,但是在国企和政府,Oracle的历史包袱实在太重了,甚至很多业务逻辑都是写在Oracle的各种存储过程里面实现的…… 我们的系统主要的技术栈是Django / Spring / AspNetCore,Java的不必说对Oracle支持肯定没问题,关键在于Django对Oracle版本有要求,兼容性不是特别好,Oracle版本没办法随意升级的,所以我想到用.Net
2021-12-18 · C# · 约 1 分钟
讨论
共 0 条加载评论中…