Глюк READ DATASET?

linker

Всем добрый день.

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

По определению из документации система R/3 является Unicode system (ЕСС 6.0, SAP_BASIS 7.00). Тестовая программа читает плоский текстовый файл (в UTF-8 ), но символ end-of-line интерпретируется как-то странно (как '#') - если по документации, то его не должно быть.

Code:

open dataset ds for input in text mode encoding default.
* некоторые действия опущены..
data: line(4096).
* последним символом line всегда оказывается '#'
read dataset ds into line.
* здесь тоже кой-какие действия
close dataset dataset.

Почему так происходит? Может, я что-то не так делаю?
Заранее спасибо за помощь.

Правка: UTF-8)

Galka

А в каком формате переноса вы загружаете файл на сервер? BIN или ASCII?

А убрать символ # в конце строки можно и не зависеть от форматов:

Code:

  REPLACE ALL OCCURRENCES OF
    cl_abap_char_utilities=>cr_lf(1)   IN buf_str WITH ''.
  REPLACE ALL OCCURRENCES OF
    cl_abap_char_utilities=>cr_lf+1(1) IN buf_str WITH ''.

linker

Цитата:

А в каком формате переноса вы загружаете файл на сервер? BIN или ASCII?

Только что еще раз перепроверил, переношу в формате BIN.

sibrin

linker написал(а):

но символ end-of-line интерпретируется как-то странно (как '#')

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

linker

sibrin написал:

linker написал(а):

но символ end-of-line интерпретируется как-то странно (как '#')

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

Дело в том, что я не могу найти в документации, что последний символ в строке будет CR/LF (где-то читал, что для UTF-8 это по идее два 0x0). Поэтому стандартная транзакция OODT падает в дамп.

Galka

попробуйте как раз в ascii загрузить. У меня такая проблема была. Сейчас смоделировала - действительно, в нумце в конце строки #, в асции таких символов нет

linker

Galka написала:

попробуйте как раз в ascii загрузить. У меня такая проблема была. Сейчас смоделировала - действительно, в нумце в конце строки #, в асции таких символов нет

Вылетает с ошибкой: CONVT_CODEPAGE, при преобразовании from codepage 4110 (UTF-8) to codepage 4102 (UTF-16BE).. Записи по обеим кодовым страницам присутствуют в таблице TCP00.

sibrin

linker написал(а):

где-то читал, что для UTF-8 это по идее два 0x0.

Чушь, в utf-8 символы до 127 идентичны ASCII.
Для того эту кодировку и придумали, чтобы не было проблем
на переходом этапе на 16 бит.

Reddy

Galka написала:

А убрать символ # в конце строки можно и не зависеть от форматов:

Code:

  REPLACE ALL OCCURRENCES OF
    cl_abap_char_utilities=>cr_lf(1)   IN buf_str WITH ''.
  REPLACE ALL OCCURRENCES OF
    cl_abap_char_utilities=>cr_lf+1(1) IN buf_str WITH ''.

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

AFH

Цитата:

If the file was opened as a binary file or as a legacy-binary file, as much data is read that fits into the data object dobj. If the data object dobj is longer than the number of exported characters, it is filled with hexadecimal 0 on the right.

А у вас случайно не этот случай?

Как вы открываете файл?

Reddy

Источником данных считывается значение поля char40 из прозрачной таблицы.

Удав

Reddy написал:

Непонятно для чего нужен сдвиг при втором вызове класса? Не работает.

А вы посмотрите размерность константы cl_abap_char_utilities=>cr_lf :wink:

Reddy написал:

Использую его в трансформации для удаления непечатных символов в строке.

Это неправильно. CRLF - это только перевод строки. Непечатных сиволов намного больше.
Для проверки нужно использовать сравнение с массивом 'A'..'Z', 'a'..'z', 'А'..'Я', 'а'..'я', '0'..'9', знаки препинания.

weise

Удав написал(а):

Непечатных сиволов намного больше.
Для проверки нужно использовать сравнение с массивом 'A'..'Z', 'a'..'z', 'А'..'Я', 'а'..'я', '0'..'9', знаки препинания.

Но ведь может получиться, что в этом массиве будет слишком много символов, начиная от @ и заканчивая заковыристыми иероглифами? Не окажется ли в таком случае разумной альтернавивой использование спецсимволов для регекспов типа "[ [:print:] ]"?

Удав

weise написал(а):

Но ведь может получиться, что в этом массиве будет слишком много символов, начиная от @ и заканчивая заковыристыми иероглифами? Не окажется ли в таком случае разумной альтернавивой использование спецсимволов для регекспов типа "[ [:print:] ]"?

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

Reddy написал:

Источником данных считывается значение поля char40 из прозрачной таблицы.

trop

возможно это возврат каретки виндовый, попробуйте как выше писали:

Code:

replace all occurrences of cl_abap_char_utilities=>cr_lf(1) in buf1 with ``.
-или-
replace all occurrences of `\r` in buf1 with ``.

Правила форума

Глюк READ DATASET?

Кто сейчас на конференции