What do the numbers in a multi-part email mean?

What do the numbers in a multi-part email mean?

南汐寒笙箫 发布于 2021-11-29 字数 829 浏览 893 回复 2 原文

I'm looking at the source of a multi-part message from Thunderbird (in hopes of writing my own multi-part message from C++/Javascript)

I was wondering what the follow means (the part between the text-only part and the html part of the email) and how I might calculate it for my own program to generate a multi-part email:

This is a multi-part message in MIME format.

Content-Type: multipart/alternative;
Content-Description: Message in alternative text and HTML forms


(as seen here)

The rest of the message code makes sense to me for the post part.

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。



需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。


老子叫无熙 2022-06-07 2 楼

They don't mean anything. They are just a random string that does not occur within the body of the email. They are just used to mark where the embedded message starts and stops.

白况 2022-06-07 1 楼

The numbers you are seeing within the boundary delimiters don't necessarily mean anything (although the RFC doesn't preclude an implementor from trying to include some meaning).

They must be unique and not contained within the part that they encapsulate.

From RFC 2046:

5.1. Multipart Media Type

In the case of multipart entities,
in which one or more different sets
of data are combined in a single body,
a "multipart" media type field must
appear in the entity's header. The
body must then contain one or more
body parts, each preceded by a
boundary delimiter line

As stated previously, each body part is preceded by a boundary
delimiter line that contains the boundary delimiter. The boundary
delimiter MUST NOT appear inside any of the encapsulated parts, on a
line by itself or as the prefix of any line


5.1.1. Common Syntax

The Content-Type field for
multipart entities requires one
parameter, "boundary". The boundary
delimiter line is then defined as a
line consisting entirely of two
hyphen characters
("-", decimal value
45) followed by the boundary
parameter value from the Content-Type
header field, optional linear
whitespace, and a terminating CRLF.


NOTE: Because boundary delimiters must not appear in the body parts
being encapsulated, a user agent must exercise care to choose a
unique boundary parameter value. The boundary parameter value
[could be] the result of an algorithm designed to
produce boundary delimiters with a very low probability of already
existing in the data to be encapsulated without having to prescan the
... The
simplest boundary delimiter line possible is something like "---",
with a closing boundary delimiter line of "-----".