Искажение UTF-8 в Subject Symfony Mailer 8.0: C3 B6 → C3 3F

Да, в Symfony Mailer и Mime 8.0.x есть регрессия с кодировкой UTF-8 в заголовке Subject при Q-кодировании: продолжения multibyte-символов вроде ö (C3 B6) заменяются на 3F (?), несмотря на правильный UTF-8 ввод и настройки mb_internal_encoding('UTF-8'). Это похоже на известную проблему в GitHub issue #58592, где word-by-word кодирование в AbstractHeader::createPhrase() ломает UTF-8 символы из-за обработки пробелов по RFC 2047. Ручное Base64-кодирование (=?UTF-8?B?...?=) полностью решает вопрос — используйте его как временный фикс перед подачей issue.

Содержание

• Проблема искажения кодировки UTF-8 в заголовке Subject Symfony Mailer
• Симптомы: почему C3 B6 превращается в C3 3F при кодировке utf 8
• Анализ входных данных и окружения (PHP 8.4, mb_internal_encoding UTF-8)
• Известные проблемы кодирования utf 8 в Symfony Mime
• RFC 2047 и Q-кодирование: таблица кодирования utf 8 для заголовков
• Workaround и решения: ручное Base64 вместо Q в charset utf 8
• Рекомендации по отчету о баге и проверке конфигурации
• Источники
• Заключение

Проблема искажения кодировки UTF-8 в заголовке Subject Symfony Mailer

Представьте: вы пишете идеальный UTF-8 заголовок с умлаутами и эмодзи — “Waffelhörnchen mit Sahne 🍴”. Всё проверено, hex-дамп сияет C3 B6 для ö, F0 9F 8D B4 для вилки. А Symfony Mailer 8.0.x выдаёт =?utf-8?Q?Waffelh=C3=3Frnchen?=? Только первый байт цел, а продолжение — сплошные ?. Звучит знакомо?

Это не ваша ошибка с кодировкой UTF-8. Mime-компонент в Symfony 8.0 режет заголовки на слова, кодируя каждое отдельно по RFC 2047 Quoted-Printable (Q). Multibyte-символы страдают: если граница слова попадает внутри последовательности (байты 80-BF), Mime подставляет ? вместо mb_substitute_character(63). Ваш SMTP-транспорт просто передаёт искажёнку дальше.

Почему именно в 8.0.x? Регрессия от оптимизаций в Symfony\Component\Mime\Header\AbstractHeader. В старых версиях (5.x) это реже всплывало, но с PHP 8.4 и длинными UTF-8 символами (эмодзи!) — бум. И да, setMaxLineLength(998) не спасает: проблема в разбиении, не в длине строки.

Симптомы: почему C3 B6 превращается в C3 3F при кодировке utf 8

Ваш пример — классика. Возьмём hex до:

45697365726b756368656e202d2057616666656c68c3b6726e6368656e206d6974205361686e65
"Eiserkuchen - Waffelhörnchen mit Sahne"

Waffelhörnchen содержит C3 B6 (ö). После $message->subject():

Subject: Eiserkuchen - =?utf-8?Q?Waffelh=C3=3Frnchen?= mit Sahne

C3 B6 → C3=3F. То же с Plätzchen (C3 A4 → C3=3F), эмодзи F0=9F=8D=B4=3F. Только первый байт (C0-DF для 2-байтных) выживает, остальное — замена на ?.

Другие признаки:

• Email::toString() повторяет искажение.
• Адресные заголовки (From/To) страдают аналогично, если имя с пробелами: =?utf-8?Q?F=C3=A4bien?= =?utf-8?Q?P=C3=B6tencier?= (двойные пробелы!).
• HTML-тело письма в норме — проблема только в unstructured headers вроде Subject.

Почему не полный крах? Mime проверяет валидность UTF-8, но при Q-кодировании encodeWord() в RfcComplianceTrait рвёт последовательность на границах слов. Результат: клиенты вроде Thunderbird показывают “Waffelh?rnchen”.

А теперь вопрос: это баг или фича? Спойлер: баг.

Анализ входных данных и окружения (PHP 8.4, mb_internal_encoding UTF-8)

Ваша среда идеальна: PHP 8.4 усилил строгость multibyte, но не виноват. Проверим шаг за шагом.

Hex-анализ входа:

Всё валидно: mb_check_encoding($subject, 'UTF-8') вернёт true. mb_internal_encoding('UTF-8') и default_charset = 'UTF-8' — на месте. mb_substitute_character(63) подставляет ?, но не должно!

Трассировка в Mime:

1. Email::subject() → Headers::addTextHeader('Subject', $subject).
2. TextHeader::setBody() → encodeHeaderValue() разбивает на слова.
3. Каждое слово → quotedPrintableEncode(): байты >127 в =XX, но если внутри multibyte — обрезка.
4. Результат: C3=3F вместо C3=B6.

PHP 8.4 не меняет логику mb_*, но строже с ошибками. Тест: echo bin2hex($subject) — чистый UTF-8. Проблема в Symfony.

Известные проблемы кодирования utf 8 в Symfony Mime

Вы не одиноки. GitHub issue #58592 описывает то же в From: “Fab=C3=AFen P=C3=B6tencier” из-за двойных пробелов (linear-white-space по RFC). Разработчик 0xb4lint подтвердил: AbstractHeader::createPhrase() кодирует слово за словом, ломая кодировку UTF-8.

PR #58593 предлагал фикс для 5.4 (улучшить обработку пробелов), но закрыли как “not planned”. В 8.0.x регрессия усилилась: эмодзи и длинные умлауты чаще попадают под нож.

Другие тикеты:

• #50345: Похожие артефакты в именах.
• Форумы: упоминания symfony mailer + “UTF-8 corruption” в Subject.

В Symfony docs по Mailer нет упоминания конфига для charset utf 8 в headers — ожидается авто. Но для 8.0 — не срабатывает стабильно.

RFC 2047 и Q-кодирование: таблица кодирования utf 8 для заголовков

RFC 2047 (§6.2) требует: слова разделять linear-white-space (пробелы/LF), кодировать Q/B. Q: =XX для небезопасных байт.

Таблица кодирования UTF-8 в Q (пример для ö):

Проблема: если слово “hörn” → “h=C3=B6rn”, но Mime режет “hörn” → “h” + “örn” → первый байт C3 в слове, B6 — в следующем → ?. RFC позволяет B-кодирование для сложных случаев — вот почему Base64 спасает.

Правило: >75 символов или небезопасные — B-auto. Но в 8.0 Q доминирует ошибочно.

Workaround и решения: ручное Base64 вместо Q в charset utf 8

Ваш фикс топ:

$subject = 'Eiserkuchen - Waffelhörnchen mit Sahne 🍴Plätzchen-Reste-Kuchen...';
$encoded = '=?UTF-8?B?' . base64_encode($subject) . '?=';
$message->getHeaders()->remove('Subject');
$message->getHeaders()->addTextHeader('Subject', $encoded);

Работает на 100%: Base64 глотает весь UTF-8 целиком, без разбивки. Тест: Email::toString() выдаст чистый =?UTF-8?B?RWlzZXJrdWNoZW4gLSAuLi4=?=.

Другие хаки:

• Укоротить Subject <60 символов (реже режется).
• Заменить пробелы на - или (но linear-white-space!).
• Патч Mime: переопределить TextHeader::encodeHeaderValue() для force B.

Для продакшена — wrapper:

function safeSubject(Email $email, string $subject): void {
 $encoded = '=?UTF-8?B?' . base64_encode($subject) . '?=';
 $email->getHeaders()->addTextHeader('Subject', $encoded);
}

Коротко, надёжно. Q красивее для ASCII, но с UTF-8 байт — нет.

Рекомендации по отчету о баге и проверке конфигурации

Конфиг не нужен — Email::subject() должен работать из коробки. Но для issue:

1. Минимальный repro (composer req symfony/mailer mime:^8.0 php:^8.4).
2. Hex-дампы до/после.
3. dd($message->getHeaders()->get('Subject')->getBody()).
4. Версии: composer show symfony/mime.

Подайте в Symfony repo — сослаться на #58592. Nicolas Grekas или 0xb4lint отреагируют быстро.

Пока: Base64. Или downgrade на 7.x, если критично.

Источники

1. Symfony Issue #58592 — Проблема искажений UTF-8 в заголовках From из-за linear-white-space: https://github.com/symfony/symfony/issues/58592
2. Symfony PR #58593 — Фикс для AbstractHeader и проблем кодирования multibyte символов: https://github.com/symfony/symfony/pull/58593
3. Symfony Mailer Documentation — Руководство по Email, заголовкам и транспорту SMTP: https://symfony.com/doc/current/mailer.html
4. RFC 2047 — Стандарт MIME encoded-word для заголовков с кодировкой UTF-8: https://datatracker.ietf.org/doc/html/rfc2047

Заключение

Регрессия в Symfony Mime 8.0.x реальна: Q-кодирование рвёт UTF-8 символы в Subject на границах слов, превращая C3 B6 в C3 3F. Похоже на #58592, фикс нужен в AbstractHeader. Используйте ручной Base64 — это надёжно и соответствует RFC. Подайте issue с вашими дампами: сообщество оценит. А пока письма полетят без артефактов. Удачи с багхантингом!