Дело о некорректной кодировке

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

Так бы начинался запутанный детективный роман. В службе поддержки «детективные истории» клиентов специалисты разбирают каждый день и иногда кажется, что решение обращения потребует больших усилий, но бывает, что решение приходит само так быстро и просто, что удивляешься его легкости!

На днях столкнулся с проблемой, которая заключалась в том, что сценарий «Агент рассылки писем по обращениям» (входит в модуль «Обращения граждан») рассылал письма в непонятной кодировке. Если быть точнее, то всегда присылал один и тот же текст письма:

РПаЎ±б

Первоначально специалист службы поддержки выдвинул предположение, что причина в почтовом сервере (возможно, по каким-то причинам сервер неверно воспринимал тело отправленного письма). Почтовым сервером оказался yandex.ru. Манипуляции с форматом письма не дали никаких результатов (изначально сценарий отправлял письма в текстовом формате, но изменение формата на html результата не дал). В итоге решение обращения зашло в тупик, поэтому к его решению подключился я.

Открыв сценарий через утилиты разработчика, я нашёл строчку, которая отвечает за отправку письма. Письмо отправлялось с помощью функции MailQuietSend(), одним из входных параметров которой является текст письма (переменная Text):

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

Первым же результатом поиска стала строчка № 73:

Далее в тексте еще несколько раз встречалось упоминание переменной Text, но в основном в переменной заменялись одни символы на другие с помощью функции Replace(), поэтому эти строчки меня не заинтересовали.

Возвращаясь к строчке 73, я решил выяснить, какой именно файл считывается в переменную. Все тот же поиск по тексту сценария указал на строчку 71 и 72 (они видны на скриншоте выше). Эти строчки говорят о том, что в переменной FileName находится путь до экспортированного документа, который находится в переменной Document. В итоге провернув аналогичные манипуляции с поиском переменных, я вышел к самым истокам. Истоком оказались три переменные RegisteredTextDocID, DeadlineChangedTextDocID и ClosedTextDocID, которые заполнялись значениями входных параметров сценария.

Справка по сценарию (кнопка «Примечание» на карточке сценария) подсказала, что:

●    RegisteredTextDocID - ИД документа, из текста которого будет формироваться текст письма при регистрации обращения;

●    DeadlineChangedTextDocID - ИД документа, из текста которого будет формироваться текст письма при изменении срока решения обращения;

●    ClosedTextDocID - ИД документа, из текста которого будет формироваться текст письма при закрытии обращения.

Подробно изучив ту же справку, я натолкнулся на такую строчку: «Текст письма формируется из текста документа, ИД которого указано в соответствующем параметре. Документ должен быть текстовым». Причина этого ограничения крылась в функции ФайлСчитать(), с помощью которой заполнялась переменная Text (строчка 71) – дело в том, что функция умеет считывать только текстовые файлы, если же файл имеет другой формат, то функция всё равно воспринимает его как текстовый и просто считывает символы файла (для наглядности, откройте файл с расширением jpeg или doc в блокнотике).

Исходя из выше описанного, я предположил, что причина в документах, ИД которых передаются в качестве входных параметров сценария, а если быть точнее, то вместо текстовых документов используются какие-то другие.

Чтобы выяснить, верно ли предположение, у клиента были запрошены документы, которые передавались в качестве параметров сценарию. Как и предполагалось, клиент прислал документ MS Word. Открыв этот документ с помощью блокнотика, я увидел знакомый набор символов:

РПаЎ±б

Клиенту была отправлена рекомендация – использовать текстовый документ, обращение было успешно закрыто.