mirai
mirai copied to clipboard
mamoe
add: ImageType.JPEG
有些时候文件的后缀命名是 jpeg，还有就是 http header 中 jpg 图片 的 Content-Type 一般是 image/jpeg，
这里是希望，对于 jpeg 不用处理直接 可以作为 formatName 参数
那应该为 JPG 添加 secondaryNames 比较好
这里我参考的是对 APNG 的处理
https://github.com/mamoe/mirai/blob/d8def8e6623611126b128a13db4a1e754e96cab8/mirai-core-api/src/commonMain/kotlin/message/data/Image.kt#L380
https://github.com/mamoe/mirai/blob/d8def8e6623611126b128a13db4a1e754e96cab8/mirai-core/src/commonMain/kotlin/message/ImageDecoder.kt#L158
可考虑弃用原 APNG 然后实现我上面提议的新方案 @Karlatemp 你觉得呢
这不可行，APNG 并不是 PNG 的 alternative name，而是另一种基于PNG的扩展标准，在协议中也使用单独的format id
这里我参考的是对 APNG 的处理
jpg 和 jpeg 似乎是纯粹的别名关系，png 和 apng 并不属于这种关系，两种情况不应按照相似方法处理 考虑到 mirai 的项目目的，对 ImageType 的细化程度应和TX的协议要求尽可能一致 https://github.com/mamoe/mirai/blob/2d26f9476935371ba75fb9bfd7de3a9fb3730160/mirai-core/src/commonMain/kotlin/message/imagesImpl.kt#L216-L227
那应该为 JPG 添加 secondaryNames 比较好
这里我参考的是对 APNG 的处理
https://github.com/mamoe/mirai/blob/d8def8e6623611126b128a13db4a1e754e96cab8/mirai-core-api/src/commonMain/kotlin/message/data/Image.kt#L380
https://github.com/mamoe/mirai/blob/d8def8e6623611126b128a13db4a1e754e96cab8/mirai-core/src/commonMain/kotlin/message/ImageDecoder.kt#L158
有些时候文件的后缀命名是 jpeg，还有就是 http header 中 jpg 图片 的 Content-Type 一般是 image/jpeg， 这里是希望，对于
jpeg不用处理直接 可以作为formatName参数
这里有个问题 对于这种别名 在处理时是不会管你后缀是啥的 mirai内部会直接进行识别 直接按识别结果存储jpg即可 所以为什么要添加JPEG呢（
那应该为 JPG 添加 secondaryNames 比较好
这里我参考的是对 APNG 的处理 https://github.com/mamoe/mirai/blob/d8def8e6623611126b128a13db4a1e754e96cab8/mirai-core-api/src/commonMain/kotlin/message/data/Image.kt#L380
https://github.com/mamoe/mirai/blob/d8def8e6623611126b128a13db4a1e754e96cab8/mirai-core/src/commonMain/kotlin/message/ImageDecoder.kt#L158
有些时候文件的后缀命名是 jpeg，还有就是 http header 中 jpg 图片 的 Content-Type 一般是 image/jpeg， 这里是希望，对于
jpeg不用处理直接 可以作为formatName参数这里有个问题 对于这种别名 在处理时是不会管你后缀是啥的 mirai内部会直接进行识别 直接按识别结果存储jpg即可 所以为什么要添加JPEG呢（
有时候已经知道 具体的类型，希望可以手动提交
其实吧，我觉得应该另外增加一个类似fromMimeType或者fromExtensionName这样的API
然后弃用掉 matchOrNull 这种表意不明的API，至少不应该用在这种场合
但是问题在于，仅仅通过fromMimeType或者fromExtensionName是无法完全确认格式的（有APNG这种情况存在，必须通过byte stream判断），所以实际上还是依靠字节流自动判断比较靠谱
有时候已经知道 具体的类型，希望可以手动提交
可以说明一下这样做的具体优势吗
避免多余的判断（随机读取）？（实际上image还是会随机读取以获取高度和宽度）
最开始的想法是 既然 ExternalResource 的构造器提供了 formatName 这一参数，就应该有一些兼容性