v7: Странное поведение MAIL.RU // текстовый файл

1C 7.7

18.05.22

✎

13:38

Столкнулся сейчас с такой проблемой, есть клиент, у которого почта на INBOX.RU. На ящик данного домэна я отправляю обычный текстовый файл, в котором содержаться данные, разделенные точкой с запятой и каждый новый блок начинается с новой строки. Дык вот...сформировав файл и отправив его себе на почту для пробы я получаю то что надо, открывая в блокноте вижу набор строк с данными. Пересылаю ему это письмо на его почту и он в ответ говорит, что все данные в одной строке. Долго не мог понять что к чему...оказалось, что при отправке почты на майл в текстовом файле слетает символ c CRLF на LF. Кстати файл формируется из 7.7. Каким образом можно в 1С программно добавить два этих символа, правильно ли я понимаю, что это Симв(10)+Симв(13)?

1 mr_fix

18.05.22

✎

14:55

Упаковать файл в архив не предлагать?

2 kupec

18.05.22

✎

15:06

да я тоже про это думал. Но там люди скорее всего не справятся с извлечением из архива

3 kupec

18.05.22

✎

19:28

Помогло сохранение файла в UTF-8

4 Злопчинский

18.05.22

✎

21:54

(2) посоветуй им блокнот и ручку

5 Злопчинский

18.05.22

✎

21:57

(0) неправильно понимаешь, с точностью до наоборот 0D0A
в 77 эти два симолва это системная константа РазделительСтрок

"строка 1"+разделительСтрок+"Строка 2"
.

6 ДедМорроз

18.05.22

✎

22:11

Ну и что,что слетает - если в far открыть,то прекрасно откроется.
То,что windows notepad так не умеет - это его проблемы.

7 NorthWind

18.05.22

✎

22:40

Скорее всего происходит следующее. Когда вы аттачите файл, ваша библиотека почты (V7Plus или DialMail или чем вы там пользуетесь) не видит в нем никаких служебных символов и присоединяет его к письму как plain text. Это автоматически означает, что почтовые узлы, через которые идет письмо, могут делать какие-то конвертации, которые не влияют на структуру текста, в частности, менять переводы строки с Windows-style 0xD 0x0A на UNIX-style (только 0x0A). А вот если вы аттачите файл в кодировке UTF-8, то библа видит посторонние символы (например в диапазоне 0x0 - 0x19, кроме 0xD, 0xA) и присоединяет файл, предварительно закодировав его в BASE64. В итоге в нем ничего не портится, он на выходе нормально раскодируется и вы получаете текст в первозданном виде.

Мораль сей басни: может, поискать в настройках аттача, чтобы оно _всегда_ кодировало файлы в BASE64?