Quoted printable utf 8

Многие типы данных, пересылаемых через email требуют "натурального" представления, то есть, 8-битный набор символов либо двоичный код (что для машины — одно и то же, только представимо для пользователя по-разному). В таком виде данные не могут быть пересланы по 7-битным почтовым протоколам, например, RFC 821, который, к тому же, ограничивает длину строки 1000 символами.

Стандартные механизмы конвертирования почты в 7-битный короткострочный формат, приемлимый для почтового транспорта, описывает поле заголовка Content-Transfer-Encoding.

В отличие от типов содержимого, увеличение множества значений Content-Transfer-Encoding не является необходимым и даже нежелательно. Но установление единого механизма конвертирования не представляется возможным. Существует противоречие между желанием эффективно "ужать" бинарные данные и желанием трансформировать данные, которые, хотя бы частично являются 7-битным текстом, так, чтобы их все-таки можно было читать. По этой причине необходимы по крайней мере 2 механизма конвертации: "читабельный" и "плотно ужимающий".

Данное поле не было определено в предыдущих стандартах. Его значение должно быть строкой без пробелов, определяющей тип конвертации, как показано ниже:

Значения не чувствительны к регистру букв, то есть, Base64, BASE64 и bAsE64 — одно и то же. Значение "7BIT" означает, что тело письма уже имеет 7-битный формат и не тренбует дополнительной обработки для пересылки по почте. Это значение полагается по умолчанию, если поле заголовка Content-Transfer-Encoding отсутствует.

Значения "8bit", "7bit" и "binary" означают, что никакой трансформации содержимого не производится. Однако, они сделаны различными для индикации того, что из себя представляет содержимое письма, и, соответственно, способа обработки, который может потребоваться для данной транспортной системы. В частности:

"7bit" означает, что данные являются текстом, имеют короткие строки и языковую кодировку US-ASCII.

"8bit" означает короткие строки, но в них могут содержаться не-ASCII символы (128-255).

"Binary" означает, что тело письма может содержать не-ASCII символы, но строки могут быть произвольной длины, т.е. слишком длинными для SMTP-транспорта, и может несоблюдаться соглашение по признаку конца строки (CRLF), принятое в SMTP-транспорте.

Хотя на первый взгляд разница в значениях Content-Transfer-Encoding может показатся неважной — ведь все они означают, что никакого преобразования нет, но четкая разметка важна для почтовых шлюзов между разными почтовыми системами, имеющими разные возможности и особенности работы, число которых со временем растет.

Спецификация на почтовый транспорт для пересылки некодированных 8-битных данных дана в RFC-1426. Однако, нет стандартизованных транспортов рочты Internet, для которых является приемлимым включение в тело письма некодированных двоичных данных. Таким образом, значение "binary" фактически не является легальным в Internet. Но в соответствии с MIME, при использовании почтовой системой транспорта, умеющего работать с двоичными данными, в случае, когда необходимо послать двоичные данные по e-mail, необходимо указать это в заголовке в поле Content-Transfer-Encoding.

Пять значений, определенных для поля Content-Transfer-Encoding, ничего не говорят о типе содержимого кроме указания алгоритма кодирования либо требований к почтовому транспорту в случае некодированных данных.

Производители почтового ПО, если необходимо, могут определить новые значения поля Content-Transfer-Encoding, но эти значения должны иметь префикс "X-" ("x-"), чтобы подчеркнуть их нестандартный характер. Однако, в отличие от типов и подтипов поля Content-Type, введение новых значений Content-Transfer-Encoding настоятельно не рекомендуется, так как может оказаться помехой для взаимосовместимости почтовых систем. Использование X-значений позволяется только как результат взаимосоглашения между взаимодействующими системами.

Если поле Content-Transfer-Encoding появляеися в заголовке тела какой-то части письма, оно применяется только к содержимому этой части. Если письмо (часть письма) имеет тип "multipart" или "message", то поле Content-Transfer-Encoding может иметь в качестве своего значения только длину символа ("7bit", "8bit" и т.д.) или "binary".

Необходимо заметить. что электронная почта является символьно-ориентированной, так что механизмы конвертации работают с данными как с потоком символов, а не битов. Если битовый поток должен быть кодирован посредством какого-либо из этих механизмов, сначала он должен быть конвертирован в 8-битный поток байтов, используя порядок битов, стандартный для сетей (старшие разряды в конце). То есть, передние биты в потоке становятся битами высшего порядка в байте. Если битовый поток оканчивается неполным байтом, недостающие разряды заполняются нулями.

Все кодирующие механизмы, определенные в спецификации MIME, кодируют любые данные в символьную форму. Так, к примеру, полагая, что тело письма (части письма) имеет поля заголовка вроде:

то это означает, что тело письма представляет собой ASCII-код base64 текстовых данных, которые в нормальном виде имеют языковую кодировку ISO-8859-1, и будут в этой языковой кодировке после декодирования.

Все множество определенных значений поля content-transfer-encoding кроме начинающихся с префикса "X-", зарезервировано в IANA для будущего использования. Частные соглашения по значениям content-transfer-encoding также настоятельно не рекомендуются.

Некоторые значения Content-transfer-encoding могут использоваться только с определенными типами (поле Content-Type). В частности, запрещено использовать любые значения кроме "7bit", "8bit", или "binary" с любым типом, рекурсивно включающим заголовки с полем Content-Type (как правило, это типы "multipart" и "message"). Все кодирования, необходимые для содержимого тел многочастного письма должны быть произведены на более низком уровне.

Замечания по ограничениям конвертации

Необходимо предотвращать случаи вложенного кодирования, когда данные проходят через алгоритм конвертации несколько раз и должны столько же раз быть декодированы, чтобы быть читаемыми. Вложенное кодирование добавляет сложностей пользовательским почтовым программам: кроме очевидных проблем с множественной конвертацией, они могут скрыть основную структуру письма. В частности, они могут привести к тому, что несколько операций по декодированию могут потребоваться только для того, чтобы определить, объекты каких типов находятся в письме. Запрещение вложенного кодирования может осложнить работу некоторых почтовых шлюзов, но это будет меньшей проблемой по сравнению с трудностями для пользовательских почтовых программ.

Читайте также:  Вконтакте моя страница полная версия для компьютера

ЗАМЕЧАНИЕ ПО ПЕРЕВОДУ КОДОВ: Конверторы quoted-printable и base64 разработаны так, что данные после их применения легко взаимоконвертируемы. Единственный нюанс, возникающий в подобной ретрансляции — признак конца строки. При конвертации из quoted-printable в base64 перевод строки должен быть заменен последовательностью CRLF. Соответственно и наоборот, но ТОЛЬКО при конвертации текстовых данных.

Механизм конвертации "Quoted-Printable"

Этот механизм предназначен для представления данных, в основном состоящих из байтов, соответствующих символам, имеющим изображение в символьном наборе ASCII. В результате данного кодирования все байты будут иметь такие значения, гарантированные от дальнейшей модификации почтовым транспортом. Если конвертируемые данные в основном представляют собой ASCII-текст, то конечная их форма остается узнаваемой и читаемой для человека. Тело, полностью состоящее из ASCII-символов, также может быть конвертироавано в Quoted-Printable, что гарантирует его содержимому целостность при прохождении через всякие шлюзы, в которых происходит языковая перекодировка символов или преобразование концов строк и т.д.

В Quoted-Printable байты должны быть рпедставлены в соответствии со следующими правилами:

ПРАВИЛО #1: (обычное 8-битное представление). Каждый байт, кроме тех, которые используются для обозначения конца строки, может быть представлен с помощью двух шестнадцатиричных цифр, предворяемых знаком "=". При написании шестнадцатиричных цифр с A по F должны использоваться заглавные буквы. Кроме тех случаев, когда нижеследующие правила позволяют альтернативное кодирование, данное правило является обязательным.

ПРАВИЛО #2: (Буквенное представление). Байты с десятичным значением с 33 по 60 и с 62 по 126 МОГУТ быть представлены ASCII-символами, соответствующими этим значениям (с ‘!’ по ‘ ‘ по ‘

ПРАВИЛО #3: (Пробелы): Байты со значениями 9 и 32 МОГУТ быть представлены как ASCII-символы "Табуляция" и "Пробел", но НЕ ДОЛЖНЫ быть представлены так в конце строки. Везде, где они представлены соответствующими ASCII-символами, за ними должен следовать символ, имеющий графическое изображение (печатный символ). В конце же строки символы табуляции и пробела должны быть представлены в соответствии с правилом #1, так как некоторые почтовые транспорты могут убирать пробелы в конце строки.

ПРАВИЛО #4: (Конец строки): Конец строки в тексте письма должен быть представлен (в соответствии с RFC 822) последовательностью CRLF. Так как в каноническом представлении текста не требуется визуального отображения символов конца строки, в Quoted-Printable не используется видимых символов для обозначения конца строки. Для представления бинарных данных более предпочтительной является кодировка base64.

Необходимо заметить, что многие реализации почтовых программ могут кодировать по-своему. В частности, при представлеии текста в системах, использующих другие соглашения по обозначению конца строки (отличные от CRLF). Такие реализации недопустимы, и генерация концов строки должна быть стандартизована везде, чтобы не требовалось распознавать, используется ли какое-либо альтернативное представление.

ПРАВИЛО #5: (Мягкий конец строки): В соответствии с Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется ‘мягкий’ перевод строки, представимый знаком равенства. Например, если исходная строка имела вид:

то в Quoted-Printable encoding он может быть представлена следующим образом:

Это обеспечивает механизм восстановления исходной длины строки пользовательским почтовыи агентом.

Поскольку символ дефиса ("-") представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов "=_", которая никогда не появляется в теле, закодированном в Quoted-Printable.)

ЗАМЕЧАНИЕ: Quoted-Printable представляет собой нечто вроде компромисса между читабельностью и сохранностью при пересылке. Тела в Quoted-Printable будут надежно защищены при прохождении многих почтовых шлюзов, но могут быть не очень хорошо переданы через некоторые шлюзы, использующие трансляцию в EBCDIC. (Теоретически, EBCDIC-шлюз должен кодировать тело из quoted-printable в base64 и затем декодировать обратно, но таких шлюзов пока не существует). Единственный способ добится действительно надежной транспортировки через EBCDIC-шлюз — экранировать ASCII-символы

в соответствии с правилом #1.

Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.

Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как "=0D=0A", в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.

Синтаксис данных в quoted-printable описывается следующим образом:

Механизм конвертации Base64

Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлит встроенного "чистого" текста.

Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ "=" используется для обозначения функции спец. обработки).

ПРИМЕЧАНИЕ: этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 — часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.

Читайте также:  Триколор тв сибирь настройка антенны самостоятельно

Процесс кодирования преобразует 4 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.

Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта (".", CR, LF) и для синтаксиса вложенных тел MIME ("-").

Выходной поток (закодированные бфайты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.

Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель ‘=’. Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи: (1) входной поток как раз оканчивается 24-битной группой. В таком случае, выходной поток будет оканчиваться четырьмя символами Base64 без символа ‘=’; (2) хвост входного потока имеет длину 8 бит. Тогда в конце выходного кода быдут два символа Base64, с добавлением двух символов ‘=’; (3) хвост входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ ‘=’.

Т.к. символ ‘=’ является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но такой гарантии нет, если число переданных битов кратно 24.

Любые бессмысленные последовательности в коде Base64 вроде "=====" должны быть игнорированы.

Если кодируемый текст не находится в канонической форме. то перед конвертацией в Base64 необходимо сначала все концы строк заменить стандартной последовательностью CRLF. Предпочтительнее эту функцию встроить в кодировщик Base64, нежели заставлять пользователя производить предварительную канонизацию текста другими средствами.

Нет нужды экранировать вложенные тела внутри многочастного тела (multipart) при кодировании его в Base64, так как в коде Base64 отсутствует символ ‘-‘.

I am trying to read email with imaplib. I get this mail body:

That is Quoted-printable encoding.
I need to get utf-8 from this. It should be Добрый день!

I googled it, but it is too messy with Python’s versions. It is already unicode in Python 3, I cann’t use .encode(‘utf-8’) here.

How can I change this to utf-8 ?

1 Answer 1

The quopri module can convert those bytes to an unencoded byte stream. You need to then decode those from whatever character set they’re in, then encode back to utf-8 .

Часто при переносе контактов с одного смартфона на другой пользователи выбирают такой способ, как экспорт телефонной книги в специальный файл и последующий импорт данных из него на конечном устройстве. Контактная информация при выгрузке сохраняется в текстовом формате vCard в файле, имеющем расширение VCF. Помимо имени и телефона записи VCF могут содержать и другие данные абонентов, например, адрес, фото, электронную почту, дату рождения и массу прочих параметров. Т. е. это своего рода каталог электронных визитных карточек людей.

Так как информация в VCF-файле хранится в текстовом формате, то для ее просмотра и редактирования можно использовать обычные текстовые редакторы, в том числе установленные на стационарном компьютере или ноутбуке. Возможность открыть файл контактов VCF и внести в него правки зачастую бывает полезна в тех случаях, когда требуется изменить какие-то данные или объединить несколько адресных книг в одну. Какие же программы лучше использовать для этих целей? Давайте разбираться.

Блокнот

Приложение Блокнот, имеющееся на любом компьютере с ОС Windows, вполне пригодно для чтения файлов с расширением VCF. Попробуем открыть с его помощью файл contact.vcf, в который мы выгрузили контакты c телефона на базе Android.

Открываем программу и просто перетаскиваем на нее файл. На фото ниже видим, что у нас получилось.

Данные каждого контакты представлены в виде текстового блока, начинающегося с BEGIN:VCARD и заканчивающегося END:VCARD. Внутри находятся атрибуты, например, N – структурированное представление имени (фамилия, имя, отчество через точку с запятой), FN – имя единой строкой, CELL – сотовый телефон. Это лишь основные атрибуты любого контакта, полный же их перечень мы приводить не будем. При желании вы можете ознакомиться с ними на странице https://ru.wikipedia.org/wiki/VCard.

Но, как мы видим, у нас есть небольшая проблема. Вместо кириллических букв фигурирует последовательность символов типа =D0=BA=D0=BE=D0=BC=D0=B8=D1=81=D1=81=D0=B0=D1=80.

В таком виде будут отображаться все имена, записанные в контактах на русском языке, т.е. прочесть их просто так не получится. А все дело в том, что файлы VCF по умолчанию сохраняются в кодировке ASCII, и все русские буквы при выгрузке кодируются комбинацией символов ASCII для обеспечения безопасности передачи информации по сети. Шифрование осуществляется методом Quoted-printable, о чем нам и говорит запись ENCODING=QUOTED-PRINTABLE, предваряющая закодированный русскоязычный текст.

Подробнее о Quoted-printable вы можете почитать в Википедии. Мы же сразу приведем готовую таблицу кодирования кириллицы.

Однако встает вопрос, каким образом автоматически расшифровать все символы без ручного поиска/замены. Здесь нам нужен соответствующий инструментарий, которого в Блокноте нет, но зато он присутствует в более продвинутом текстовом редакторе. К нему и перейдем.

Читайте также:  Почему гудит монитор компьютера

Notepad++

Итак, речь идет о приложении Notepad. Скорее всего оно уже установлено на вашем компьютере, если же нет, то скачиваем и устанавливаем его. Далее открываем с помощью Notepad наш vcf-файл и видим, что русские имена показываются так же некорректно, как и в Блокноте.

Чтобы декодировать определенный кусок текста, выделяем его мышью и переходим в меню Плагины – MIME Tools – Quoted-printable Decode.

Чудесным образом набор нечитабельных знаков превращается в слово на русском языке.

Если после произведенных действий вместо русских имен вы увидите кракозябры, то следует предварительно изменить кодировку документа c ANSI на UTF-8. Для этого необходимо зайти в меню «Кодировки» и выбрать пункт «Преобразовать в UTF-8».

Казалось бы, теперь можно выделить все содержимое файла (клавиши Ctrl+A), и одним кликом мыши раскодировать все контакты. Но тут есть одна загвоздка. Декодированию мешают знаки «равно» в записи CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE. Видимо при расшифровке они принимаются за символы ASCII. Выход из ситуации простой. Нажимаем сочетание клавиш Ctrl+H, открывая тем самым окно для массовой замены. В поле «Заменить» вписываем CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE, а в поле «Заменить на» этот же текст, но без знаков «=», т.е. CHARSETUTF-8;ENCODINGQUOTED-PRINTABLE. Кликаем по кнопке «Заменить все».

Все, мы избавились от ненужных «равно» и можно приступить к массовому декодированию. Выделяем весь текст и жмем Quoted-printable Decode, после чего все контакты приобретают нормальный вид.

Теперь осталось вернуть на место знаки «равно» в записи CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE. Для этого делаем замену, обратную той, что мы производили выше.

Если мы хотим сделать файл контактов VCF пригодным для импорта в телефон, необходимо закодировать русский текст обратно символами ASCII. Делается это с помощью того же раздела меню Плагины – MIME Tools, но уже следует выбрать пункт Quoted-printable Encode. Помимо этого необходимо вернуть документу кодировку ANSI (пункт меню Кодировки – Преобразовать в ANSI).

Outlook

В системе Windows достаточно «своих» приложений для работы с телефонными книгами, которые могут открывать файлы с расширением VCF. Вот только у всех у них, как правило, есть два недостатка: первый – из файла с несколькими контактами они читают только один контакт, второй – возникают проблемы с отображением русских имен (вместо букв появляются иероглифы). Обе этих проблемы актуальны для приложения Outlook, входящего в пакет Microsoft Office. Чтобы загрузить в программу контакты из VCF-файла, щелкаем по нему правой кнопкой мыши и выбираем Открыть с помощью – Outlook.

В нашем случае из адресной книги прочитался только первый контакт, а так как он был на русском языке, то отобразился в виде кракозябр.

Для исправления ситуации нужно повозиться с кодировками, например, в том же Notepad.

Контакты Windows

В Windows есть штатный функционал для работы с адресными книгами. Чтобы с ним познакомиться, перейдем в папку C:/Users/Имя_пользователя/Contacts.

Здесь нажмем кнопку «Импорт» и в открывшемся окне выберем пункт «Визитная карточка (файл VCF)».

Теперь снова жмем «Импорт», после чего все контакты начнут импортироваться по одному и сохраняться в отдельные файлы.

Чтобы просмотреть любую карточку, просто дважды кликаем по ней.

Файлы можно перевести обратно в VCF с помощью кнопки «Экспорт», но теперь все контакты будут по-отдельности, и это очень неудобно. К тому же, здесь также имеются проблемы с отображением кириллицы.

Nokia Suite

Фирменная утилита от компании Нокиа. Скачать ее можно с официального сайта Майкрософт по адресу https://www.microsoft.com/en-us/download/details.aspx? >

Выбираем файл VCF и кликаем «Открыть». К сожалению, из всей телефонной книги программа по умолчанию выдергивает только первый контакт, игнорируя все остальные. Зато с отображением текстов на русском проблем нет, все транслируется корректно.

vCardOrganizer

Программа от сторонних разработчиков, прекрасно адаптированная для работы с файлами VCF. На наш взгляд, самый удобный инструмент для обработки контактов в формате vCard, но, к сожалению, платный. Скачать free-версию приложения можно по адресу http://www.micro-progs.com/vcardorganizer/. После загрузки распаковываем архив и запускаем программу.

Перетаскиваем файл на рабочее поле и дважды кликаем по новому пункту списка.

Откроется новое окно, в котором представлена вся информация по абонентам адресной книги. С помощью стрелок можно переключаться между контактами, также доступно редактирование и сохранение данных (для этого нужно приобрести полную версию стоимостью 25 долларов), в том числе на русском языке.

Контакты Google

Ну и, наконец, последний в данном обзоре инструмент, который позволяет открывать и просматривать файлы в формате VCF. Это «Контакты Google». Чтобы воспользоваться сервисом, заходим в свой аккаунт Гугл, нажимаем сверху плитку «Приложения Google» и кликаем по значку «Контакты».

Можно и сразу перейти на нужную страницу, введя в строке браузера адрес https://contacts.google.com/. Здесь на панели слева выбираем пункт «Импортировать».

В появившемся окне жмем «Импортировать из файла CSV или vCard».

После этого будет предложено перейти к старой версии Google Контактов, так как новая пока не поддерживает импорт. Переходим по ссылке.

Далее кликаем слева по строке «Импорт контактов…», а потом выбираем файл для импорта.

Как только операция завершится, контакты отобразятся в виде списка. С ним можно делать все, что угодно – изменять существующие данные, добавлять новых людей или удалять какие-то позиции. После внесения корректировок не составит труда экспортировать список в тот же файл VCF, пригодный для импорта в адресную книгу любого смартфона.