EML — Base64: Accented UTF-8 Body
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
From: Maya Chen <maya@brightside.example>
To: Sam Rivera <sam@meridiansupply.example>
Subject: Confirmation de la degustation (SAMPLE)
Date: Sat, 07 Feb 2026 09:00:00 -0800
Message-ID: <p7-cte-b64-accented@brightside.example>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Qm9uam91ciBTYW0sDQoNCkxlIGNhZmUgQnJpZ2h0c2lkZSBjb25maXJtZSBsYSBkZWd1c3RhdGlv
bjogY3JlbWUgYnJ1bGVlLCBjYWZlIGZpbHRyZSwgdGhlLg0KUHJpeCB1bml0YWlyZSA6IDQsNTAg
4oKsIOKAlCBxdWFudGl0ZSA6IDEyLiBSZWZlcmVuY2UgOiDCqyBTQU1QTEUtMDE0OCDCuy4NCk1l
cmNpIHBvdXIgdm90cmUgcmVwb25zZSByYXBpZGUsIGMnZXN0IHRyZXMgYXBwcmVjaWUuDQoNCkNv
cmRpYWxlbWVudCwNCk1heWENCg==
Specifications
- Wave
- p7
- Seed
- 20260807
- Charset
- utf-8
- Decoded Bytes
- 247
- Line Endings
- CRLF (RFC 5322)
- Twin Decodes Identically
- true
- Content Transfer Encoding
- base64
- Encoded Lines
- 5
- Wrap Column
- 76
Testing contract
Expected to pass- Scenario
- Decode a 76-column base64 utf-8 body and use it as the reference result for its quoted-printable twin.
- Expected result
- Decoded output is 247 octets identical to the quoted-printable twin, including trailing whitespace and CRLF breaks.
What is a .eml file?
An EML file is a single email message stored in the RFC 822 / MIME format — plain-text headers (From, To, Subject, Date, Message-ID) followed by the body, which may be plain text, HTML, or a multipart structure with alternative bodies and file attachments encoded in base64.
How to use this file
Use an example EML to test email header parsing, MIME decoding, HTML-part handling, attachment extraction, and EML-to-other-format conversion.
How to use this file for testing
“EML — Base64: Accented UTF-8 Body” is a deterministic Novus Examples fixture for Email parsing, Encoding detection, Conversion testing. Standards-compliant RFC 822 messages — plain, multipart text+HTML, and with an attachment — plus an MBOX mailbox, for testing header parsing, MIME decoding, attachment extraction, and mailbox splitting.
Documented properties for this file: seed 20260807 · CRLF (RFC 5322). Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Email fixtures use fixed dates, message IDs, and MIME boundaries so runs are reproducible, and every address is fictional. Test header parsing, MIME decoding, attachment extraction, and EML/MBOX conversion against the documented structure.
Code examples
from email import policy
from email.parser import BytesParser
msg = BytesParser(policy=policy.default).parse(open("cte-base64-accented-utf8.eml", "rb"))
print(msg["subject"], msg["from"])Related files
- emlEML — Attachment With No Filename At AllAn attachment with a bare Content-Disposition: attachment and no name in either header. A client has to invent a filename, and the extension it invents decides whether the saved file opens as a spreadsheet or as unknown binary.
- emlEML — CID Inline ImageA multipart/related message with an HTML body referencing a CID-inline PNG — for email client and MIME parser tests.
- emlEML — HTML Only (No Plain Alternative)A single-part text/html email with no text/plain alternative — edge case for clients that require multipart/alternative.
- emlEML — Identical Image, Inline and AttachedThe same 16x16 PNG appears twice with the same filename: once inline with a Content-ID, once as a plain attachment. Deduplicating by filename or by content hash collapses the pair and loses one of them, which is how an attachment silently disappears.
- emlEML — message/rfc822 Forward of a Multipart MessageA forward that embeds the whole original message, headers and all, as a message/rfc822 part — and that original is itself a multipart with its own attachment and threading headers. Extractors routinely stop at the message/rfc822 boundary and miss the nested file.
- emlEML — multipart/alternative in Reverse Preference OrderThe alternative parts are ordered richest-first, the opposite of what RFC 2046 requires. A client that blindly takes the last part shows plain text here and HTML everywhere else, which is exactly the intermittent-looking bug this fixture pins down.
Generated by generation/email_p7.py. Free for any use, no attribution required — license.