Наабапили загрузку из очень большого TXT-файла, который лежит на сервере приложений. Сервер на Солярке, файл туда заливается в кодировке Win-1251.
Чтение построчно через
OPEN DATASET apps_file FOR INPUT IN LEGACY TEXT MODE CODE PAGE '1504' WITH WINDOWS LINEFEED.

Спотыкается дампом на READ DATASET, если в читаемой строке есть например символ x096 "длинное тире". Если убрать LEGACY TEXT MODE CODE PAGE '1504' - конвертирует русские буквы в чёрти-что, даже translate to codepage '1504' не помогает

Если грузануть файл с клиента, ФМом GUI_UPLOAD, то заменяет кривой символ на '#', дампа нету.

Вопрос - как посмотреть, какие конкретно символы ASCII входят в состав CODEPAGE '1504' ? Брутфорсить посимвольно от 0 до 255 както не хочется
Есть штатный способ вычленить разом все кривые символы в строке (или прогрузить файл в Win-кодировке с Unix-сервера)?

Попробуйте грузить в бинарном режиме и потом конвертировать классом CL_ABAP_CONV_IN_CE

поправка - GUI_UPLOAD получается протаскивает такой символ без преобразования. В таблицу БД ложится символ "длинное тире", но если его write на экран, то получаем '#'.

да именно не хотелосьбы без лишних преобразований в памяти сервера приложений, - файл неприличного объёма.

файл в UNICODE переделать никак?

А преобразования так или иначе все равно будут. Либо сам сервер приложений в ядре будет из win1251 в юникод преобразовывать, либо вы ручками туже операцию вызовите.

имелось ввиду изначально файл создавать не в WIN1251, а в UNICODE
чтобы избежать дампа используйте OPEN DATASET ... IGNORING CONVERSION ERRORS, все непонятые символы будет заменять на "#"

Ой, я это замечание топикстартеру адресовал

спасибо, IGNORING CONVERSION ERRORS помогло.

Единственное что пока непонятно - GUI_UPLOAD, даже если явно передавть в него CODEPAGE = '1504' всёравно протаскивает с клиента этот символ без преобразования (как будто внутри ФМа алгоритм трансляции кодовых страниц совершенно другой, чем в OPEN DATASET, и этот символ не считается неправильным). А в решётку он превращается только при write (в АLV отображается норамльно как "длинное тире"). Т.е. одна и та-же загрузка с сервера и с клиента - даёт разное наполнение таблиц в SAPe. Вроде мелочь, но с учётом что по этому тексту пользователи SAP ищут соответствия ...

Насчёт конверсии файла в UNICODE - попробую, т.к. он формируется самописными SQL-скриптами в MSSQLserver. Но тогда у него объём ещё удвоится при загрузке.

Попробуйте:



У меня тире выводится даже врайтом, но система довольно новая.
А какой объем вы экономите? Место на жестком диске или память системы? Если память системы - то объем все равно удваивается, т.к. юникод система хранит строки у себя только в юникоде и при загрузке их преобразовывает.