图片格式转换工具源码是一类服务端处理的格式互转工具：上传图片、选定目标格式、拿到新文件。它可读入 JPG、PNG、BMP、WEBP、TIFF、HEIC 六种来源，输出集中在 JPG、PNG、BMP、WEBP 四种，另有一页专门生成 ICO 图标。它解决的是「对方要什么格式」这类硬性适配问题。

图片格式转换工具源码是一类什么样的工具？

它是一组以「换格式」为唯一目的的页面。

八个转换页分成两类：一类是通用互转，可选输出四种格式；一类是定向转换，比如 HEIC 转 JPG、TIFF 转 JPG、图片转 JPG 等，这类页面没有参数栏，文件一上传成功就自动开始转换，不需要再点按钮。另有一页生成 ICO 图标，按 16 到 256 七档尺寸出一张图标。

它和在线图片压缩工具站源码里的压缩页共用同一套上传、列表与下载链路——差别只在底部参数栏：压缩页有策略要选，转换页没有。

为什么读入有六种、输出只有四种？

因为来源与去向承担的任务不同。

来源要尽量兼容：用户手里可能是 iPhone 拍的 HEIC、扫描仪出的 TIFF、老系统导出的 BMP，收不了就等于这个需求接不住，用户只能去别处。所以读入面要宽。

去向要能直接用：转换的意义是让文件在某个场合能打开、能上传、能被系统识别，格式越偏门，对方越可能打不开，转换就失去了意义。 所以输出面收窄到四种最常见、兼容性最好的格式，外加 ICO 这一种有明确专门用途的。

这不是能力不足，而是按使用场景做的取舍。

HEIC 与 TIFF 为什么只作为来源？

因为这两种格式适合存，不适合交。

HEIC 的优势是同等画质下体积小得多，代价是兼容性差——很多系统、很多软件并不认它，这正是大量用户需要把它转成 JPG 的原因。 TIFF 保留的信息更完整，常用于印刷与扫描归档，但体积大、传输与加载都慢，它是「留档用」的格式，不是「发出去」的格式。

这里还牵出一处实现细节：这两种格式浏览器普遍无法直接显示，如果列表里只放原图缩略图，用户看到的就是一个个破图。因此这类系统在上传时会额外生成一张 JPEG 预览图专供列表显示，原文件不动，只为「看得见」多生成一份。

六页「上传即转」为什么不需要参数？

因为格式转换本身没有可调的东西。

选定了目标格式，剩下的只是执行——不像压缩需要权衡体积与画质，转换在「换成什么」之外没有第二个变量。参数栏是给有取舍的地方用的。

而删除参数栏带来的是转化率的提升：用户上传完就已经在处理，不用再找按钮、不用判断选项。 与之配套的还有卡片形态的差异——压缩与编辑类用详情卡，显示原图与结果各自的格式、宽高与体积，方便对比；转换类用缩略网格，图片上悬停出现删除按钮，左上角标出输出格式或失败状态，因为转换不需要比体积，只需要看清「转成了什么」。

图标生成与格式转换有什么不同？

它多了一步「装进画布」。

源图未必是方的，而图标必须是正方形，所以生成 ICO 的做法是先把图片等比缩放进一块方形透明画布，再编码成图标文件。这一步决定了结果可能带透明边，也决定了非正方形源图不会被拉伸变形。

另一个差别是尺寸：转换页输出的是完整图片，图标页输出的是 16、24、32、48、64、128、256 中的某一档，一次只出一个尺寸。想要多尺寸套件，需要分别生成。

选型时优先核对哪几项？

四项。

其一，格式覆盖是否对得上使用场景。 尤其是 HEIC 与 TIFF 这两个高频来源有没有收。其二，前端与后端是否都做格式校验。 前者按页面声明拦截，后者按白名单复核，只做前端等于没做。 其三，输出文件的命名与体积是否正常。 单文件下载应保留原文件名、只换扩展名，输出体积也不该异常膨胀。其四，非主流格式能否正常预览。 列表里看得见，用户才敢确认自己选对了文件。

前两项决定能不能用，后两项决定用起来顺不顺。若还要顺带压缩与尺寸调整，在线图片处理工具源码给的是纯前端路线的另一种取舍。