Value #

[Former Member]

Hi experts,

I have a problem with a conversion of a file csv. I use the method CL_ABAP_CONV_IN_CE=>CREATE for convert this csv file and after I split this value in a table of string, but I have a table with two rows: one row has the correct value, but the second row has value = #, that corresponds to a blank line in csv file. How can I do for to delete this row? I write:

If l_string(1) eq '#',

but this modify is not reflected...

Any suggestion?

Edited by: webdynpro.gc on Mar 1, 2010 3:29 PM

[Subhankar · Accepted solution]

Hi,

Recently I also faced the same problem. There one interesting solution.

1. Get the new line char format from cl_abap_char_utilities=>cr_lf.

Here the value come like ## (0D000A00 ine hex value)

2. Take the first char in a char one field . so here this field will contain # (0D00).

3. Then replace this char one field by normal #

TYPE-POOLS:abap.

DATA: l_char TYPE char1,

l_char2 TYPE abap_cr_lf.

l_char2 = cl_abap_char_utilities=>cr_lf.

l_char = l_char2.

REPLACE ALL OCCURRENCES OF l_char in l_line with '#'.

Thanks

Subhankar

[Former Member · Accepted solution]

tks solved!

[thomas_jung]

The # is used to represent any non-printable character. So the underlying character code likely isn't #. If you look at the string in the debugger and view the Hexidecimal represenation you can see that.

There are kernel attributes of the class CL_ABAP_CHAR_UTILITIES to represent some of the more common non-printable characters. It is probably CR_LF or NEWLINE. You might try the following:

If l_string(1) eq CL_ABAP_CHAR_UTILITIES=>NEWLINE or
   l_string(1) eq CL_ABAP_CHAR_UTILITIES=>CR_LF.

[Former Member]

I tryed with CL_ABAP_CHAR_UTILITIES=>NEWLINE and also with CL_ABAP_CHAR_UTILITIES=>CR_LF, but this modify is not reflected. I saw in debug that the value hexdecimal of # is '0D00', but I don't know how can I do for convert this value...

[thomas_jung]

0D00 is simply an invalid unicode character - generally represented by a box character when viewed with a text editor. I'm not exactly sure what you are picking up there. You would have to remove this in byte mode - preferably while this was still an XSTRING. Better question might be why you are getting this byte sequence in the first place. It shouldn't be exported to the CSV format by Excel.

[thomas_jung]

The problem could be back with the CL_ABAP_CONV_IN_CE Conversion. Have you looked at the hex values of the XSTRING before conversion? CL_ABAP_CONV_IN_CE might be replacing a character that is outside your code page. Are you running a Unicode system? If not a character from outside your code page might be replaced with this value. For instance you are logged on in English, but there is one Chinese character in your data. If you aren't a Unicode system, this character will be corrupted as there is no correct correlation in the current code page and replaced with the # character.

[Former Member]

For convert the CSV file, I use this method:

CALL METHOD CL_ABAP_CONV_IN_CE=>CREATE

EXPORTING

INPUT = l_xstring

ENCODING = 'UTF-8'

REPLACEMENT = '?'

IGNORE_CERR = ABAP_TRUE

RECEIVING

CONV = lr_CONV.

CALL METHOD lr_CONV->READ

IMPORTING

DATA = l_string.

SPLIT l_string AT cl_abap_char_utilities=>newline INTO TABLE i_data.

What I have to specify for delete the invalid rows?