media-type

警告：这最初是一个 mime 的分叉，目的是添加一些 mime crate 中缺失的部分。从那时起，它与 mime crate 大量分道扬镳，现在它是一个重新编写/替代实现，而不是分叉，因为与原始 crate 几乎没有重叠。遗憾的是，它变得稍微复杂，在广泛使用之前需要经过一些简化和优化。如果可能的话，在简化和优化后，它将被合并到 mime crate 中。对于某些用例，它仍然很好。只是比 mime 慢，并且并不总是非常方便。

提供一个提供 media-type 类型（s）的 crate。媒体类型有时也称为 mime-type 或简称为 mime（但最后一个是错误的，因为 media-types 只是 mime 标准的一部分）。

媒体类型的经典示例是 text/plaincharset=utf-8。

虽然媒体类型看起来很简单，但它们有一些复杂的部分（关于编码非 US-ASCII 字符和语义相等性），遗憾的是没有 media-type 标准。相反，它们在多个标准中定义，并且 定义不同。但不仅定义不同，它们的使用方式也不同，这取决于如何使用标准。例如，http 标准中的媒体类型与 http 语法中“过时”部分的使用与否有关，这通常被（错误地）用来添加非 US-ASCII 文本（现在有一个“官方”的方法来编码非 US-ASCII utf-8，它基于 mime/mail 中类似的媒体类型标准，但有一些不同）。

最严格的MIME标准是用于在IANA注册表中注册媒体类型的标准（这应该始终进行）。虽然您创建的所有媒体类型都应该符合该标准，但您可能需要处理那些要么不兼容，要么在非语法但语义层面上扩展了语法的媒体类型。例如，通过指定具有特定形式的参数应被解释为百分比编码的UTF-8。

或者，有一些关于在非常安全的WAI中解析媒体类型的损失性标准，但可能产生无法使用的垃圾类型。

这个crate背后的想法是提供一种方式

1. 拥有一种形式的“任何”媒体类型，它可以被读取但不指定用于解析/验证它的语法。
2. 提供一些包装器，以类型安全的方式添加有关用于验证的语法的详细信息，从而对其结构提供保证。
3. 足够通用，允许人们添加他们自己的方法。