What does it do? The content of the operand dobj> is split into segments in accordance with the sequence of separators in sep> and the results are either stored in individual target fields result1 result2 ...> or in the lines of an internal table result_tab>.
At least two target fields result1 result2 ...> must be specified. The following can be specified for the target fields:
Existing character-like or byte-like variables.
Inline declarations with DATA(var)>> or FINAL(var)>>. If IN CHARACTER MODE> is used, the declared variables are of the type string>; if IN BYTE MODE> is used, they are of the type xstring>.
The following can be specified for the internal table result_tab>:
An existing internal table with character-like or byte-like line type. It must be a standard table> without secondary table keys>. The table is initialized before being split.
An inline declaration with DATA(var)>> or FINAL(var)>>. A standard table is declared with the table line as the primary table key and without secondary table keys. If IN CHARACTER MODE> is used, the line type is of the type string>; if IN BYTE MODE> is used, it is of the type xstring>. dobj> and sep> are character-like expression positions>. The system searches the operand dobj> from left to right for all occurrences of the content of the operand sep>. The search is case-sensitive. All segments between the start of the operand and the first occurrence, between the occurrences, and between the last occurrence and the end of the operand are assigned one by one to the individual target fields result1 result2 ...>, or appended to the internal table result_tab> as follows.
If the target fields result1 result2 ...> or the lines of the internal table result_tab> have a fixed length and this length is not sufficient for a segment, the segment is truncated on the right and sy-subrc> is set to 4. If the length is greater than the length of the segment, it is padded with blanks or hexadecimal 0 on the right. If the target fields result1 result2 ...> or the lines of the internal table result_tab> are strings, their length is adjusted to that of the associated segment.
If not enough target fields result1 result2 ...> are specified to include all the segments, dobj> is only split until all the target fields result1 result2 ...> have been assigned values, except for the last one. The remaining content of dobj> is then assigned to the final operand, without being split.
The segments are assigned directly while ignoring the conversion rules.
If more target fields result1 result2 ...> are specified than required, the surplus target fields with fixed lengths contain blanks or hexadecimal 0 after the statement and surplus strings are initial. If the content of the operand sep> is found immediately at the start of dobj>, or occurs in direct succession in dobj>, the result of the split is an empty string. If the content of sep > is at the end of dobj>, the search is completed there and no further separation takes place to the right of this point. If the content of the operand sep> is not found or is an empty string, the result of the split is a single segment that contains the entire content of dobj>, and which is assigned to the first individual target field or the first line of the internal table. In character string processing, trailing blanks are respected in separators sep> of fixed length. If the operand dobj> has a fixed length, any trailing blanks are ignored in the operand dobj> and in the segments created by the split. If the operand dobj> has the type string>, any trailing blanks are respected in the operand dobj> and in the segments created by the split. System Fields> sy-subrc>Meaning> 0The segments were passed to the target fields or the internal table without being truncated. 4At least one of the segments was truncated on the right when passed to the target fields or internal table.
Latest notes:
Provided that enough target fields are specified or that the segments are stored in an internal table, the number of segments created is determined by the number of separators found, as follows:
If the last occurrence is not at the end of the operand, the number of segments matches the number of occurrences plus 1.
If the last occurrence is at the end of the operand, the number of segments matches the number of occurrences.
In the case of target fields or table lines with the type n>, d>, or t>, the type-dependent assignment rules and initial values are not relevant. The segments are assigned as unconverted segments and any surplus target fields are filled with blanks.
All specified single fields result1 result2 ...> are given values.
To access the segments of a character string directly in an operand position, a segment function> can be used that covers some of the functions of the statement SPLIT>. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 The text field text> is separated at its blanks into the three strings str1>, str2>, and str3>, and also into an internal table with the line type string>. Since the three strings are not sufficient for all seven parts, str3> contains drag it is getting old> after the split, while the internal table contains seven lines; one for each word in text>. ABEXA 00680 ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 A text string text1> and a text field text2> have the same content and are split into a table in the same way. When the text string is split, the segments contain trailing blanks. This is not the case when the text field is split. ABEXA 00681 ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 The following SPLIT> statement extracts all strings of digits in a text string to an internal table. ABEXA 00682 ABAP_EXAMPLE_END • IN BYTE MODE SPLIT • IN CHARACTER MODE SPLIT
ABAP Addition
What does it do? The optional addition IN ${CHARACTER$|BYTE$} MODE> determines whether character string or byte string processing> is performed. If the addition is not specified, character string processing is performed. Depending on the type of processing, the operands dobj>, sep>, and the target fields result1 result2 ...> or the lines of the internal table result_tab> must be byte-like or character-like.
ABAP_EXAMPLE_VX5 The byte string xstr> is split into an internal table with line type xstring> at bytes with the value hexadecimal 20, which stands for a blank in code page UTF-8. ABEXA 00683 ABAP_EXAMPLE_END