Vergleich STRING <> CHAR Feld (Unicode-Problem?)

Vergleich STRING <> CHAR Feld (Unicode-Problem?)

Hallo Zusammen,

habe ein Phänomen, was sich wahrscheinlich durch Unicode erklären lässt, verstehe aber nicht, warum das so ist.
Folgendes Progrämmchen zeigt die Problematik:

REPORT zj_string_char_comp.
DATA:
gv_string TYPE string,
gv_char(8),
gv_length TYPE i.

START-OF-SELECTION.
gv_char = '0123456'.
CONCATENATE gv_string gv_char INTO gv_string.
DESCRIBE FIELD gv_char LENGTH gv_length
IN CHARACTER MODE.

WHILE STRLEN( gv_string ) < gv_length.
CONCATENATE gv_string '#' INTO gv_string.
ENDWHILE.

TRANSLATE gv_string USING '# '.

* 1. Vergleich
IF gv_string = gv_char.
WRITE: / 'GV_STRING = GV_CHAR'.
ENDIF.
* 2. Vergleich
IF gv_string(gv_length) = gv_char.
WRITE: / 'GV_STRING(GV_LENGTH) = GV_CHAR'.
ENDIF.
* 3. Vergleich
IF gv_string(gv_length) cs gv_char.
WRITE: / 'GV_STRING(GV_LENGTH) CS GV_CHAR'.
ENDIF.


Meine Frage wäre, warum ziehen die Vergleiche 1 und 2 nicht? In der Doku zu Unicode steht zwar irgend etwas von Fragmentsicht usw., aber wenn ich doch mit Offset und so zugreife, sollte das doch klappen, oder?

Die Werte sind übrigens im Debugger (auch im HEX-Mode) identisch:

gv_string(gv_length) 3132333435362020
gv_char 3132333435362020

Gruß

ST22

Hallo zusammen,

Ralf hat Recht. Mach mal folgendes:

data: l type i.

l = strlen( gv_string ).
write: / 'gv_string =', l, 'Zeichen lang'.

l = strlen( gv_char ).
write: / 'gv_char =', l, 'Zeichen lang'.

Damit wirst du festellen, das gv_sting 8 Zeichen hat unf gv_char nur 7. Somit geht dein direkter Vergliech nicht.

Lösung: condense gv_string no-gaps.

Gruß

Thomas