AdoptOSS

> 我不知道ea最开始是为什么加入，翻记录第一班都有ea所以我留着了 > 那就可以去除了 #2048 大概需要ea逻辑，但可能需要重新设计

> 可考虑弃用原 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

其实吧，我觉得应该另外增加一个类似`fromMimeType`或者`fromExtensionName`这样的API 然后弃用掉 `matchOrNull` 这种表意不明的API，至少不应该用在这种场合 但是问题在于，仅仅通过`fromMimeType`或者`fromExtensionName`是无法完全确认格式的（有APNG这种情况存在，必须通过byte stream判断），所以实际上还是依靠字节流自动判断比较靠谱

> 有时候已经知道 具体的类型，希望可以手动提交 可以说明一下这样做的具体优势吗

@dragon0629 验证码登录的话大概要等 #717 看起来是TX的限制，这种情况下没法用正常方式登录了

> 但由于用户有可能会处理 imageId 的内容，不能影响已经编译的代码。 ID对用户的主要场景应该是作为标识，任何直接从ID中解析metadata或md5的行为都可能妨碍扩展性（可以另行讨论其必要性） 出于扩展性的考虑，提议新ID不做出过分具体的格式承诺，给出黑盒的String（为了便于序列化等场合，可承诺只包含字母及部分特定符号），并提供版本标号 > mitadata 既然只供内部使用，那用 ProtoBuf 编码不就最小了？（其实主要还是简单） 即使如此，使id基本可读仍然可能有助于调试分析等场合

另需考虑id的唯一性比较意义在新ID如何成立 考虑是否需要规定比较行为使用 mainID or fullID（特别是考虑到服务器提供的metadata可能不可靠的情况下）

的确相当于序列化，但是在许多场合，紧凑设计的image id 比多字段的Mirai code 或 JSON 要方便得多

登录全新device info的新账号，经常会出现类似“错误，请更新QQ版本”的情况 似乎 `ANDROID_PAD` / `IPAD` 也存在同样问题 但 `ANDROID_PHONE` 很正常