{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/email-subject-unicode-round-trip","id":"email-subject-unicode-round-trip","slug":"email-subject-unicode-round-trip","title":"Round-Trip Unicode Email Subjects Through the Sending Path","description":"Detect header encoding corruption separately from visual subject truncation. A synthetic Unicode header fixture with decoding assertions.","dek":"Detect header encoding corruption separately from visual subject truncation. A synthetic Unicode header fixture with decoding assertions.","category":"Email Production","topics":["Migma","email marketing","email production"],"publishedAt":"2026-09-18","updatedAt":"2026-09-18","lastVerifiedAt":"2026-09-18","readingMinutes":4,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma: Send an email campaign","url":"https://docs.migma.ai/campaigns/send-campaign?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-subject-unicode-round-trip"},{"title":"Migma: Email Preflight","url":"https://docs.migma.ai/email-editor/email-preflight?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-subject-unicode-round-trip"},{"title":"IETF RFC 2047: Non-ASCII mail headers","url":"https://www.rfc-editor.org/rfc/rfc2047?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-subject-unicode-round-trip"},{"title":"IETF RFC 6532: Internationalized email headers","url":"https://www.rfc-editor.org/rfc/rfc6532?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-subject-unicode-round-trip"}],"wordCount":761,"body":"Test the decoded Subject header as well as the visible inbox label when localizing a Migma campaign. A subject can be shortened by an inbox display without being corrupted, while an encoding error can change the underlying text even when the draft preview looked correct.\n\n> **Editorial disclosure:** Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 18, 2026.\n\n> **Affiliation disclosure:** Marketing Wiki’s commissioning maintainer also maintains Migma. This guide is published directly by automation without independent review.\n\nMigma's [campaign workflow](https://docs.migma.ai/campaigns/send-campaign?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-subject-unicode-round-trip) includes subject configuration. Its [Preflight guide](https://docs.migma.ai/email-editor/email-preflight?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-subject-unicode-round-trip) recommends a received test and notes that draft test emails use Migma's sender. We recommend adding a transport round-trip check on the actual final sending path when subjects contain non-ASCII text. A draft test is useful evidence for its own path, not proof about a different exporting or sending platform.\n\nTwo standards explain why raw bytes and displayed text differ. [RFC 2047](https://www.rfc-editor.org/rfc/rfc2047?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-subject-unicode-round-trip) defines encoded words for mail headers. [RFC 6532](https://www.rfc-editor.org/rfc/rfc6532?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-subject-unicode-round-trip) permits UTF-8 in internationalized message headers under the relevant transport requirements. Neither establishes which route your provider uses for a particular message.\n\n## Keep three versions of the subject\n\nRecord the approved Unicode string, the raw received Subject field and the decoded result. Preserve header folding in the raw artifact, while comparing the decoded text as text. A long encoded field is not itself proof of an overly long user-visible subject.\n\nUse a synthetic fixture with ordinary accents and a non-Latin script:\n\n```text\nCafé invitation — 東京\n```\n\nThe phrase is a technical fixture, not translated campaign copy. Have a fluent reviewer approve real localized wording separately. If your campaign uses emoji or combining marks, add examples that match that actual requirement instead of assuming the fixture covers every Unicode case.\n\n## Run an offline encoding check first\n\nThis small Python exercise uses the standard library to encode and decode the fixture through an RFC 2047 representation:\n\n```python\nfrom email.header import Header, decode_header, make_header\n\nsubject = \"Café invitation — 東京\"\nwire = Header(subject, \"utf-8\").encode()\nrestored = str(make_header(decode_header(wire)))\nassert restored == subject\n```\n\nThe assertion was run locally for this article. It proves the example's library round-trip, not delivery through Migma or any email provider. Keep that scope explicit in the test report.\n\nDo not paste the encoded output into an ordinary subject-entry field unless the sending API specifically requires it. A system that expects Unicode text may encode the supplied string again. The result can expose encoding syntax to readers instead of the intended words.\n\n## Compare the received result, not a screenshot alone\n\nIn an authorized seed test, retrieve the raw message from the mailbox. Decode the Subject with a mail-aware parser and compare it with the approved string. If they differ, preserve both values and identify the first boundary where the difference appears: draft, export, provider request or received message.\n\nUse a discrepancy sheet with these columns:\n\n| Approved text | Decoded received text | Visible inbox label | Classification |\n| --- | --- | --- | --- |\n| Full fixture | Exact match | Shortened at the edge | Display truncation to review |\n| Full fixture | Replacement character appears | Damaged character visible | Encoding or transformation issue |\n| Full fixture | Encoding syntax remains | Syntax visible | Possible double encoding |\n| Full fixture | Different punctuation | Looks nearly identical | Copy transformation requiring a decision |\n\nThese are diagnostic examples, not observed failures in a named product. A parser result should guide the investigation rather than become an unsupported diagnosis of the provider.\n\n## Decide how strict equality should be\n\nFor an approved marketing subject, start with exact string equality. If your pipeline deliberately normalizes Unicode, document that transformation and compare against the approved normalized value. Do not silently strip accents or punctuation to make a test pass.\n\nVisual similarity is not an adequate substitute. Conversely, byte-for-byte equality of whole raw headers may be too strict because folding and valid encodings can differ while preserving the same decoded text. Keep the acceptance condition tied to the reader-facing meaning and your documented transport contract.\n\nAfter repairing a transformation, repeat the final-path test and inspect the inbox at the relevant widths. The [preheader extraction guide](/articles/email-preheader-extraction-check) concerns preview text from the body; this fixture concerns header transport. No live email, provider API or Migma account was used in this research. Start with one accented subject your team already sends and establish which stage owns its final encoding."}