计算机网络基础：电子邮件的信息格式

梁辰兴2026-06-07 8:55

📌目录

📧 电子邮件的信息格式：结构、编码与MIME扩展

电子邮件的信息格式是定义电子邮件"内容组织方式"的标准规范，它规定了一封邮件从"传输标识"到"用户可见内容"的完整结构，包括邮件信封、邮件头部、邮件正文三大核心部分。作为电子邮件系统的"内容骨架"，其格式直接决定了邮件能否被正确解析、显示（如正文排版、附件展示），同时适配SMTP传输协议的要求，解决了纯文本邮件的局限性。本文将系统梳理电子邮件的基本结构、核心字段、编码规则，深入解析MIME扩展的作用与应用，结合考点与工程实战，帮助大家彻底掌握这一与SMTP紧密关联的核心知识点。

📖 一、电子邮件信息格式的核心概述：定义与本质

电子邮件的信息格式并非随意编写，而是由IETF制定统一标准（RFC 822、RFC 2822修订基本格式，RFC 2045-RFC 2049定义MIME扩展），其核心价值是"标准化邮件内容的组织与解析方式"，实现不同邮件客户端（Outlook、Foxmail、手机邮箱）、不同邮件服务器之间的内容互通。

（一）电子邮件格式的定义与核心定位

1. 核心定义

  • 官方定义：一封完整的电子邮件，由"邮件信封"和"邮件内容"两部分组成------邮件信封用于SMTP协议传输时的"地址标识"（告知服务器发件人、收件人），不被用户可见；邮件内容是用户实际编写、接收后可见的部分，包含头部（字段信息）和正文（具体内容）。
  • 通俗理解：电子邮件的格式就像"一封带信封的信件"------邮件信封对应现实中的信封（写有寄件人、收件人地址，供快递员投递），由SMTP协议解析使用；邮件内容对应信封内的信件（写有信件标题、正文、寄件时间），由邮件客户端解析并展示给用户。

2. 核心作用与定位

  • 核心作用：统一内容结构 （确保不同客户端/服务器能正确解析邮件）、支撑SMTP传输 （信封信息为SMTP中继提供地址依据）、适配内容扩展（通过MIME扩展支持附件、HTML格式等）。

  • 与SMTP的关联（高频考点）：SMTP协议负责"邮件传输"（投递信封），电子邮件格式负责"内容组织"（定义信封和信件内容），二者协同工作------SMTP传输时仅读取信封信息，不解析邮件内容；邮件内容的解析由接收方客户端完成，与SMTP无关。

  • 关键特征：基础格式简洁（仅支持纯文本）、可扩展性强（通过MIME扩展支持多种内容类型）、编码规范（解决非ASCII字符（中文、特殊符号）显示乱码问题）。

  • 示例（一封简单邮件的完整格式，简化版）：

    复制代码 
    // 邮件信封（SMTP传输用，用户不可见）
MAIL FROM:<userA@qq.com>
RCPT TO:<userB@163.com>

// 邮件内容（用户可见，头部+正文）
From: 张三 <userA@qq.com>
To: 李四 <userB@163.com>
Subject: 测试邮件格式
Date: Wed, 11 Feb 2026 10:00:00 +0800
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

这是一封测试电子邮件格式的纯文本邮件，用于演示基本结构。

  • 关键注意：

    1. 邮件信封与邮件内容的区别：信封仅包含发件人（MAIL FROM）、收件人（RCPT TO）地址，用于SMTP传输；内容包含From、To、Subject等头部字段和正文，是用户可见的部分，二者地址可不一致（如代发邮件）；
    2. 电子邮件的基础格式（RFC 822）仅支持ASCII字符，若包含中文、特殊符号或附件，必须通过MIME扩展和编码实现，否则会出现乱码或无法显示。

（二）格式的协议分层与核心特性

1. 协议分层归属

  • 分层：应用层，与SMTP、POP3、IMAP协议同级，本身不负责数据传输，仅定义"邮件内容的组织规则"；依赖SMTP协议完成传输，依赖POP3/IMAP协议完成接收后的解析与展示。
  • 交互逻辑：发件人通过客户端编写邮件（遵循邮件格式）→ 客户端将邮件封装为"信封+内容"，通过SMTP协议发送给服务器→ 服务器通过信封信息完成中继，将邮件内容存储→ 收件人通过POP3/IMAP协议获取邮件内容，客户端解析格式并展示。

2. 核心特性（3个关键）

  • 统一性：无论邮件内容是纯文本、HTML还是附件，均遵循"信封+头部+正文"的基础结构，不同客户端解析规则一致；
  • 简洁性：基础格式仅包含必要字段（From、To、Date等），结构清晰，便于服务器快速解析和传输；
  • 可扩展性：通过MIME扩展突破纯文本限制，支持附件、图片、HTML排版等多种内容形式，适配现代电子邮件的需求。

🔧 二、电子邮件的核心结构：信封+内容（必学重点）

一封完整的电子邮件，严格遵循"邮件信封 + 邮件内容"的双层结构，其中邮件内容又分为"邮件头部"和"邮件正文"，二者缺一不可。下面逐一解析各部分的定义、格式、示例和注意事项，结合实例拆解，便于理解和记忆。

（一）邮件信封（SMTP传输专用，用户不可见）

1. 定义与操作规则

  • 定义：邮件信封是SMTP协议传输邮件时使用的"地址标识信息"，仅包含发件人和收件人的邮箱地址，不包含任何用户可见的内容，由邮件客户端自动生成，SMTP服务器仅读取信封信息完成投递。

  • 格式：仅包含两个核心字段，无固定排版，由SMTP命令直接指定（对应SMTP中的MAIL FROM和RCPT TO命令）：

    1. 寄件人地址（Envelope From）：对应SMTP的MAIL FROM命令，格式为<发件人邮箱>；
    2. 收件人地址（Envelope To）：对应SMTP的RCPT TO命令，格式为<收件人邮箱>，支持多个收件人（多次执行RCPT TO命令）。

  • 示例（信封与SMTP命令的关联）：

    当用户A给用户B、用户C发邮件时，SMTP命令与信封信息对应如下：

    复制代码 
    // SMTP命令（客户端→服务器）
MAIL FROM:<userA@qq.com>  // 信封寄件人地址
RCPT TO:<userB@163.com>   // 信封收件人地址1
RCPT TO:<userC@126.com>   // 信封收件人地址2
DATA                      // 开始传输邮件内容（头部+正文）

  • 关键注意（高频考点）：

    1. 信封地址与邮件内容中的From/To字段可不一致：信封地址用于SMTP传输，内容中的From/To用于用户显示（如代发邮件：信封寄件人是代发服务器，内容From是实际发件人）；
    2. 信封仅包含邮箱地址，不包含姓名（如<userA@qq.com>），姓名仅在邮件内容的From/To字段中出现；
    3. 收件人类型（抄送CC、密送BCC）：CC（抄送）地址会同时出现在信封和内容To字段中（所有收件人可见）；BCC（密送）地址仅出现在信封中（仅收件人自己可见，其他收件人看不到）。

（二）邮件内容（用户可见，核心部分）

邮件内容是用户编写、接收后可见的全部信息，由"邮件头部"和"邮件正文"两部分组成，二者之间用一个空行分隔（核心分隔符，缺少会导致解析错误），格式严格遵循RFC 822标准。

1. 邮件头部（核心字段集合，必选+可选）

（1）定义与操作规则
  • 定义：邮件头部是邮件内容的"属性说明部分"，包含邮件的基本信息（发件人、收件人、主题、发送时间等），由一系列"字段名: 字段值"组成，每个字段单独一行，字段名不区分大小写（如From与from等价），字段值可换行（换行时需缩进）。
  • 核心规则：
    1. 必选字段（4个，缺少则邮件无效，无法正常解析）：From、To、Date、Subject；
    2. 可选字段（常用）：CC（抄送）、BCC（密送）、Reply-To（回复地址）、Content-Type（内容类型）、Content-Transfer-Encoding（编码方式）；
    3. 分隔规则：头部与正文之间必须有一个空行（仅换行，无其他字符），否则客户端会将头部当作正文解析。
（2）必选头部字段（高频考点，必须掌握）
字段名 格式 核心作用 示例 注意事项
From From: 姓名 <邮箱地址>（姓名可选） 指定邮件的实际发件人，用户可见 From: 张三 userA@qq.com 或 From: userA@qq.com 姓名可选，邮箱地址必须包含<>；若不填姓名，直接写邮箱地址
To To: 姓名1 <邮箱1>, 姓名2 <邮箱2>（多个用逗号分隔） 指定邮件的主要收件人，用户可见 To: 李四 userB@163.com, 王五 userD@sina.com 多个收件人用逗号分隔；可仅填邮箱地址，不填姓名
Subject Subject: 邮件主题（可包含中文，需编码） 简要说明邮件核心内容，用户可见 Subject: 2026年工作计划（纯文本） 或 Subject: =?UTF-8?B?5pmu5Lq65Yqo5LqG5ouG?=（中文编码后） 主题为空时，显示为"无主题"；中文需编码，否则乱码
Date Date: 星期, 日 月 年 时:分:秒 时区 指定邮件的发送时间，由客户端自动生成 Date: Wed, 11 Feb 2026 10:30:00 +0800 时区常用+0800（北京时间）；格式必须规范，否则显示"发送时间未知"
（3）常用可选头部字段
  • CC（抄送）：
    • 格式：CC: 姓名 <邮箱地址>（多个用逗号分隔）；
    • 作用：指定抄送收件人（邮件的次要接收者，所有收件人可见其邮箱）；
    • 示例：CC: 赵六 userE@139.com。
  • BCC（密送）：
    • 格式：BCC: 姓名 <邮箱地址>（多个用逗号分隔）；
    • 作用：指定密送收件人（仅自己可见，其他收件人看不到其邮箱，信封中会包含该地址）；
    • 示例：BCC: 孙七 userF@sohu.com。
  • Reply-To（回复地址）：
    • 格式：Reply-To: <邮箱地址>；
    • 作用：指定"回复邮件时的默认收件人"，若不设置，默认回复给From字段的发件人；
    • 示例：Reply-To: userA_reply@qq.com（回复时自动发送到该邮箱）。
  • Content-Type（内容类型）：
    • 格式：Content-Type: 类型/子类型; charset=编码格式；
    • 作用：指定邮件正文的类型和编码字符集，是解析正文的关键（后续MIME扩展重点讲解）；
    • 示例：Content-Type: text/plain; charset=utf-8（纯文本，UTF-8编码）。
  • Content-Transfer-Encoding（编码方式）：
    • 格式：Content-Transfer-Encoding: 编码名称；
    • 作用：指定邮件正文/附件的编码方式，解决非ASCII字符传输乱码问题；
    • 示例：Content-Transfer-Encoding: quoted-printable（中文正文常用编码）。
（4）邮件头部示例（完整版）
复制代码 
From: 张三 <userA@qq.com>
To: 李四 <userB@163.com>, 王五 <userD@sina.com>
CC: 赵六 <userE@139.com>
BCC: 孙七 <userF@sohu.com>
Subject: =?UTF-8?B?5pmu5Lq65Yqo5LqG5ouG?=  // 中文"2026年工作计划"编码后
Date: Wed, 11 Feb 2026 10:30:00 +0800
Reply-To: <userA_reply@qq.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

2. 邮件正文（用户编写的实际内容）

（1）定义与操作规则
  • 定义：邮件正文是用户实际编写的邮件内容，紧跟在邮件头部之后，用一个空行分隔，是邮件的核心信息（如文字、图片、附件的展示内容）。
  • 格式规则：
    1. 基础格式：仅支持纯文本（ASCII字符），每行长度建议不超过78个字符（兼容老旧客户端），换行用<CRLF>（回车+换行）；
    2. 编码规则：若包含中文、特殊符号，需通过"Content-Transfer-Encoding"指定的编码方式编码（如quoted-printable、Base64）；
    3. 排版规则：纯文本正文可通过换行、空格实现简单排版（如分段用两个<CRLF>），复杂排版（如字体、颜色）需通过MIME扩展实现HTML格式。
（2）示例（纯文本正文，中文编码后）
复制代码 
// 头部与正文之间的空行（必须）
=E8=BF=99=E6=98=AF=E4=B8=80=E5=B0=81=E6=B5=8B=E8=AF=95=E9=82=AE=E4=BB=B6=E7=9A=84=E6=AD=A3=E6=96=87=E3=80=82
=E5=85=AC=E5=8F=B82026=E5=B9=B4=E5=B7%A5=E4=BD=9C=E8=AE=A1=E5=88=92=E5=A6=82=E4=B8=8B=EF=BC=9A
1. =E5=85=AC=E5=8F=B8=E6=8A=80=E6=9C=AF=E5=8F=91=E5=B1=95=E6=8A=80=E6=9C=AF
2. =E5=AE=9E=E4=B8=9A=E5=A4=96=E6=8E=A5=E5=8F=8A=E5=85=B3=E8=81=94
3. =E5=91=98=E5=B7%A5=E5=9F=B9=E8=AE=AD=E5=92=8C=E6=89=98=E7=AE=A1

=E8=AF=B7=E5=9C=A82026=E5=B9=B43=E6=9C=8831=E6=97%A5=E5=89=8D=E5=8F=91=E5=9B=9E=E5=A4=8D=E3=80=82

  • 解码后正文：

    这是一封测试邮件的正文。

    公司2026年工作计划如下：

    1. 公司技术发展技术
    2. 实业外接及关联
    3. 员工培训和管理

    请在2026年3月31日前回复。

（3）关键注意
  1. 头部与正文的空行不可缺少：若缺少空行，邮件客户端会将头部字段当作正文的一部分，导致显示混乱；
  2. 纯文本正文不支持复杂排版：若需字体、颜色、图片插入，必须通过MIME扩展实现HTML正文；
  3. 正文编码必须与"Content-Transfer-Encoding"字段一致：否则会出现乱码（如编码为quoted-printable，解码用Base64，会显示乱码）。

（三）完整电子邮件格式实例拆解（综合应用）

为了巩固各部分知识，下面拆解一封完整的电子邮件（包含信封、头部、正文，中文编码），逐一对应各组成部分，帮助大家快速掌握：

复制代码 
// 1. 邮件信封（SMTP传输用，用户不可见）
MAIL FROM:<userA@qq.com>  // 信封寄件人
RCPT TO:<userB@163.com>   // 信封收件人（主要）
RCPT TO:<userE@139.com>   // 信封收件人（抄送）
RCPT TO:<userF@sohu.com>  // 信封收件人（密送）

// 2. 邮件内容（头部+正文，用户可见）
From: 张三 <userA@qq.com>
To: 李四 <userB@163.com>
CC: 赵六 <userE@139.com>
Subject: =?UTF-8?B?5pmu5Lq65Yqo5LqG5ouG?=  // 中文"2026年工作计划"
Date: Wed, 11 Feb 2026 10:30:00 +0800
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

// 头部与正文之间的空行（必须）
=E8=BF=99=E6=98=AF=E4=B8=80=E5=B0=81=E5=85=B3=E4=BA=8E2026=E5=B9=B4=E5=B7%A5=E4=BD=9C=E8=AE=A1=E5=88=92=E7=9A=84=E9=82=AE=E4=BB=B6=E3=80=82
=E5=85=AC=E5=8F=B82026=E5=B9=B4=E4=B8=BB=E8%A6%81=E5=8A%A0=E5=BC=BA=E4=BB%A5=E4=B8=8B=E5=8A=9B=E5=8A=9B=EF=BC=9A
1. =E6=8A=80=E6=9C=AF=E5=8F=91=E5=B1=95=EF=BC=9A=E5=8A%A0=E5=BC=BA=E7=BD=91=E7=BB=9C=E6=8A=80=E6=9C=AF=E5=8F=91=E5=B1=95=EF=BC=8C=E6=8F=90=E9=AB=98=E7=AB=AF=E6=8A=80=E6=9C=AF=E6=94=AF=E6=8C=81=E3=80=82
2. =E5=AE=9E=E4=B8=9A=E5=A4=96=E6=8E=A5=EF=BC=9A=E5=8A%A0=E5=BC=BA=E4=B8=8E=E5=A4=96=E9=83%A8=E4=BC=81=E4%B8%9A=E7=9A=84=E5=85=B3=E8=81=94=EF=BC=8C=E6=8F=90=E9=AB=98=E5=AE=9E=E4=B8=9A=E7=94=9F=E4=BA%A7=E8=83=BD=E5=8A=9B=E3=80=82
3. =E5=91=98=E5=B7%A5=E5=9F=B9=E8=AE=AD=EF=BC=9A=E5=8A%A0=E5=BC=BA=E5=91=98=E5=B7%A5=E7=9A=84=E6=8A=80=E6=9C=AF=E5=9F=B9=E8=AE=AD=EF=BC=8C=E6=8F=90=E9=AB=98=E5=91=98=E5=B7%A5=E5=8A=9B=E5=8A=9B=E3=80=82

=E8=AF=B7=E5=90=84=E9=83%A8=E9=97%A8=E5=89=8D=E5=A4=8D=E6=8E=A5=E4=BB%A5=E4=B8=8A=E5=8A=9B=E5=8A=9B=EF=BC=8C=E5=B9=B6=E5=9C=A82026=E5=B9=B43=E6=9C=8831=E6=97%A5=E5=89=8D=E5=8F=91=E5=9B=9E=E5=A4=8D=E6=8E=A5=E7=9A=84=E5=B7%A5=E4=BD=9C=E6=83=85=E5=86%B5=E3=80=82
组成部分 内容说明 核心作用
邮件信封 MAIL FROM:userA@qq.com、RCPT TO:userB@163.com等 SMTP传输时定位发件人、收件人，完成投递
邮件头部 From、To、Subject、Date等字段 说明邮件属性，供客户端显示基本信息，指导解析
邮件正文 编码后的中文内容（解码后为2026年工作计划） 展示用户编写的实际邮件内容

🔄 三、电子邮件的编码规则：解决非ASCII字符乱码

电子邮件的基础格式（RFC 822）仅支持ASCII字符（0-127之间的字符，如字母、数字、部分符号），若邮件中包含中文、日文等非ASCII字符 ，或特殊符号（如@、#、空格之外的符号），直接传输会导致解析错误、显示乱码。因此，需要通过标准化的编码方式，将这些字符转换为ASCII字符范围内的字符串，确保传输和解析正常。

（一）编码核心原则

1. 编码定义与逻辑

  • 定义：电子邮件编码是将非ASCII字符转换为ASCII字符的过程，核心分为"头部编码"和"正文编码"，二者编码方式可不同，但需在头部字段中明确指定，确保接收方客户端能正确解码。
  • 核心逻辑：
    1. 头部编码：仅对Subject、From、To等字段中的非ASCII字符（如中文姓名、中文主题）编码，字段名不编码；
    2. 正文编码：对整个正文的非ASCII字符编码，编码方式由"Content-Transfer-Encoding"字段指定；
    3. 编码后的数据均为ASCII字符，可通过SMTP协议正常传输，接收方客户端根据头部字段的编码说明，解码还原为原始字符。

2. 两种核心编码方式（高频考点）

电子邮件常用的编码方式有两种：Quoted-Printable和Base64，二者适用场景不同，需根据内容类型选择，下面逐一解析：

（二）Quoted-Printable编码（中文正文首选）

1. 编码规则与适用场景

  • 适用场景：适用于包含大量ASCII字符、少量非ASCII字符的内容（如中文正文、带特殊符号的纯文本），编码后可读性较强（ASCII字符直接保留）。
  • 核心规则：
    1. ASCII字符（33-126之间，如字母、数字、常用符号）：不编码，直接保留；
    2. 特殊ASCII字符（如空格、换行、=）：编码为"=+两位十六进制ASCII码"；
    3. 非ASCII字符（如中文）：先转换为指定字符集（如UTF-8）的字节，再对每个字节编码为"=+两位十六进制数"；
    4. 每行编码后的长度不超过76个字符，若超过，需在该行末尾加"="表示换行（换行符不编码）。

2. 示例（中文编码与解码）

  • 原始中文："2026年工作计划"（UTF-8编码字节：E5 85 B3 E4 BA 8E 32 30 32 36 E5 B9 B4 E5 B7 A5 E4 BD 9C E8 AE A1 E5 88 92）；
  • 编码后：=E5=85=B3=E4=BA=8E2026=E5=B9=B4=E5=B7%A5=E4=BD=9C=E8=AE=A1=E5=88=92；
  • 解码：将每个"=xx"转换为对应的字节，再组合为UTF-8字符串，还原为原始中文。

（三）Base64编码（附件/二进制内容首选）

1. 编码规则与适用场景

  • 适用场景：适用于二进制内容（如图片、文档、视频等附件），或包含大量非ASCII字符的内容，编码后为纯ASCII字符串，可通过SMTP正常传输。
  • 核心规则：
    1. 将二进制数据（如附件的二进制流、中文的UTF-8字节）按3个字节为一组，转换为4个ASCII字符；
    2. 若二进制数据长度不是3的倍数，用"="补齐（补齐的"="仅用于标识，解码时忽略）；
    3. 编码后的字符仅包含A-Z、a-z、0-9、+、/（共64个字符，对应Base64名称），无其他特殊字符；
    4. 每行编码后的长度不超过76个字符，超过则换行（换行符不编码）。

2. 示例（中文编码与解码）

  • 原始中文："测试附件"（UTF-8编码字节：E6 B5 8B E8 AF 95 E9 99 84 E4 BB B6）；
  • 编码后：5rWL6K+V5ouG5pys；
  • 解码：将4个ASCII字符一组，转换为3个二进制字节，再组合为UTF-8字符串，还原为原始中文。

（四）两种编码方式对比（高频考点）

编码方式 适用场景 编码后可读性 编码效率（字节膨胀率） 示例
Quoted-Printable 中文正文、少量特殊符号的纯文本 强（ASCII字符保留） 较低（1个非ASCII字符→3个字节） =E8=BF=99=E6=98=AF=E4=B8=80=E5=B0=81=E6=B5=8B=E8=AF=95=E6=AD=A3=E6=96=87
Base64 附件、二进制内容、大量非ASCII字符 弱（纯编码字符串，无可读性） 较高（3个字节→4个字节，膨胀率33%） 5rWL6K+V5ouG5pys

关键注意

  1. 编码一致性：头部编码与正文编码可不同（如Subject用Base64，正文用Quoted-Printable），但需在对应字段中明确指定（如Subject编码需标注字符集，正文编码由Content-Transfer-Encoding指定）；
  2. 字符集统一：编码和解码必须使用相同的字符集（目前主流为UTF-8），否则会出现乱码（如客户端用GBK编码，服务器用UTF-8解码，中文会显示乱码）；
  3. 附件编码：所有附件均需用Base64编码，因为附件是二进制内容，Quoted-Printable编码效率极低，无法适配。

💻 四、MIME扩展：突破纯文本限制（核心补充）

电子邮件的基础格式（RFC 822）仅支持纯文本ASCII字符，无法传输附件、图片、HTML格式邮件，也无法正常显示中文等非ASCII字符。为了解决这些局限，IETF制定了MIME协议（多用途互联网邮件扩展，Multipurpose Internet Mail Extensions），作为电子邮件格式的补充，扩展了邮件内容的支持类型。

（一）MIME的核心作用与定位

1. 核心定义与作用

  • 定义：MIME是电子邮件格式的扩展标准，不改变电子邮件的基础结构（信封+头部+正文），仅通过新增头部字段和内容组织方式，扩展邮件内容的支持范围。
  • 核心作用（3个关键）：
    1. 支持非ASCII字符（中文、日文等）：通过编码方式，将非ASCII字符转换为ASCII字符传输；
    2. 支持多种内容类型：纯文本、HTML、图片、音频、视频、文档等（如HTML邮件、图片附件）；
    3. 支持多部分内容：一封邮件可包含多个部分（如正文+多个附件、纯文本正文+HTML正文）。

2. 与电子邮件格式、SMTP的关联

  • MIME与电子邮件格式：MIME是电子邮件格式的"扩展插件"，遵循RFC 822的基础结构，仅新增头部字段和内容组织规则；
  • MIME与SMTP：MIME不影响SMTP传输，SMTP仅传输编码后的ASCII字符，无需解析MIME内容；MIME内容的解析由接收方客户端完成。

（二）MIME核心头部字段（必学）

MIME通过新增3个核心头部字段，告知接收方客户端"邮件内容的类型、编码方式、组织方式"，这3个字段是MIME扩展的核心，也是高频考点：

1. Content-Type（内容类型字段）

  • 格式：Content-Type: 类型/子类型; 参数

  • 核心作用：指定邮件内容的类型（纯文本、HTML、附件等），以及内容的组织方式（单部分/多部分）。

  • 常见类型与子类型（高频考点）：

    （1）单部分内容（邮件仅包含一种类型的内容）：

    • 纯文本：text/plain; charset=utf-8（默认，纯文本正文）；
    • HTML文本：text/html; charset=utf-8（HTML格式正文，支持排版、图片）；
    • 图片：image/jpeg（JPG图片）、image/png（PNG图片）；
    • 文档：application/pdf（PDF文件）、application/msword（Word文件）；
    • 音频/视频：audio/mp3（MP3音频）、video/mp4（MP4视频）。

    （2）多部分内容（邮件包含多种类型的内容，如正文+附件）：

    • 格式：Content-Type: multipart/mixed; boundary=分隔符
    • 说明：boundary（分隔符）是自定义的字符串，用于分隔邮件的不同部分（如正文部分、附件1、附件2），分隔符需唯一，不可在内容中出现。

2. Content-Transfer-Encoding（编码方式字段）

  • 格式：Content-Transfer-Encoding: 编码名称
  • 核心作用：指定邮件内容（正文/附件）的编码方式，告知接收方客户端如何解码。
  • 常用编码名称：quoted-printable（中文正文）、base64（附件、二进制内容）、7bit（纯ASCII字符，无需编码）。

3. Content-Disposition（内容处置字段）

  • 格式：Content-Disposition: 处置类型; filename=文件名（可选）
  • 核心作用：指定邮件内容的展示方式（是显示为正文，还是作为附件下载），主要用于附件。
  • 常用处置类型：
    • inline： inline（默认，将内容显示在邮件正文中，如HTML图片、纯文本）；
    • attachment： attachment（将内容作为附件，接收方需下载才能查看，需指定filename参数，如filename="2026工作计划.pdf"）。

（三）MIME多部分内容示例（带附件的邮件）

下面以"纯文本正文+PDF附件"的邮件为例，展示MIME多部分内容的格式（核心部分）：

复制代码 
From: 张三 <userA@qq.com>
To: 李四 <userB@163.com>
Subject: =?UTF-8?B?5pmu5Lq65Yqo5LqG5ouG+5paH5Lu2?=  // 中文"2026年工作计划+附件"
Date: Wed, 11 Feb 2026 11:00:00 +0800
Content-Type: multipart/mixed; boundary="abc123"  // 多部分内容，分隔符abc123
Content-Transfer-Encoding: 7bit  // 头部编码为7bit（纯ASCII）

// 分隔符（开头加--），分隔正文部分
--abc123
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=E8=BF=99=E6=98=AF2026=E5=B9=B4=E5=B7%A5=E4=BD=9C=E8=AE=A1=E5=88=92=E7=9A=84=E9=82=AE=E4=BB=B6=EF=BC=8C=E9=99=84=E4=BB%B6=E4%B8%BA=E5=8A%A0=E5=BC=BA=E7=9A=84=E5=8A=9B=E5=8A=9B=E3=80=82

// 分隔符，分隔PDF附件部分
--abc123
Content-Type: application/pdf; name="2026工作计划.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="2026工作计划.pdf"

JVBERi0xLjQKJeLjz9MNCjYgMCBvYmoKPDwvTGVuZ3RoIDQgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeAovRjEgMCBSL0YwIDAgUi9GMiAwIFIKL0Y0IDAgUi9GNCAwIFIKPj4Kc3RhcnR4cmVmCjE0NgolJUVPRgo=

// 分隔符（结尾加--），标识多部分内容结束
--abc123--

关键注意

  1. 分隔符规则：多部分内容的分隔符必须在Content-Type字段中指定，每个部分用"--分隔符"开头，最后一个部分用"--分隔符--"结尾（双横杠标识结束）；
  2. 附件文件名编码：若文件名包含中文，需对文件名进行编码（如filename*=UTF-8''%E5%B7%A5%E4%BD%9C%E8%AE%A1%E5%88%92.pdf），否则会显示乱码；
  3. HTML正文与纯文本正文共存：可通过multipart/alternative类型，同时包含纯文本正文和HTML正文，客户端会优先显示HTML正文（若不支持HTML，显示纯文本正文）。

📚 五、电子邮件格式的常见应用场景与规范

电子邮件格式的规范应用，直接影响邮件的解析效果和用户体验，下面结合实际工程场景，梳理常见应用场景和规范，帮助大家规避问题、规范编写。

（一）常见应用场景

1. 纯文本邮件（基础场景）

  • 场景说明：仅包含纯文本正文，无附件、无复杂排版，适用于简单通知、测试邮件；
  • 格式规范：头部包含4个必选字段，正文为纯文本，中文编码用quoted-printable，Content-Type设为text/plain; charset=utf-8；
  • 示例：企业内部通知邮件、简单的个人沟通邮件。

2. HTML格式邮件（常用场景）

  • 场景说明：包含HTML正文，支持字体、颜色、排版、图片插入，适用于营销邮件、正式通知邮件；
  • 格式规范：Content-Type设为text/html; charset=utf-8，HTML正文需符合HTML标准，图片可内嵌（Base64编码）或链接（外部图片URL）；
  • 注意事项：需同时准备纯文本正文（通过multipart/alternative类型），适配不支持HTML的老旧客户端。

3. 带附件的邮件（高频场景）

  • 场景说明：包含正文+一个或多个附件（文档、图片、音频等），适用于工作汇报、文件传输；
  • 格式规范：Content-Type设为multipart/mixed; boundary=分隔符，每个附件单独作为一个部分，编码用Base64，Content-Disposition设为attachment，指定文件名；
  • 注意事项：附件大小不宜过大（受邮件服务器限制，通常单个附件不超过20MB），文件名包含中文时需编码。

4. 带图片的邮件（营销/宣传场景）

  • 场景说明：正文包含内嵌图片（如LOGO、宣传图片），适用于营销邮件、产品宣传邮件；
  • 格式规范：图片可通过两种方式嵌入：
    1. 内嵌图片：将图片Base64编码，作为多部分内容的一部分，Content-Disposition设为inline；
    2. 外部图片：在HTML正文中引用图片URL（如<img src="https://img.xxx.com/logo.png">）；
  • 注意事项：外部图片可能被客户端拦截（显示为占位符），优先使用内嵌图片（Base64编码）。

（二）工程应用规范（避坑重点）

  1. 头部字段规范：必选字段（From、To、Subject、Date）不可缺少，格式严格遵循标准（如Date字段的时区、Subject字段的编码）；
  2. 编码规范：中文主题用Base64编码，中文正文用quoted-printable编码，附件用Base64编码，字符集统一为UTF-8；
  3. 多部分内容规范：分隔符需唯一，不可在内容中出现，结尾必须用"--分隔符--"标识结束；
  4. 文件名规范：附件文件名包含中文时，需编码（如filename*=UTF-8''文件名.pdf），避免乱码；
  5. 兼容性规范：尽量兼容老旧客户端，HTML邮件需搭配纯文本正文，避免使用复杂的HTML标签和样式。

⚠️ 六、常见问题与故障排查（高频考点+实战）

在电子邮件格式的使用和开发过程中，经常会遇到乱码、附件无法打开、正文显示混乱等问题，下面梳理5个核心问题，结合考点和实际故障，帮助大家快速排查、解决。

（一）邮件乱码（最常见问题）

1. 故障现象与原因

  • 现象：邮件主题、正文或附件文件名显示乱码（如"=E8=BF=99=E6=98=AF=E4=B8=80=E5=B0=81=E9=82=AE=E4=BB=B6"）；
  • 核心原因：
    1. 编码与解码字符集不一致（如客户端用GBK编码，服务器用UTF-8解码）；
    2. 头部字段（Subject）未编码，直接包含中文；
    3. 正文编码方式与Content-Transfer-Encoding字段指定不一致（如正文用Base64编码，字段指定为quoted-printable）。

2. 解决方案

  • 统一字符集：编码和解码均使用UTF-8（目前主流）；
  • 规范编码：中文主题用Base64编码，中文正文用quoted-printable编码，附件用Base64编码；
  • 检查字段：确保Content-Transfer-Encoding字段指定的编码方式与正文/附件的实际编码一致。

（二）附件无法打开

1. 故障现象与原因

  • 现象：接收邮件后，附件显示灰色，无法下载或打开；
  • 核心原因：
    1. 附件编码错误（如用quoted-printable编码，而非Base64）；
    2. Content-Type字段指定的附件类型错误（如PDF文件设为image/jpeg）；
    3. 多部分内容的分隔符错误（如缺少结尾的"--分隔符--"）。

2. 解决方案

  • 附件编码：所有附件均用Base64编码；
  • 正确指定类型：根据附件格式，正确设置Content-Type（如PDF设为application/pdf）；
  • 检查分隔符：确保多部分内容的分隔符正确，结尾包含"--分隔符--"。

（三）正文显示混乱（头部与正文混淆）

1. 故障现象与原因

  • 现象：邮件正文包含头部字段（如From、To），或正文部分显示不全；
  • 核心原因：头部与正文之间缺少空行（核心分隔符），客户端将头部当作正文解析。

2. 解决方案

  • 严格添加空行：在邮件头部的最后一个字段后，添加一个空行（仅换行，无其他字符），再编写正文。

（四）HTML正文无法显示（仅显示纯文本）

1. 故障现象与原因

  • 现象：发送的HTML邮件，接收后仅显示纯文本，不显示排版和图片；
  • 核心原因：
    1. Content-Type字段设为text/plain（纯文本），而非text/html；
    2. 客户端不支持HTML格式，且未添加纯文本正文（multipart/alternative类型）。

2. 解决方案

  • 正确设置Content-Type：HTML正文设为text/html; charset=utf-8；
  • 添加纯文本正文：通过multipart/alternative类型，同时包含HTML正文和纯文本正文，适配不同客户端。

（五）密送（BCC）收件人无法接收邮件

1. 故障现象与原因

  • 现象：密送（BCC）的收件人未收到邮件，主要收件人和抄送收件人正常接收；
  • 核心原因：BCC地址仅添加到邮件内容的BCC字段中，未添加到邮件信封的RCPT TO命令中（SMTP仅读取信封地址投递）。

2. 解决方案

  • 正确设置BCC：将BCC收件人地址同时添加到"邮件内容的BCC字段"和"邮件信封的RCPT TO命令"中，确保SMTP服务器能读取到密送地址。

📝 总结

电子邮件的信息格式是电子邮件系统的"内容骨架"，核心遵循"邮件信封+邮件内容"的双层结构，其中邮件内容包含头部（字段集合）和正文（实际内容），二者协同实现邮件的传输与展示。MIME扩展作为核心补充，突破了纯文本邮件的局限，支持中文、附件、HTML格式等，与SMTP协议协同工作，构成了完整的电子邮件服务体系。

🔍 核心逻辑 ：电子邮件格式的本质是"标准化内容组织方式"，邮件信封用于SMTP传输（地址标识，用户不可见），邮件内容用于用户展示（头部+正文，用户可见）；基础格式仅支持ASCII字符，MIME扩展和编码规则解决了非ASCII字符和附件传输的问题。

⚖️ 编码与MIME ：常用两种编码方式------Quoted-Printable（中文正文首选）、Base64（附件首选）；MIME通过Content-Type、Content-Transfer-Encoding、Content-Disposition三个核心字段，扩展邮件内容类型和展示方式。

📚 应用规范 ：不同场景（纯文本、HTML、带附件）需遵循对应的格式规范，核心是保证编码一致、字段完整、分隔正确，兼顾兼容性和用户体验。

⚠️ 故障排查：常见问题（乱码、附件无法打开、正文混乱）的核心原因的是编码不一致、字段错误、分隔符缺失，需针对性检查编码方式、头部字段和MIME设置。

理解电子邮件的信息格式，不仅能掌握邮件内容的组织与解析逻辑，更能快速排查邮件发送与接收过程中的故障，同时深入理解SMTP、MIME、POP3/IMAP协议的协同关系，为后续学习邮件系统搭建、邮件客户端开发打下坚实基础，也是计算机网络基础的高频考点。

相关推荐
RXXW_Dor1 小时前
ModbusTcp通信C#WPF开发测试(基于Nmodbus4库应用)
服务器·网络·tcp/ip
.小小陈.1 小时前
应用层协议 HTTP 全解析：从基础到实战
网络·网络协议·http
Irissgwe1 小时前
10、NAT、代理服务、内网穿透
网络·frp·内网穿透·nat·代理服务器·反向代理·正向代理
网络研究院1 小时前
AI安全格局：前沿模型、智能体AI和AI编码工具如何重塑网络安全与关键基础设施韧性
网络·人工智能·安全·模型·威胁
10WTW011 小时前
计网实验 协议分析--ARP协议
网络
酉鬼女又兒1 小时前
零基础入门计算机网络：点对点协议PPP、媒体接入控制基本概念、静态划分信道技术、CSMA/CD与CSMA/CA协议全面详解
服务器·网络·网络协议·计算机网络·职场和发展·求职招聘·媒体
Shadow（⊙ｏ⊙）2 小时前
System V共享内存详解，shm系列接口，三种共享内存删除机制。System V通信缺点分析
linux·运维·服务器·开发语言·网络·c++
酉鬼女又兒2 小时前
零基础快速入门IP编址计算练习题详解：从基础到实战
网络·网络协议·tcp/ip·计算机网络·考研·职场和发展·分类
万能的知了2 小时前
服务器托管 vs 云主机 vs 裸金属：一张决策流程图
运维·服务器·网络
热门推荐
01GitHub 镜像站点02【AI】2026 年具身智能模型和世界模型总结032026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf04Codex 下载安装指南：Windows 和 macOS 官方版下载05Codex 桌面端更新后 Chrome 插件和 Computer Use 不可用，怎么排查和修复06CC-Switch 下载、安装与使用配置指南【2026.5.29】07【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法08CC-Switch & Claude 基于 Linux 服务器安装使用指南09Codex 接入 DeepSeek API 完整配置文档10裂开！ChatGPT 居然开始要手机号验证，附详细解决方法