电子邮件中有多少种Content-Type和Content-Encoding-Trafing以及如何解码？
我正在使用 ImapX lib 接收来自 Gmail 的电子邮件。
我收到电子邮件正文的多种类型的内容类型和内容编码传输。 如何解码呢？
I am using ImapX lib to recieve email from Gmail.
I get many type of Content-Type and Content-Encoding-Trafering of Body of email.
How to decode it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
MIME 标准记录在 RFC 2045 到 2048 中。您可能不想阅读所有这些标准，但在尝试处理 MIME 之前，您当然应该对 MIME 有基本的了解。 http://en.wikipedia.org/wiki/MIME 是一个很好的起点。
Content-Transfer-Encoding可以具有五个不同值之一；其中，7bit、8bit和binary不需要任何解码（它们的不同之处在于您可以假设的字符集和行长度;8bit和binary之间的区别是8bit保证具有有限长度的行，尽管有时您确实会看到这种情况被违反； ）。对于
quoted-printable和base64您需要解码；但任何相当现代的编程语言都已经有这方面的库函数。Content-Type层次结构基本上是无限的。顶级类型的数量有限（text、image、audio、application等）一组标准的子类型（text/plain、text/html等），但正在注册更多子类型，并且标准不要求注册类型。无论如何，这些通常不需要解码；它们声明内容的类型，以便接收者知道如何处理它们。通用的包罗万象的是application/octet-stream，它基本上意味着“这里有一个数据块；希望人类接收者知道如何处理它”，并且对于许多类型来说，没有合理的默认值下载到本地磁盘以外的操作。所有通用电子邮件客户端都会直接向用户显示text/plain，除非Content-Disposition另有要求，并且大多数现代客户端都会显示text/html和其他几种内联类型。但您想要对内容执行的操作首先取决于您正在编写的应用程序类型。The MIME standards are documented in RFCs 2045 through 2048. You probably don't want to read all of them, but you certainly should have a basic understanding of MIME before you attempt to process it. http://en.wikipedia.org/wiki/MIME is a good starting point.
The
Content-Transfer-Encodingcan have one of five distinct values; out of those,7bit,8bit, andbinarydo not need any decoding (they differ in what you can assume about character sets and line lengths; the difference between8bitandbinaryis that8bitis guaranteed to have lines of limited length; although you certainly see this violated in the wild sometimes).For
quoted-printableandbase64you need decoding; but any reasonably modern programming language already has library functions for this.The
Content-Typehierarchy is basically unlimited. There is a limited number of top-level types (text,image,audio,application, etc) and a standard set of subtypes (text/plain,text/html, etc) but more are being registered, and the standard doesn't require a type to be registered. Anyway, these do not typically need decoding; they declare the type of the content, so that the recipient knows what to do with them. The generic catch-all isapplication/octet-streamwhich basically means "here is a blob of data; hopefully the human recipient knows what to do with this" and for many types, there is no sensible default action other than to download to the local disk. All general-purpose email clients will displaytext/plaindirectly to the user, unless theContent-Dispositionrequires otherwise, and most modern clients will displaytext/htmland several other types inline. But what you want to do with the content is first and foremost dictated by what kind of application you are coding.