Tôi đang cố triển khai trình phân tích cú pháp MIME cơ bản cho số multipart/related bằng C++/Qt.MIME RFC "Loại nội dung" nhầm lẫn thông số? Đặc tả RFC không rõ ràng
Cho đến giờ tôi đã viết một số mã phân tích cú pháp cơ bản cho các tiêu đề và tôi đang đọc các RFC để có ý tưởng cách thực hiện mọi thứ càng gần với đặc tả càng tốt. Đáng tiếc là có một phần trong RFC gây bối rối cho tôi một chút:
Từ RFC882 Mục 3.1.1:
Mỗi lĩnh vực tiêu đề có thể được xem như là một dòng duy nhất, logic của ký tự ASCII, bao gồm một tên trường và trường nội dung. Để thuận tiện, phần trường-thân của thực thể khái niệm này có thể được chia thành một biểu diễn nhiều dòng; này được gọi là "gấp". Quy tắc chung là ở bất cứ nơi nào có có thể là tuyến tính-trắng-không gian (KHÔNG chỉ đơn giản là LWSP-ký tự), một CRLF ngay lập tức theo sau AT LEAST một LWSP-char thay vì có thể được chèn vào. Do đó, một dòng đơn
Được rồi, vì vậy tôi chỉ đơn giản phân tích trường tiêu đề và nếu CRLF theo sau khoảng trắng tuyến tính, tôi chỉ cần kết hợp chúng một cách hữu ích để tạo thành một dòng tiêu đề. Hãy tiến hành ...
Từ RFC2045 Mục 5.1:
Trong ký hiệu Augmented BNF của RFC 822, một lĩnh vực tiêu đề giá trị Content-Type được định nghĩa như sau:
content := "Content-Type" ":" type "/" subtype *(";" parameter) ; Matching of media type and subtype ; is ALWAYS case-insensitive.[ ...]
parameter := attribute "=" value attribute := token ; Matching of attributes ; is ALWAYS case-insensitive. value := token/quoted-string token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials>
Oka y. Vì vậy, có vẻ như nếu bạn muốn chỉ định một tiêu đề Content-Type với các thông số, bạn chỉ cần làm điều đó như thế này:
Content-Type: multipart/related; foo=bar; something=else
... và một phiên bản gấp của cùng một tiêu đề sẽ trông như thế này:
Content-Type: multipart/related;
foo=bar;
something=else
Chính xác? Tốt. Như tôi đã tiếp tục đọc các RFC, tôi đi qua những điều sau đây trong RFC2387 Mục 5.1 (Ví dụ):
Content-Type: Multipart/Related; boundary=example-1
start="<[email protected]>";
type="Application/X-FixedRecord"
start-info="-o ps"
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <[email protected]>
[data]
--example-1
Content-Type: Application/octet-stream
Content-Description: The fixed length records
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
[data]
--example-1--
Hmm, đây là số lẻ. Bạn có thấy tiêu đề Content-Type không? Nó có một số tham số, nhưng không phải tất cả đều có một ";" làm dấu phân cách tham số.
Có lẽ tôi không đọc RFC đúng cách, nhưng nếu trình phân tích cú pháp của tôi hoạt động đúng như đặc tả, các tham số type và start-info sẽ dẫn đến một chuỗi hoặc tệ hơn, lỗi phân tích cú pháp.
Các bạn nghĩ gì về điều này? Chỉ là một lỗi đánh máy trong RFC? Hay tôi đã bỏ lỡ điều gì đó?
Cảm ơn!
Khi làm việc với các tiêu chuẩn như vậy, bạn nên luôn luôn khoan dung khi đọc đầu vào và nghiêm ngặt khi viết đầu ra. – Gumbo
Đó là một lỗi đánh máy trong các ví dụ. Các thông số phải luôn được phân tách bằng dấu chấm phẩy một cách chính xác, ngay cả khi được gấp. Việc gấp không có nghĩa là thay đổi ngữ nghĩa của một tiêu đề, chỉ để cho phép dễ đọc và tính đến các hệ thống có giới hạn độ dài dòng. –
@Remy Lebeau: Tại sao bạn không đăng nó làm câu trả lời để tôi có thể chấp nhận nó? Tôi đã cố gắng liên lạc với tác giả gốc của RFC, nhưng họ đã không trả lời cho đến nay. – BastiBen