Либо я что-то не так набирал, либо ещё что, но не нашел поиском ответа на свой вопрос.
Проблема такая: при создании документа XML через if_ixml, кодировка по умолчанию - utf-8, в итоговом файле нужна кодировка cp-1251.

После рендеринга формируется бинарная табличка с текстом.
При её выгрузке преобразования кодировок бессмысленны, т.к. бинарник.

Предпринял попытку изменить кодировку документа, хотя чувствовал, что делаю не то что нужно.

В результате получил ахинею.

Отсюда вопрос, а как преобразовать сформированный документ в нужную кодировку?

Если все правильно помню.... то преобразование в нужную кодировку происходит :

Увы, предложенный, Nikolas способ не сработал.

Но проблема решилась.
Следуя мануалу, изначально, таблица в которую рендерится была объявлена как

т.е. байтовых строк. Преобразовав её в

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

метод set_encoding - работает, выяснилось после переноса в тестовую систему. (А вот решение которое было на разработке - наоборот не работает в тесте ). Буду интересоваться у админа - в чем причина...

Я бы не стал терроризировать базисников. Вряд ли они могут это сломать/починить. Лучше минимальный примерчик с ошибкой покажите целиком. А проверьте ещё раз: наверняка что-нибудь напутали.

А вообще Nikolas правильно советует, что нужно использовать renderer, а сам документ пусть будет в системной кодировке.

Изначально я создал через рендерер табличку байтовых строк, которые при выгрузке через gui_download и filetype 'BIN' давали нормальный файл, но юникод.

Спросил совета у масс, т.к. самостоятельные эксприменты с set_encoding не дали результатов(а на разработке они их не дали и в последствии). Nikolas сказал про этот метод на renderer'e, а не на документе (как до этого пробовал я).
Результатом - все равно кракозябры.

Изменил целевую табличку для renderer'a как это было постом выше и стал выгружать как текстовый файл в codepage '1504'.
Финт ушами конечно, но работал (на разработке).

При переносе на тест результатом стали те же "кракозябры".

Изменил назад, с учетом что set_encoding производится на объекте renderer, а не документе. В итоге на разработке - выходят "кр-бры", а на тесте, после переноса, нормальный cp-1251.

Программы - идентичны, настройки gui - так же, результат действия - различен. Как таковой ошибки не нашел

По поводу различия разработки и теста. Может быть какая-нибудь глупость. Например, после переноса через транспорт программа может активироваться не сразу и вы запускали предыдущую версию. Или что-нибудь в этом духе.

Вы сами себя запутали с кодировками, по-моему. В xml документе кодировку ставить не надо (только в renderer), а GUI_DOWNLOAD нужно вызывать с форматом 'BIN'.

Этот вариант исключен.


set_encoding на разрабокте не отрабатывал и не отрабатывает как надо до сих пор. На тесте - работает, вот собственно код того, что имею в итоге.

А можно посмотреть, как выглядят "кракозябы" в разработке?

Есть класс CL_XML_DOCUMENT - можно там посмотреть, как выгружается/звгружается XML в файл.

Там как раз формат 'BIN' стоит.

Для успокоения совести, ещё бы неплохо проверить, совпадает ли содержимое l_xml_table перед вызовом gui_download с тем, что попадает в файл.

На разработке (так выглядит при кодировке win)


На тесте:


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

Ну это ISO-8859-5. Т.е. в дебаггере xml-таблаца должна выглядеть читабельно.

В дебаггере xml-таблица байтовый строки

Т.е. получается, что попытка поставить windows-1251 на разработке преобразует не в cp1251, а в iso?
Тогда какие могут быть причины этого?

Вот бы эти байтовые строки сравнить в таблице перед gui_download и в файле.

А если взять простую строчку текста и выгрузить в ASC формате с кодировкой 1504 через gui_download?

Если имя кодировки неизвестное, то выгружается в utf-8. В старых версиях кодировка windows-1251 не поддерживалась, но может сделали заглушку... Сравните версию и уровень патчей ядра в разработке и продуктиве.