|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Доброго всем. Возникла проблема с неверной кодировкой файлов аттачей при отправке их по e-amil. Аттачи хранятся в виде файлов csv на сервере. ПО сервера: Операционная система: Linux version 3.12.48-52.27-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Mon Oct 5 10:08:10 UTC 2015 (314f0e3) Версия Cache: Cache for UNIX (SUSE Linux Enterprise Server for x86-64) 2015.1.2 (Build 607_2) Tue Aug 11 2015 15:24:03 EDT Сообщение со списком аттачей формирую следующим образом: Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
В результате выполнения кода выше, получаю письма с нужными количеством вложений, но в неверной кодировке в наименовании аттача (см.рисунок). Там где закодировано - хотелось бы получить русские буквы, вместо "кракозябров". При этом, содержимое самого файла получаю корректное, в нужной мне кодировке. При запуске программы из Студии в режиме отладки в переменной iattach и списке attachList отображаются перекодированные русские символы, именно так и не иначе я могу получить доступ к файлам и добавить их к письму. Пользователи же работают с почтой в ОС Windows и там аттачи должны отображаться по-русски (перекодированные). Может у кого-то была схожая проблема - как удалось решить? Или придется "извратиться", н-р, через класс %FileBinaryStream и метод AttachStream класса %Net.MailMessage? ----------------------------------------------- А мы тут плюшками балуемся... Аленочка тм ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2017, 10:06 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Аленочка, что выдаёт: Код: sql 1.
для любой папки с файлами аттачей? Если в имени файла неверная кодировка, то скорее всего где-то не хватает локализации, вот основные шаги по локализации сервеа и Caché: 1. Изменить локализацию сервера если она не ru_RU.UTF-8 2. Изменить локализацию Caché если она не rus(w) 3. ^NLS -> Select defaults -> I/O tables -> System call -> Выбрать UTF8 -> Сохранить 4. Перезапустить сервер ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2017, 11:36 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Аленочка, кодировка имён файлов - больная тема для всех, кто работает в гетерогенных средах. Как вы, конечно, знаете, в Linux используется кодировка UTF-8, в Windows - всяко бывает :), но некоторые почтовые клиенты действительно ожидают CP-1251. Почта должна доставить имя файла в его оригинальной кодировке (UTF-8) и скорее всего делает это правильно. Вы можете убедиться в этом, используя какой-нибудь кросс-платформенный почтовый клиент, например, Zimbra, либо приняв его его с помощью Cache (%Net.POP3), либо раскодировав "ручками" заголовок принятого письма (большинство почтовых клиентов позволяют его увидеть). Можно попробовать задать m.Charset="CP-1251", но не уверен, что это поможет. Лучшее решение - совсем отказаться от кириллических имён файлов. P.S. В правильно настроенной Linux-системе предложенный Эдуардом вызов непременно выдаст крякозябры из-за лишней перекодировки в UTF-8. Правильно так: Код: javascript 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2017, 11:59 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Alexey Maslov...В правильно настроенной Linux-системе предложенный Эдуардом вызов непременно выдаст крякозябры из-за лишней перекодировки в UTF-8...Виноват, впал в субъективизм. Сказанное зависит от используемой локали, а у меня она несколько отличается от дефолтной RUW8. Но лишний раз выставить K\RAW\ в данном случае не повредит :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2017, 12:06 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Alexey Maslov, Я не очень глубоко в это все лез, но вроде бы есть кодировка имен файлов, кодировка контента и кодировки аттачей (каждого) тоже есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2017, 12:25 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Аленочка, У меня в свое время были проблемы с нестандартной оправкой писем. Если лень читать все, то вам нужно пользоваться Код: sql 1. 2.
Ну и знать, соответственно, что же в этих заголовках должно быть. В Каше не все заголовки выведены как свойства. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2017, 12:41 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Да, не всё в Cache выведено как свойства. Например, корректный заголовок письма с вложенным файлом с кириллическим именем выглядит так (отправлено не из Cache): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Насколько критично наличие полей filename*n*, сейчас не скажу. Возможно, для некоторых почтовых клиентов критично. Поэтому и посоветовал Алёночке посмотреть заголовки писем в почтовом клиенте, "внушающем доверия". Возможно, придётся добавлять дополнительные поля. Кстати, кое-что можно почерпнуть из этой статьи . ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2017, 12:57 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Alexey MaslovПочта должна доставить имя файла в его оригинальной кодировке (UTF-8) и скорее всего делает это правильно. Вы можете убедиться в этом, используя какой-нибудь кросс-платформенный почтовый клиент, например, Zimbra, либо приняв его его с помощью Cache (%Net.POP3), либо раскодировав "ручками" заголовок принятого письма (большинство почтовых клиентов позволяют его увидеть). Используем как раз Zimbra ))) Alexey MaslovМожно попробовать задать m.Charset="CP-1251", но не уверен, что это поможет. Правильно вроде UTF-8 или CP1251. Пробовала уже и m.Charset выставлять и добавлять параметром в AttachFile - никак не влияет. Alexey MaslovЛучшее решение - совсем отказаться от кириллических имён файлов. Кириллические имена файлов - это требования бизнеса, отказаться от них нельзя. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 02:47 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Блок А.Н.Аленочка, У меня в свое время были проблемы с нестандартной оправкой писем. Если лень читать все, то вам нужно пользоваться Код: sql 1. 2.
Ну и знать, соответственно, что же в этих заголовках должно быть. В Каше не все заголовки выведены как свойства. Попробовала, что-то ничего у меня не получилось, кроме того что удалось изменить Content-Type (значок вложения вместо синего стал зеленым )))) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 03:31 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Попробовала еще вариант через %FileBinaryStream. Идея была отрыть файл в потоке, скопировать поток с новым именем и отправить по почте. Наименование вложения получаю в нужной кодировке, но содержимое файлов пустое. Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 07:49 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Аленочка, У вас оба вложения пустые, исходное тоже. Думаю, причина в том, что вы попросту создали пустой поток этими командами: s currStream=##class(%FileBinaryStream).%New() s currStream.Filename=iattach Сопоставить поток с существующим файлом, ЕМНИП, можно так: s currStream=##class(%FileBinaryStream).%New() s sc=currStream.LinkToFile(Filename) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 10:52 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Аленочка, рада эксперимента отправил сам себе файл с кириллическим именем из Cache 2015.1 for Linux /8bit. Вложение пришло в таком виде (смотрим исходник!): Код: plaintext 1. 2. 3. 4. 5. 6.
Как видим, имя файла закодировано в соответствие с RFC 2047. Windows-кодировка выбрана, очевидно, исходя из текущей локализации Cache. Всё вроде бы нормально, и Thunderbird правильно показал имя вложения. А вот Zimbra с задачей не справилась, и ровно как у вас, показала крякозябры. Возможный выход из положения: предварительно разобравшись, какие форматы кодирования имён понимает Zimbra, отключить автоматическое кодирование заголовка Код: javascript 1.
и кодиовать самостоятельно. Все необходимые функции в Cache для этого есть; мне когда-то приходилось делать нечто подобное для отправки писем из Cache 4.1, в которой класс %Net.SMTP был ещё в зачаточном состоянии. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 11:55 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Alexey Maslov...причина в том, что вы попросту создали пустой поток этими командами: s currStream=##class(%FileBinaryStream).%New() s currStream.Filename=iattachпогорячился, конечно, так тоже можно; значит, файл оказался пустым по какой-то другой причине. Кстати, в какой кодировке у вас читаются имена файлов при просмотре каталога средствами Cache? zzdump name ; - проверяли? У меня они в UTF-8, что правильно: именно так и кодируются имена файлов в Linux, хоть и это и не совсем удобно в рамках Cache/8bit. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 12:47 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Забыла отписаться как удалось решить, возможно кому-то пригодится. У сообщения %Net.MailMessage выставляем параметр s m.IsMultiPart = 1 и формируем для него столько частей %Net.MailMessagePart, сколько у нас вложений. Далее делаем почти все то же самое что делает метод AttachFile (содержимое взято оттуда) с небольшим, но важным изменением вот в этом месте: s attach.FileName = $ZCVT(filename, "I", "UTF8"). Только таким образом удалось решить. Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.07.2017, 04:55 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Аленочка, рад, что нашли достаточно изящное решение, и спасибо, что отписались. Кстати, в Cache Unicode ошибка не возникла бы, т.к. в локализации (RUSW) таблица по умолчанию для файлов - UTF8. В 8-битной же локализации (RUW8) по какой-то причине таблица по умолчанию для файлов - RAW. Такое впечатление, что разработчики ИнтерСистемз считают, что если некоторая кодовая таблица является "центральной" в локализации Cache (в данном случае, CP1251), то локализация ОС должна быть основана на той же таблице, т.е. в случае Linux - ru_RU.CP1251. Однако такое встретишь нечасто, стандарт де-факто - ru_RU.UTF8. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.07.2017, 16:30 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Пожалуйста) да вот такие особенности, которые усложняют жизнь разработчикам) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.07.2017, 07:56 |
|
Cache for UNIX и проблемы с кодировкой файлов при отправке по e-mail (Unix vs Windows)
|
|||
---|---|---|---|
#18+
Alexey Maslovи спасибо, что отписались.Вот это, кстати, да. А то некоторые напишут пост и пропадают. И непонятно, нашли они решение сами, или им помогли советы, или они вообще это все не читают :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.07.2017, 12:47 |
|
|
start [/forum/topic.php?fid=39&msg=39479393&tid=1556337]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 19ms |
total: | 165ms |
0 / 0 |