RFC 2046: MIME Phần 2 — Các Loại Phương Tiện

Standards Track MIME — Multipurpose Internet Mail Extensions Published March 2026

ELI5: [RFC 2045](2045) xác định phong bì cho email. RFC 2046 xác định các loại nội dung bạn có thể đặt bên trong: văn bản, hình ảnh, âm thanh, video, ứng dụng — và quan trọng nhất là, cách để đặt nhiều nội dung trong một phong bì. Đó là lý do tại sao một email có thể chứa nội dung văn bản, nội dung HTML và ba tệp đính kèm.

Tại Sao Điều Này Tồn Tại

RFC 2045 giới thiệu Content-Type và transfer encodings, nhưng nó không định nghĩa những loại nội dung nào tồn tại hoặc chúng hoạt động như thế nào. RFC 2046 lấp đầy khoảng trống đó bằng cách định nghĩa:

Các loại phương tiện cấp cao nhất (text, image, audio, video, application, multipart, message).
Cơ chế multipart cho phép một email duy nhất chứa nhiều phần nội dung với dấu phân cách ranh giới.
Các kiểu con multipart cụ thể điều khiển cách máy khách thư hiển thị các phần (mixed, alternative, digest, parallel).

Đây là RFC giúp email hiện đại trở thành khả thi. Không có nó, mỗi email sẽ là một khối văn bản duy nhất.

Cách Nó Hoạt Động

Các Loại Phương Tiện Cấp Cao Nhất

Loại	Mô Tả	Các Kiểu Con Phổ Biến
`text`	Văn bản có thể đọc được	`text/plain`, `text/html`, `text/calendar`
`image`	Dữ liệu hình ảnh	`image/png`, `image/jpeg`, `image/gif`, `image/svg+xml`
`audio`	Dữ liệu âm thanh	`audio/mpeg`, `audio/ogg`
`video`	Dữ liệu video	`video/mp4`, `video/webm`
`application`	Dữ liệu nhị phân hoặc định dạng có cấu trúc	`application/pdf`, `application/json`, `application/octet-stream`
`multipart`	Nhiều phần nội dung trong một tin nhắn	`multipart/mixed`, `multipart/alternative`, `multipart/related`
`message`	Tin nhắn email được đóng gói	`message/rfc822`, `message/delivery-status`

Cơ Chế Multipart

Các loại multipart là trái tim của RFC 2046. Một tin nhắn multipart chứa tham số boundary để phân cách mỗi phần:

Content-Type: multipart/mixed; boundary="----=_boundary_001"

------ lời nói đầu (bị bỏ qua bởi các máy khách MIME) ------

------=_boundary_001
Content-Type: text/plain; charset=utf-8

Đây là phần đầu tiên.

------=_boundary_001
Content-Type: text/plain; charset=utf-8

Đây là phần thứ hai.

------=_boundary_001--
^^^ lưu ý -- ở cuối đánh dấu kết thúc

Các quy tắc chính cho ranh giới:

Mỗi phần được đứng trước bởi -- + chuỗi ranh giới trên dòng riêng của nó.
Ranh giới cuối cùng có -- được thêm vào sau nó (ví dụ: --boundary--).
Chuỗi ranh giới không được xuất hiện trong bất kỳ phần nội dung nào. Sử dụng một chuỗi dài, ngẫu nhiên.
Nội dung trước ranh giới đầu tiên (phần mở đầu) và sau ranh giới cuối cùng (phần bế mạc) bị bỏ qua bởi các máy khách nhận thức MIME.

Các Kiểu Con Multipart

Kiểu con cho biết máy khách thư cách hiển thị các phần. Đây là nơi mà sự tinh tế nằm ở đó.

`multipart/mixed` — Các Phần Theo Trình Tự

Loại multipart phổ biến nhất. Các phần được hiển thị theo thứ tự. Được sử dụng cho "nội dung tin nhắn + tệp đính kèm":

Content-Type: multipart/mixed; boundary="----=_mixed"

------=_mixed
Content-Type: text/plain; charset=utf-8

Đây là báo cáo bạn yêu cầu.

------=_mixed
Content-Type: application/pdf; name="report.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report.pdf"

JVBERi0xLjQKJeLjz9MK...

------=_mixed--

`multipart/alternative` — Cùng Nội Dung, Các Định Dạng Khác Nhau

Chứa nhiều phiên bản của cùng nội dung. Máy khách thư chọn phiên bản tốt nhất mà nó có thể hiển thị. Các phần được sắp xếp từ đơn giản nhất đến phong phú nhất — phần cuối cùng được ưu tiên:

Content-Type: multipart/alternative; boundary="----=_alt"

------=_alt
Content-Type: text/plain; charset=utf-8

Chào mừng đến dịch vụ của chúng tôi!

------=_alt
Content-Type: text/html; charset=utf-8

<h1>Chào mừng đến dịch vụ của chúng tôi!</h1>
<p>Chúng tôi rất vui được có bạn.</p>

------=_alt--

Đây là cách mọi email HTML được xây dựng tốt hoạt động: phần văn bản/thường rơi vào đầu tiên, phiên bản văn bản/html rơi vào cuối cùng. Một máy khách hỗ trợ HTML hiển thị HTML; một máy khách văn bản thường hiển thị văn bản.

`multipart/related` — Các Phần Được Liên Kết

Được sử dụng khi các phần tham chiếu lẫn nhau. Trường hợp sử dụng phổ biến nhất là email HTML với hình ảnh nội tuyến. HTML tham chiếu hình ảnh bằng Content-ID (URL cid:):

Content-Type: multipart/related; boundary="----=_rel"

------=_rel
Content-Type: text/html; charset=utf-8

<p>Xem logo của chúng tôi:</p>
<img src="cid:logo@example.com" alt="Logo" />

------=_rel
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-ID: <logo@example.com>

iVBORw0KGgoAAAANSUhEU...

------=_rel--

`multipart/digest` — Bộ Sưu Tập Các Tin Nhắn

Một biến thể của mixed trong đó loại nội dung mặc định cho mỗi phần là message/rfc822 thay vì text/plain. Được sử dụng bởi các digest danh sách gửi thư. Hiếm khi thấy trong email hiện đại.

Các Chi Tiết Kỹ Thuật Chính

Các Loại Multipart Lồng Nhau

Sức mạnh thực sự của MIME đến từ sự lồng nhau. Một email tiếp thị điển hình với hình ảnh nội tuyến và tệp đính kèm trông như thế này:

; Cấu trúc tiêu chuẩn cho email HTML với hình ảnh nội tuyến + tệp đính kèm

Content-Type: multipart/mixed           ← ngoài: nội dung + tệp đính kèm
  |
  |-- multipart/alternative              ← nội dung: văn bản hoặc HTML
  |     |-- text/plain                    ← dự phòng văn bản thường
  |     |-- multipart/related             ← HTML + hình ảnh nội tuyến
  |           |-- text/html               ← nội dung HTML
  |           |-- image/png (cid:logo)    ← hình ảnh nội tuyến
  |
  |-- application/pdf (attachment)       ← tệp đính kèm

Sự lồng nhau ba cấp này là mẫu tiêu chuẩn được sử dụng bởi hầu như mọi thư viện email và nhà cung cấp dịch vụ email.

Loại `message/rfc822`

Đóng gói toàn bộ tin nhắn email dưới dạng phần nội dung. Được sử dụng để chuyển tiếp tin nhắn dưới dạng tệp đính kèm và trong thông báo bounce (RFC 3462 multipart/report). Tin nhắn được đóng gói có các tiêu đề riêng của nó (From, To, Subject, v.v.) và nội dung.

Dự Phòng `application/octet-stream`

Khi loại nội dung của tệp không xác định, hãy sử dụng application/octet-stream. Điều này cho máy khách biết rằng hãy coi nó như dữ liệu nhị phân chung và thường kích hoạt lời nhắc tải xuống. Nó tương đương MIME với "Tôi không biết cái này là gì; lưu nó lại và tìm ra bản thân".

Yêu Cầu Ranh Giới

Chuỗi ranh giới có những quy tắc cụ thể:

Tối đa 70 ký tự.
Bao gồm các ký tự chữ và số ASCII cộng với một bộ ký tự đặc biệt giới hạn: '()+_,-./:=? và khoảng cách.
Không được xuất hiện trong bất kỳ phần nội dung được đóng gói nào.
Trong thực tế, hãy sử dụng một chuỗi dài ngẫu nhiên như ----=_Part_12345_67890.1234567890.

Những Lỗi Phổ Biến

Sử dụng multipart/mixed thay vì multipart/alternative cho văn bản+HTML. Nếu bạn đặt text/plain và text/html trong một vùng chứa mixed, máy khách sẽ hiển thị cả hai (hoặc hiển thị văn bản và cung cấp HTML dưới dạng tải xuống). Sử dụng alternative để máy khách chọn định dạng tốt nhất.
Thứ tự phần sai trong multipart/alternative. Định dạng đơn giản nhất đầu tiên, phong phú nhất cuối cùng. Nếu bạn đặt HTML trước văn bản thường, một số máy khách sẽ hiển thị phiên bản văn bản thường ngay cả khi HTML có sẵn.
Hình ảnh nội tuyến mà không có multipart/related. Nếu bạn tham chiếu URL cid: trong HTML nhưng hình ảnh nằm trong phần multipart/mixed anh chị em thay vì vùng chứa multipart/related, nhiều máy khách sẽ không giải quyết tham chiếu.
Thiếu dấu ngoặc Content-ID. Giá trị tiêu đề Content-ID phải được bao quanh bởi dấu ngoặc nhọn: <image001@example.com>. Tham chiếu cid: trong HTML bỏ qua chúng: src="cid:image001@example.com".
Va chạm ranh giới. Sử dụng chuỗi ranh giới ngắn hoặc dễ dự đoán (như boundary hoặc ---) có nguy cơ xuất hiện trong nội dung nội dung, điều này sẽ làm hỏng cấu trúc tin nhắn. Luôn sử dụng ranh giới ngẫu nhiên.
Quên -- cuối cùng. Ranh giới đóng phải kết thúc bằng -- (ví dụ: --boundary--). Thiếu cái này khiến trình phân tích cú pháp chờ các phần khác và có thể dẫn đến tin nhắn bị xáo trộn hoặc không hoàn chỉnh.

Tác Động Về Khả Năng Gửi

Multipart/alternative chính xác là cần thiết. Bộ lọc thư rác mong đợi các email HTML được xây dựng tốt để bao gồm một phiên bản text/plain thay thế. Thiếu nó là tín hiệu spam. Các phần text và HTML phải có nội dung xấp xỉ tương đương — một phần văn bản một dòng với phần HTML 50 KB trông đáng ngờ.
Hình ảnh nội tuyến tăng điểm spam. Sử dụng nặng multipart/related với nhiều hình ảnh nội tuyến (đặc biệt là khi email chủ yếu là hình ảnh với ít văn bản) kích hoạt heuristics hình ảnh-spam. Ưu tiên hình ảnh được lưu trữ với URL https:// trên các tham chiếu cid: cho email tiếp thị.
Loại tệp đính kèm quan trọng. Tệp đính kèm có thể thực thi được (.exe, .js, .bat) bị chặn hoặc cách ly bởi hầu như tất cả các nhà cung cấp thư. Thậm chí .zip tệp chứa các tệp thực thi sẽ bị đánh dấu. Tuân thủ các loại an toàn: PDF, các định dạng hình ảnh phổ biến, tài liệu văn phòng.
Tin nhắn quá lớn bị từ chối. Nhiều nhà cung cấp từ chối tin nhắn trên 25 MB (một số trên 10 MB). Nhớ rằng mã hóa base64 thêm 33% chi phí. Tệp đính kèm 20 MB trở thành email ~27 MB.
MIME được cấu trúc đúng cách báo hiệu tính hợp pháp. Các MIME được tạo thành công với sự lồng nhau chính xác, ranh giới hợp lệ, và khai báo Content-Type thích hợp cho bộ lọc spam biết tin nhắn này được tạo bởi phần mềm email hợp pháp, không phải công cụ spam được xây dựng thủ công.