Wie konvertiert man eine Stringtabelle nach XSTRING?
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Hallo zusammen,
ich stehe vor dem Problem, dass ich eine CSV-Tabelle in einer internen Tabelle (mit Zeilentyp STRING) aufgebaut habe. Diese soll über eine REST-Schnittstelle versendet werden. Das setzt aber voraus, dass sie als binärer XSTRING vorliegt (wobei dann auch die Zeilenenden in den XSTRING integriert sind).
Nach meinem Verständnis führt der klassische Weg über die Klasse CL_BCS_CONVERT, namentlich die Methode CL_BCS_CONVERT=>RAW_TO_XSTRING. Das Problem an dieser Methode ist aber, dass sie bei der Texttabelle den Zeilentyp SOLI erwartet, und der ist im DDIC als C(255) definiert. Ich kann aber bei meiner CSV-Datei nicht garantieren, dass keine Zeile länger als 255 Zeichen ist!
Im Moment habe ich eine Lösung im Einsatz, die funktioniert, die ich technisch aber als Krüppellösung einstufe. Und zwar gebe ich die Tabelle per OPEN DATASET TEMP_FILENAME FOR OUTPUT IN TEXT MODE ENCODING UTF-8 in eine temporäre Textdatei auf den Server aus, um sie gleich anschließend per OPEN DATASET TEMP_FILENAME FOR INPUT IN BINARY MODE in einen XSTRING einzulesen und hinterher wieder zu löschen. Das funktioniert, aber das muss doch auch direkt in ABAP gehen?!?
ich stehe vor dem Problem, dass ich eine CSV-Tabelle in einer internen Tabelle (mit Zeilentyp STRING) aufgebaut habe. Diese soll über eine REST-Schnittstelle versendet werden. Das setzt aber voraus, dass sie als binärer XSTRING vorliegt (wobei dann auch die Zeilenenden in den XSTRING integriert sind).
Nach meinem Verständnis führt der klassische Weg über die Klasse CL_BCS_CONVERT, namentlich die Methode CL_BCS_CONVERT=>RAW_TO_XSTRING. Das Problem an dieser Methode ist aber, dass sie bei der Texttabelle den Zeilentyp SOLI erwartet, und der ist im DDIC als C(255) definiert. Ich kann aber bei meiner CSV-Datei nicht garantieren, dass keine Zeile länger als 255 Zeichen ist!
Im Moment habe ich eine Lösung im Einsatz, die funktioniert, die ich technisch aber als Krüppellösung einstufe. Und zwar gebe ich die Tabelle per OPEN DATASET TEMP_FILENAME FOR OUTPUT IN TEXT MODE ENCODING UTF-8 in eine temporäre Textdatei auf den Server aus, um sie gleich anschließend per OPEN DATASET TEMP_FILENAME FOR INPUT IN BINARY MODE in einen XSTRING einzulesen und hinterher wieder zu löschen. Das funktioniert, aber das muss doch auch direkt in ABAP gehen?!?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Die erwartet nur eine einzelne Zeile. Ich habe aber eine komplette CSV-Tabelle (also kommaseparierte Textfelder). Ich wüsste nicht, wie ich die Zeilenumbrüche (CR/LF) in den String reinbekomme.
du sagtest doch, deine CSV-Tabelle sei vom Zeilentyp STRING
mit CONCATENATE LINES OF itab könntest du diese ja komplett in einen Einzelstring übernehmen und den dann konvertieren. Ggfs, kann man zwischen jede Zeile dann noch CRLF oder was erforderlich ist, einfügen.
z.B.
mit CONCATENATE LINES OF itab könntest du diese ja komplett in einen Einzelstring übernehmen und den dann konvertieren. Ggfs, kann man zwischen jede Zeile dann noch CRLF oder was erforderlich ist, einfügen.
z.B.
Code: Alles auswählen.
DATA:
csv_tab TYPE table_of_strings,
csv_string TYPE string,
csv_xstring TYPE xstring.
APPEND 'erster' TO csv_tab.
APPEND 'zweiter' TO csv_tab.
CONCATENATE LINES OF csv_tab
INTO csv_string SEPARATED BY cl_abap_char_utilities=>cr_lf.
csv_xstring = cl_bcs_convert=>string_to_xstring( csv_string ).Folgende Benutzer bedankten sich beim Autor zzcpak für den Beitrag:
DeathAndPain
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Muss ich mal ausprobieren, das könnte funktionieren. Ich hatte das gar nicht mehr präsent, dass man sich über cl_abap_char_utilities Sonderzeichen beschaffen kann. Danke!
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Das hat funktioniert, vielen Dank!
Nebenbei habe ich auch die Syntax CONCATENATE LINES OF kennengelernt; die kannte ich noch nicht. Der normale CONCATENATE-Befehl hat seine Daseinsberechtigung mit der Einführung des &&-Operators IMHO weitestgehend verloren, aber in dieser Form ist er weiterhin sehr nützlich.
Nebenbei habe ich auch die Syntax CONCATENATE LINES OF kennengelernt; die kannte ich noch nicht. Der normale CONCATENATE-Befehl hat seine Daseinsberechtigung mit der Einführung des &&-Operators IMHO weitestgehend verloren, aber in dieser Form ist er weiterhin sehr nützlich.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Wenn du die "alten" Befehle loswerden willst:
Es gibt auch die Funktion CONCAT_LINES_OF die das gleiche macht.
Es gibt auch die Funktion CONCAT_LINES_OF die das gleiche macht.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
DeathAndPain
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Danke, das ist eine interessante ergänzende Information.
Hingegen finde ich den CONCATENATE LINES OF in zzcpaks Beispielcode optisch super in Ordnung. Die von Dir genannte Funktion ist sicherlich eine interessante Alternative, aber hier sehe ich keinen Leidensdruck.
Nicht ums Verrecken. Es geht nicht darum, die alten Befehle loszuwerden, weil sie alt sind, es muss schon auch was bringen. Deswegen werde ich den FOR-Befehl in Zuweisungen wahrscheinlich auch nie einsetzen, da er in meinen Augen nicht hilfreich ist, die Lesbarkeit des Codes zu verbessern, sondern diese im Gegenteil deutlich verschlechtert. Aber der CONCATENATE-Befehl mit seiner insbesondere bei Leerzeichen sehr umständlichen und schlecht lesbaren Syntax hat mir noch nie gefallen. Bei dem Befehl habe ich mich schon unter 3.1i gefragt, warum die SAP sich dafür keine bessere Lösung hat einfallen lassen. Wenn man z.B. einen Text in eine Variable packen wollte, bei der hinter dem Wert der ersten ein Doppelpunkt und dann der Wert der zweiten kam, wobei - optisch üblich - vor dem Doppelpunkt kein Leerzeichen sein sollte, dahinter aber sehr wohl, dann musste man nacheinander zwei CONCATENATES machen, einen mit und einen ohne SEPARATED BY SPACE. Der Code sah schrecklich aus. Mit && und dem accent grave als Anführungszeichen geht das nicht nur viel kürzer, sondern auch bedeutend besser lesbar.Wenn du die "alten" Befehle loswerden willst
Hingegen finde ich den CONCATENATE LINES OF in zzcpaks Beispielcode optisch super in Ordnung. Die von Dir genannte Funktion ist sicherlich eine interessante Alternative, aber hier sehe ich keinen Leidensdruck.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Das geht doch auch mit dem CONCATENATE seit Strings als Datentyp und damit dann auch der "backtick" als Stringbegrenzer eingeführt wurde.DeathAndPain hat geschrieben:...dem Befehl habe ich mich schon unter 3.1i gefragt, warum die SAP sich dafür keine bessere Lösung hat einfallen lassen. Wenn man z.B. einen Text in eine Variable packen wollte, bei der hinter dem Wert der ersten ein Doppelpunkt und dann der Wert der zweiten kam, wobei - optisch üblich - vor dem Doppelpunkt kein Leerzeichen sein sollte, dahinter aber sehr wohl, dann musste man nacheinander zwei CONCATENATES machen, einen mit und einen ohne SEPARATED BY SPACE. Der Code sah schrecklich aus. Mit && und dem accent grave als Anführungszeichen geht das nicht nur viel kürzer, sondern auch bedeutend besser lesbar.
Code: Alles auswählen.
CONCATENATE lv_vor `: ` lv_nach into text.
CONCATENATE lv_vor lv_nach into text SEPARATED BY `: `.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Dito. Weshalb ich schon lange embedded expressions verwende (die 'deutsche' Übersetzung "Zeichenketten-Template" finde ich ziemlich bescheuert, daher der englische Begriff).DeathAndPain hat geschrieben:Aber der CONCATENATE-Befehl mit seiner insbesondere bei Leerzeichen sehr umständlichen und schlecht lesbaren Syntax hat mir noch nie gefallen
Beispiel für blöde Lesbarkeit:
Code: Alles auswählen.
data: sy_index type string.
sy_index = sy-index.
CONCATENATE string_a sy_index string_b into ziel_string SEParated by space.Deutlich besser lesbar in meinen Augen:
Code: Alles auswählen.
ziel_string = |{ string_a } { sy-index } { string_b }|.ziel_string = |{vor_string_a && string_a } { sy-index } { string_b && nach_string_b}|.
(ohne code-Tags wegen der kfm.-Und-Zeichen)
alt:
Code: Alles auswählen.
data: sy_index type string, string_vorn type string, string_hinten type string.
sy_index = sy-index.
concatenate: vor_string_a string_a into string_vorn,
string_b nach_string_b into string_hinten,
string_vorn sy_index string_hinten into ziel_string SEParated by space.
clear: string_vorn, string_hinten. " nicht mehr benötigtRalf
PS: Zu FOR gebe ich dir erstmal recht, würde aber nie ausschließen, dass es Fälle gibt, wo man das sinnvoll einsetzen kann. Gemacht hab ich es einmal, wo es darum ging, aus einer Liste von Objekten eine Datentabelle mit deren Attribute zu machen. In meinem Kopf war das eine Art "MOVE_CORRESPONDING", warum ich es auch kompakt in einer Anweisung haben wollte, aber syntaktisch nicht entsprechend umsetzbar. Und da sage ich "lieber eine kompakte Anweisung mit einem erklärenden Kommentar davor als 30 Codingzeilen, bei denen der Entwickler erst ermitteln muss, was da in den Einzelschritten gemacht werden muss". Andere mögen da anderer Meinung sein, aber was ich programmiere, mache ich erstmal so, wie ich es für richtig halte - wer das nicht will, soll wen anderen beauftragen. Der Kommentar sagte soviel wie "das ist ein move-corresponding der Attribute aller Objekte in die Datentabelle".
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Wobei Du hier die gute, alte 3.1i-Syntax zugrundelegst. Heutzutage könnte der CONCATENATE-Verwender sich mit CONV() retten und damit den Großteil Deiner Argumentation entkräften. Ich finde CONCATENATE aber dennoch hässlich.ralf.wenzel hat geschrieben:Beispiel für blöde Lesbarkeit:DeathAndPain hat geschrieben:Aber der CONCATENATE-Befehl mit seiner insbesondere bei Leerzeichen sehr umständlichen und schlecht lesbaren Syntax hat mir noch nie gefallen
sy-index ist ein INT4-Feld, weshalb man es nicht concatenaten kann, also muss man es in ein Zeichenfeld umsetzen (hier: sy_index zur Veranschaulichung). Das heißt, man muss den CONCATENATE-Befehl mit Hilfsvariablen erst "möglich machen" (was andere als "gewollte Geschwätzigkeit" auslegen mögen -- ich fand immer schon, dass Geschwätzigkeit keinen Wert an sich darstellt).Code: Alles auswählen.
data: sy_index type string. sy_index = sy-index. CONCATENATE string_a sy_index string_b into ziel_string SEParated by space.
Wenn man regexps beherrscht. Ich würde (IMHO mindestens genauso gut lesbar) einfachDeutlich besser lesbar in meinen Augen:
Code: Alles auswählen.
ziel_string = |{ string_a } { sy-index } { string_b }|.
string_a && sy-index && string_b
coden. Der Doppelampersand hat kein Problem mit dem Integerwert (wobei ich jetzt nicht weiß, ob das unter 7.0 auch schon so war).
Ja, wobei das mit dem Doppelampersand nebst accent grave auch schon alles abgedeckt ist.Da muss ich Schritt für Schritt nachvollziehen, was da eigentlich gemacht wird, um dann im Kopf zu haben, was die neue Syntax schon ausdrückt. Und drei unnütze Variablen, die ich nur brauche, weil CONCATENATE zu doof ist, hab ich auch noch am Hals. Die steigern die Lesbarkeit auch nicht gerade.Code: Alles auswählen.
data: sy_index type string, string_vorn type string, string_hinten type string. sy_index = sy-index. concatenate: vor_string_a string_a into string_vorn, string_b nach_string_b into string_hinten, string_vorn sy_index string_hinten into ziel_string SEParated by space. clear: string_vorn, string_hinten. " nicht mehr benötigt
Ich würde solchen Code akzeptieren, wenn der Kommentar gut genug wäre, dass ich dann auch ohne allzu großen Aufwand nachvollziehen kann, was Dein FOR da veranstaltet. Bei dem von Dir geschilderten Fall kann ich mir das durchaus vorstellen.PS: Zu FOR gebe ich dir erstmal recht, würde aber nie ausschließen, dass es Fälle gibt, wo man das sinnvoll einsetzen kann. Gemacht hab ich es einmal, wo es darum ging, aus einer Liste von Objekten eine Datentabelle mit deren Attribute zu machen. In meinem Kopf war das eine Art "MOVE_CORRESPONDING", warum ich es auch kompakt in einer Anweisung haben wollte, aber syntaktisch nicht entsprechend umsetzbar.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
CONV ist 7.40, auf einem 7.31er System geht das nicht, meine Lösung aber schon.DeathAndPain hat geschrieben:Wobei Du hier die gute, alte 3.1i-Syntax zugrundelegst. Heutzutage könnte der CONCATENATE-Verwender sich mit CONV() retten und damit den Großteil Deiner Argumentation entkräften. Ich finde CONCATENATE aber dennoch hässlich.
Nein, aber dann hast du auch keine Leerzeichen drin. Das war ja gewünscht. Du willst ja schreiben "Durchlauf 3 geht schief" und nicht "Durchlauf3geht schief".DeathAndPain hat geschrieben:Wenn man regexps beherrscht. Ich würde (IMHO mindestens genauso gut lesbar) einfach
string_a && sy-index && string_b
coden. Der Doppelampersand hat kein Problem mit dem Integerwert (wobei ich jetzt nicht weiß, ob das unter 7.0 auch schon so war).
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Wenn man extra kompliziertes und schlecht designtes Coding für das CONCATENATE angibt ist es natürlich viel einfacher zu behaupten, dass die String-Templates besser lesbar seien. Hier mal eine Alternative, die in meinen Augen sehr gut lesbar ist und ohne die Zwischenvariablen auskommt.ralf.wenzel hat geschrieben:Da muss ich Schritt für Schritt nachvollziehen, was da eigentlich gemacht wird, um dann im Kopf zu haben, was die neue Syntax schon ausdrückt. Und drei unnütze Variablen, die ich nur brauche, weil CONCATENATE zu doof ist, hab ich auch noch am Hals. Die steigern die Lesbarkeit auch nicht gerade.Code: Alles auswählen.
data: sy_index type string, string_vorn type string, string_hinten type string. sy_index = sy-index. concatenate: vor_string_a string_a into string_vorn, string_b nach_string_b into string_hinten, string_vorn sy_index string_hinten into ziel_string SEParated by space. clear: string_vorn, string_hinten. " nicht mehr benötigt
Code: Alles auswählen.
CONCATENATE vor_string_a
string_a
` `
string_b
nach_string_b
INTO ziel_string
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Du hast den sy-Index nicht in der Anweisung 
Das macht sie freilich einfacher. Ob man ein Leerzeichen in die Anweisung schreiben kann, kann ich gerade nicht testen. Und war es nicht so, dass man max. vier Dinge in einem Rutsch verketten kann? Wie gesagt, ich sitze nicht am System und nutze die Anweisung selten.
In Summe gibt es lauter Beschränkungen, die es bei Zeichenketten nicht gibt.
Ralf
Das macht sie freilich einfacher. Ob man ein Leerzeichen in die Anweisung schreiben kann, kann ich gerade nicht testen. Und war es nicht so, dass man max. vier Dinge in einem Rutsch verketten kann? Wie gesagt, ich sitze nicht am System und nutze die Anweisung selten. In Summe gibt es lauter Beschränkungen, die es bei Zeichenketten nicht gibt.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Dann machste haltRalf hat geschrieben:Nein, aber dann hast du auch keine Leerzeichen drin. Das war ja gewünscht. Du willst ja schreiben "Durchlauf 3 geht schief" und nicht "Durchlauf3geht schief".DeathAndPain hat geschrieben:Wenn man regexps beherrscht. Ich würde (IMHO mindestens genauso gut lesbar) einfach
string_a && sy-index && string_b
coden. Der Doppelampersand hat kein Problem mit dem Integerwert (wobei ich jetzt nicht weiß, ob das unter 7.0 auch schon so war).
string_a && ` ` && sy-index && ` ` && string_b
Finde ich von der Lesbarkeit her immer noch in Ordnung.
Ich habe Ralf so verstanden, dass er die in älteren Releases ursprünglich notwendige Syntax beschrieben hat. Die Accent grave-Anführungszeichen gibt es zwar schon länger als 7.40, aber in den richtig alten Releases gab es sie nicht. Den CONCATENATE schon.black_adept hat geschrieben:Wenn man extra kompliziertes und schlecht designtes Coding für das CONCATENATE angibt ist es natürlich viel einfacher zu behaupten, dass die String-Templates besser lesbar seien.
Vergleichbare Themen
1
Antw.
Antw.
2546
Views
Views
konvertierung von TIF-Xstring to PDF-Xstring
von lino » 11.07.2012 16:38 • Verfasst in ABAP Objects®
von lino » 11.07.2012 16:38 • Verfasst in ABAP Objects®
1
Antw.
Antw.
1976
Views
Views
3
Antw.
Antw.
3435
Views
Views
0
Antw.
Antw.
1139
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.