При отправке текстовых файлов через почтовые компоненты в 1С 7.7 часто возникает ситуация, когда получатель жалуется на то, что все содержимое файла слилось в одну строку. Давайте разберемся, почему это происходит и как заставить почтовые системы сохранять структуру вашего файла в первозданном виде.
Основная причина заключается в стандартах передачи данных через протоколы SMTP и MIME. Когда вы отправляете файл как вложение типа text/plain, почтовые серверы по пути следования письма имеют право проводить «нормализацию» содержимого. Исторически сложилось так, что стандартным символом переноса строки в сетевых протоколах является LF (Line Feed, код 10). В Windows стандартом является пара CRLF (Carriage Return + Line Feed, коды 13 и 10). Почтовые узлы могут автоматически «исправлять» ваш CRLF на LF, из-за чего старые версии редакторов, таких как Блокнот, перестают видеть разрывы строк.
Прежде всего, важно убедиться, что вы правильно формируете строки в 1С. Распространенной ошибкой является попытка вручную склеить символы в неверном порядке. В 1С 7.7 для формирования переноса строки используйте системную константу РазделительСтрок. Она гарантированно подставляет корректную пару символов для текущей операционной системы.
Если вам нужно принудительно задать перенос, используйте следующую конструкцию:
// Правильный способ формирования строк в 1С 7.7
ТекстФайла = "Строка 1" + РазделительСтрок + "Строка 2";
Запомните, что последовательность должна быть 13 (CR) + 10 (LF), а не наоборот. Использование РазделительСтрок избавляет вас от необходимости помнить коды ASCII.
Чтобы почтовый сервер перестал «улучшать» ваш файл, нам нужно сделать так, чтобы он воспринимал его не как простой текст, а как бинарный поток данных. Давайте проанализируем доступные методы:
UTF-8 многие почтовые библиотеки автоматически меняют способ передачи вложения на BASE64. Это предотвращает автоматическую конвертацию символов переноса, так как сервер видит уже закодированный бинарный поток.v7plus.dll или DialMail) поддерживает выбор метода передачи, всегда выбирайте BASE64. Это самый надежный способ передачи файлов любого типа, при котором исходная структура байтов остается неизменной.text/plain на application/octet-stream. Это сигнал для почтового клиента, что файл не является текстовым документом, подлежащим нормализации, что чаще всего решает проблему со «склеиванием» строк.Если вы подозреваете, что файл «портится» при передаче, не спешите винить 1С. Откройте полученный файл в профессиональном редакторе, например, FAR Manager или Notepad++. Эти программы умеют корректно отображать оба типа переносов строк (CRLF и LF). Если в этих программах файл выглядит правильно, значит, проблема только в устаревшем текстовом редакторе Блокнот у получателя.
Если же данные действительно приходят в одну строку даже в профессиональных редакторах, обязательно проверьте настройки вашего почтового объекта в 1С: убедитесь, что вложение передается именно как бинарный объект, а не как обычный текстовый блок. В крайнем случае, упакуйте файл в ZIP-архив — это гарантированно сохранит все внутренние переносы строк, так как содержимое архива для почтового сервера является неделимым набором байтов.