Unicode-Konvertierung Sonderzeichen ("Ã "nach "à")
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
Hallo Leute,
meinem Unwissen geschuldet bin ich leider wieder mal ratlos. Leider fällt es mir schon schwer, eine klare Frage zu formulieren, da ich auf diesem Gebiet absoluter Laie bin.
Es geht wohl grob um Unicode-Konvertierung, evtl. auch um Codepages? Genauer um Sonderzeichen, in diesem Fall um den Buchstaben "a" mit Accent grave, also "à".
Ist es möglich, dieses Zeichen "à" mittels ABAP in den Wert "Ã " zu konvertieren und umgekehrt?
***
Hier noch etwas zusätzliche Hintergrundinfo:
In einer Eigenprogrammierung greifen wir auf die XML-RPC-Schnittstelle des Bundeszentralamts für Steuern zu. Die Schnittstelle dient zur Prüfung ausländischer Umsatzsteuer-ID's. URL: https://evatr.bff-online.de/eVatR/xmlrpc/
Die Schnittstelle erwartet eingangsseitig URL-Coding bzw. Percent Encoding. Der Name der Testfirma "Grenouilles S.à.r.l." wird daher wie folgt in der Anfrage übermittelt: "Grenouilles%20S.%c3%a0.r.l."
Ausgangsseitig antwortet die Schnittstelle jedoch dann mit folgendem Wert: "Grenouilles S.Ã .r.l.", welcher in SAP wieder "zurück"-konvertiert werden müsste in "Grenouilles S.à.r.l.".
Im habe im Web einen Unicode-Konverter gefunden: URL: https://www.branah.com/unicode-converter
Im Anhang ein Screenshot davon. Ich frage mich, ob das auch in SAP mit ABAP in etwa so abbildbar wäre?
***
Danke für jede Rückmeldung und Anregung. Es würde mir schon helfen, zu wissen, ob mein Vorhaben überhaupt möglich ist und logisch Sinn ergibt... Ich habe mich schon eine ganze Weile damit beschäftigt, aber bin noch nicht nennenswert weit gekommen.
Viele Grüße
meinem Unwissen geschuldet bin ich leider wieder mal ratlos. Leider fällt es mir schon schwer, eine klare Frage zu formulieren, da ich auf diesem Gebiet absoluter Laie bin.
Es geht wohl grob um Unicode-Konvertierung, evtl. auch um Codepages? Genauer um Sonderzeichen, in diesem Fall um den Buchstaben "a" mit Accent grave, also "à".
Ist es möglich, dieses Zeichen "à" mittels ABAP in den Wert "Ã " zu konvertieren und umgekehrt?
***
Hier noch etwas zusätzliche Hintergrundinfo:
In einer Eigenprogrammierung greifen wir auf die XML-RPC-Schnittstelle des Bundeszentralamts für Steuern zu. Die Schnittstelle dient zur Prüfung ausländischer Umsatzsteuer-ID's. URL: https://evatr.bff-online.de/eVatR/xmlrpc/
Die Schnittstelle erwartet eingangsseitig URL-Coding bzw. Percent Encoding. Der Name der Testfirma "Grenouilles S.à.r.l." wird daher wie folgt in der Anfrage übermittelt: "Grenouilles%20S.%c3%a0.r.l."
Ausgangsseitig antwortet die Schnittstelle jedoch dann mit folgendem Wert: "Grenouilles S.Ã .r.l.", welcher in SAP wieder "zurück"-konvertiert werden müsste in "Grenouilles S.à.r.l.".
Im habe im Web einen Unicode-Konverter gefunden: URL: https://www.branah.com/unicode-converter
Im Anhang ein Screenshot davon. Ich frage mich, ob das auch in SAP mit ABAP in etwa so abbildbar wäre?
***
Danke für jede Rückmeldung und Anregung. Es würde mir schon helfen, zu wissen, ob mein Vorhaben überhaupt möglich ist und logisch Sinn ergibt... Ich habe mich schon eine ganze Weile damit beschäftigt, aber bin noch nicht nennenswert weit gekommen.
Viele Grüße
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Habt ihr beim Entgegennehmen des Werts eine Möglichkeit, das Encoding zu steuern?
Ihr übergebt und bekommt da UTF-8 (8 bis 32bit) zurück und interpretiert es vermutlich als ISO-8859-1 (8bit). D.h. dann aber auch, dass das UTF-8-Zeichen à (hex C3A0) mit dem 8bit-Encoding als zwei Zeichen interpretiert wird (man sieht auch das "Leerzeichen" hinter Ã)!
Ihr übergebt und bekommt da UTF-8 (8 bis 32bit) zurück und interpretiert es vermutlich als ISO-8859-1 (8bit). D.h. dann aber auch, dass das UTF-8-Zeichen à (hex C3A0) mit dem 8bit-Encoding als zwei Zeichen interpretiert wird (man sieht auch das "Leerzeichen" hinter Ã)!
Moin,
habe ebenfalls ein Programm für genau diese API gebaut, das geht etwas einfacher.
1. URL-Encoding
Die übergebenen Parameter müssen escaped werden, dafür gibt es eine eingebaute Funktion:
Beispiel:
2. Die Antwort der API muss eigentlich nicht rückkonvertiert werden, zumindest finde ich in meinem Coding nichts.
habe ebenfalls ein Programm für genau diese API gebaut, das geht etwas einfacher.
1. URL-Encoding
Die übergebenen Parameter müssen escaped werden, dafür gibt es eine eingebaute Funktion:
Beispiel:
Code: Alles auswählen.
METHOD escape_param.
result = escape( val = parameter
format = cl_abap_format=>e_url_full ).
ENDMETHOD.
METHOD build_url.
DATA(url_params) = '?UstId_1=' && escape_param( mv_own_vat )
&& '&UstId_2=' && escape_param( customer_data->stceg )
&& '&Firmenname=' && escape_param( customer_data->name1 )
&& '&Ort=' && escape_param( customer_data->ort01 )
&& '&PLZ=' && escape_param( customer_data->pstlz )
&& '&Strasse=' && escape_param( customer_data->stras )
&& '&Druck=' && escape_param( c_no ).
result = c_api_base_url && url_params.
ENDMETHOD.
Beitrag
von black_adept (Top Expert / 4086 / 126 /
940
)
»
Evtl. kann dir die Klasse CL_ABAP_CONV_IN_CE das umkonvertieren wenn du weißt was die Quellcodepage ist.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Gokar
Danke erstmal für die Rückmeldungen! :)
@qyurryus
Ausgangsseitig bei uns verwende ich folgende Methode für die Konvertierung bzw. das Escapen nach URL-Coding: cl_http_utility=>escape_url( )
Dann übergebe ich die Anfrage-Daten mittels Funktionsbaustein HTTP_GET und erhalte über Parameter-Tabelle response_entity_body die Rückgabewerte. In der Rückgabetabelle ist dann auch schon direkt "S.Ã .r.l." enthalten, anstatt "S.à.r.l.".
Kann es vielleicht sein, dass ich meine Variable für die Rückgabetabelle anders definieren muss. Aktuell hab ich das ganz lieblos wie folgt drin:
Und
@black_adept + @fr-g
Ich habe leider wie eingangs erwähnt kaum Ahnung von der ganzen Materie und weiß gar nicht, um welche Codepages es sich hier handeln könnte oder wie ich das rausfinden kann.
Auf Klasse "CL_ABAP_CONV_IN_CE" bin ich schon gestoßen und habe damit getestet. Aber wie gesagt, ich weiß gar nicht, welche Encoding-Parameter ich hier mitgeben soll...
@qyurryus
Ausgangsseitig bei uns verwende ich folgende Methode für die Konvertierung bzw. das Escapen nach URL-Coding: cl_http_utility=>escape_url( )
Dann übergebe ich die Anfrage-Daten mittels Funktionsbaustein HTTP_GET und erhalte über Parameter-Tabelle response_entity_body die Rückgabewerte. In der Rückgabetabelle ist dann auch schon direkt "S.Ã .r.l." enthalten, anstatt "S.à.r.l.".
Kann es vielleicht sein, dass ich meine Variable für die Rückgabetabelle anders definieren muss. Aktuell hab ich das ganz lieblos wie folgt drin:
Code: Alles auswählen.
"Daten, HTTP-Antwort
TYPES: BEGIN OF ty_s_text,
line(9999),
END OF ty_s_text.Code: Alles auswählen.
DATA: t_response_xml TYPE STANDARD TABLE OF ty_s_text WITH DEFAULT KEY.@black_adept + @fr-g
Ich habe leider wie eingangs erwähnt kaum Ahnung von der ganzen Materie und weiß gar nicht, um welche Codepages es sich hier handeln könnte oder wie ich das rausfinden kann.
Auf Klasse "CL_ABAP_CONV_IN_CE" bin ich schon gestoßen und habe damit getestet. Aber wie gesagt, ich weiß gar nicht, welche Encoding-Parameter ich hier mitgeben soll...
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Ich würde dir anstatt des Funktionsbausteins, die Klasse CL_HTTP_CLIENT empfehlen. Da kannst du dir die Daten aus dem Response z.B. als XSTRING zurückliefern lassen und die Konvertierung dann über CL_ABAP_CONV_IN_CE selbst erledigen.
Das Problem beim HTTP_GET mit der Codepage ist, wenn du ein CHAR-Feld angibst, wird implizit die Codepage des Applikationsservers als Zielformat angenommen. Wenn nun die Gegenstelle eine "falsche" Codierung im Header angibt oder sonst irgendwo beim Import ein Fehler auftritt entsteht ziemlicher Kauderwelsch.
Ich hatte mal so ein ähnliches Problem bei der FTP-Kommunikation:
Der Server hat alles in UTF-8 übermittelt.
Die SAP Bausteine haben es von der Konsole aber per IS0-8859-1 ausgelesen und da wir Unicode einsetzen ist das Ergebnis dann kaum wiederzuerkennen gewesen.
Ich musste dann mit CL_ABAP_CONV_OUT_CE den Unicode Text unter Angabe der eigentlich falschen Codepage IS0-8859-1 in einen XSTRING zurückwandeln und daraus dann mit CL_ABAP_CONV_IN_CE als UTF-8 wieder importieren.
Das Problem beim HTTP_GET mit der Codepage ist, wenn du ein CHAR-Feld angibst, wird implizit die Codepage des Applikationsservers als Zielformat angenommen. Wenn nun die Gegenstelle eine "falsche" Codierung im Header angibt oder sonst irgendwo beim Import ein Fehler auftritt entsteht ziemlicher Kauderwelsch.
Ich hatte mal so ein ähnliches Problem bei der FTP-Kommunikation:
Der Server hat alles in UTF-8 übermittelt.
Die SAP Bausteine haben es von der Konsole aber per IS0-8859-1 ausgelesen und da wir Unicode einsetzen ist das Ergebnis dann kaum wiederzuerkennen gewesen.
Ich musste dann mit CL_ABAP_CONV_OUT_CE den Unicode Text unter Angabe der eigentlich falschen Codepage IS0-8859-1 in einen XSTRING zurückwandeln und daraus dann mit CL_ABAP_CONV_IN_CE als UTF-8 wieder importieren.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
Gokar
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
Danke für den Kommentar.a-dead-trousers hat geschrieben: ↑05.08.2020 10:32Ich würde dir anstatt des Funktionsbausteins, die Klasse CL_HTTP_CLIENT empfehlen. Da kannst du dir die Daten aus dem Response z.B. als XSTRING zurückliefern lassen und die Konvertierung dann über CL_ABAP_CONV_IN_CE selbst erledigen.
Das Problem beim HTTP_GET mit der Codepage ist, wenn du ein CHAR-Feld angibst, wird implizit die Codepage des Applikationsservers als Zielformat angenommen. Wenn nun die Gegenstelle eine "falsche" Codierung im Header angibt oder sonst irgendwo beim Import ein Fehler auftritt entsteht ziemlicher Kauderwelsch.
Ich hatte mal so ein ähnliches Problem bei der FTP-Kommunikation:
Der Server hat alles in UTF-8 übermittelt.
Die SAP Bausteine haben es von der Konsole aber per IS0-8859-1 ausgelesen und da wir Unicode einsetzen ist das Ergebnis dann kaum wiederzuerkennen gewesen.
Ich musste dann mit CL_ABAP_CONV_OUT_CE den Unicode Text unter Angabe der eigentlich falschen Codepage IS0-8859-1 in einen XSTRING zurückwandeln und daraus dann mit CL_ABAP_CONV_IN_CE als UTF-8 wieder importieren.
Ich schaue mir die Klasse CL_HTTP_CLIENT auf jeden Fall mal an. Den Funktionsbaustein HTTP_GET hatte ich damals auch nur verwendet, weil ich überhaupt keine Ahnung hatte, wie ich eine Kommunikation mit der Schnittstelle bewerkstelligen kann und irgendwie über den Fu-Ba gestolpert bin und dann erstmal damit zufrieden war.
Geht das in die richtige Richtung wenn ich mal vorsichtig formuliere, dass durch die unterschiedlichen Codepages quasi Zeichen oder Informationen verloren gehen oder zumindest Informationen "zerteilt" werden?
Sorry, ist nur ein schwacher Versuch, einer ganz groben technischen Erklärung für mich selbst :D
Lieben Gruß
@a-dead-trousers + @Rest
Ich habe mich zwischenzeitlich mit der Klasse CL_HTTP_CLIENT beschäftigt und kann vermelden, dass es nun funktioniert. Hier ein Ausschnitt aus dem Coding. Nicht beirren lassen, die Variable "i_s_request_data" ist eine interne Struktur, in der ich einige Informationen gesammelt ablege...
Außerdem interessant (zumindest für mich an der Stelle):
Verwendet man anstatt der Methode IF_HTTP_RESPONSE->GET_CDATA( ) die Methode GET_DATA( ) und liest den zurückgelieferten XSTRING mit Endcoding 'UTF-8' dann passen die Sonderzeichen (= 'à'). Liest man den XSTRING mit SAP-Encoding '1100' (iso-8859-1) dann kommt auch wieder anstatt 'à' zurück: 'Ã '.
Hierzu auch ein knapper Ausschnitt:
Danke an alle für die hilfreichen und netten Rückmeldungen. Ihr habt mir SEHR weitergeholfen.
Liebe Grüße :)
Ich habe mich zwischenzeitlich mit der Klasse CL_HTTP_CLIENT beschäftigt und kann vermelden, dass es nun funktioniert. Hier ein Ausschnitt aus dem Coding. Nicht beirren lassen, die Variable "i_s_request_data" ist eine interne Struktur, in der ich einige Informationen gesammelt ablege...
Code: Alles auswählen.
DATA: i_r_exception TYPE REF TO cx_root.
DATA: i_r_client TYPE REF TO if_http_client.
"...
TRY.
"Client-Objekt erzeugen
cl_http_client=>create_by_url(
EXPORTING
url = i_s_request_data-url_no_special_signs
IMPORTING
client = i_r_client
).
IF i_r_client IS BOUND.
"HTTP GET senden, evtl. Timeout angeben
i_r_client->send( timeout = if_http_client=>co_timeout_default ).
"Response lesen
i_r_client->receive( ).
"HTTP Return Code holen
i_r_client->response->get_status(
IMPORTING
code = i_s_request_data-status_http_code
reason = i_s_request_data-status_http_text
).
"Header-Daten der Übertragung
i_r_client->response->get_header_fields( CHANGING fields = i_s_request_data-t_header_fields ).
"Wenn Status 200 (Ok)
IF i_s_request_data-status_http_code EQ 200.
"HTTP Body als Character-Daten
i_v_string1 = i_r_client->response->get_cdata( ).
"Zeilenweise in interne Tabelle auftrennen
SPLIT i_v_string1 AT cl_abap_char_utilities=>newline INTO TABLE i_s_request_data-t_response_xml IN CHARACTER MODE.
ENDIF.
ENDIF.
CATCH cx_root INTO i_r_exception.
i_v_string1 = i_r_exception->get_text( ).
CONCATENATE 'Fehler bei HTTP-Anfrage:' i_v_string1 INTO i_v_string1 SEPARATED BY space.
MOVE i_v_string1 TO i_s_request_data-status_http.
me->add_message( EXPORTING p_i_v_text = i_s_request_data-status_http
p_i_v_type = 'E'
CHANGING p_c_s_data_debitor = p_c_l_data_debitor ).
ENDTRY.
Verwendet man anstatt der Methode IF_HTTP_RESPONSE->GET_CDATA( ) die Methode GET_DATA( ) und liest den zurückgelieferten XSTRING mit Endcoding 'UTF-8' dann passen die Sonderzeichen (= 'à'). Liest man den XSTRING mit SAP-Encoding '1100' (iso-8859-1) dann kommt auch wieder anstatt 'à' zurück: 'Ã '.
Hierzu auch ein knapper Ausschnitt:
Code: Alles auswählen.
DATA: r_client TYPE REF TO if_http_client.
DATA: r_conv TYPE REF TO cl_abap_conv_in_ce.
DATA: v_xstring TYPE xstring.
DATA: v_string TYPE string.
"HTTP-Anfrage, Client-Objekt erzeugen, etc.
cl_http_client=>create_by_url( EXPORTING url = 'https://...' IMPORTING client = r_client ).
"...
"HTTP Body binär
v_xstring = r_client->response->get_data( ).
"xstring -> string - UTF-8
r_conv = cl_abap_conv_in_ce=>create( input = v_xstring encoding = 'UTF-8' ).
r_conv->read( IMPORTING data = v_string ). "<-- Sonderzeichen 'à' = O.K.
"xstring -> string - iso-8859-1
r_conv = cl_abap_conv_in_ce=>create( input = v_xstring encoding = '1100' ).
r_conv->read( IMPORTING data = v_string ). "<-- Sonderzeichen 'à' entspricht jetzt: 'Ã '
Liebe Grüße :)
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Das entspricht also genau dem Verhalten, das du zu Anfang hattest und ist für mich ein guter Beleg dafür, das die "alten" Sachen in ABAP meist nicht für "moderne" Softwareumgebungen geeignet bzw. ausgelegt sind.Gokar hat geschrieben: ↑05.08.2020 18:01Verwendet man anstatt der Methode IF_HTTP_RESPONSE->GET_CDATA( ) die Methode GET_DATA( ) und liest den zurückgelieferten XSTRING mit Endcoding 'UTF-8' dann passen die Sonderzeichen (= 'à'). Liest man den XSTRING mit SAP-Encoding '1100' (iso-8859-1) dann kommt auch wieder anstatt 'à' zurück: 'Ã '
In vielen (den meisten?) Fällen hat die SAP aber schon nachgebessert und bietet die passenden Alternativen an:
CL_DD_DOCUMENT => IF_IXML
HTTP_GET => CL_HTTP_CLIENT
SO_NEW_DOCUMENT_ATT_SEND_API1 => CL_BCS
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
Gokar
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
Yep, ich benutze die Klasse cl_ixml zum Parsen der Response und muss keinerlei Konvertierungs-Unfug tätigen.a-dead-trousers hat geschrieben: ↑05.08.2020 18:21Das entspricht also genau dem Verhalten, das du zu Anfang hattest und ist für mich ein guter Beleg dafür, das die "alten" Sachen in ABAP meist nicht für "moderne" Softwareumgebungen geeignet bzw. ausgelegt sind.
In vielen (den meisten?) Fällen hat die SAP aber schon nachgebessert und bietet die passenden Alternativen an:
CL_DD_DOCUMENT => IF_IXML
HTTP_GET => CL_HTTP_CLIENT
SO_NEW_DOCUMENT_ATT_SEND_API1 => CL_BCS
Danke, werde ich mir mal vormerken, ist sicherlich noch hilfreich! :)a-dead-trousers hat geschrieben: ↑05.08.2020 18:21CL_DD_DOCUMENT => IF_IXML
HTTP_GET => CL_HTTP_CLIENT
SO_NEW_DOCUMENT_ATT_SEND_API1 => CL_BCS
Ich werde mich Morgen oderso nochmal abschließend hier melden. Ich hatte heute leider nicht genug Zeit noch etwas zu testen, um das für mich zum Abschluss zu bringen.
Hallo nochmal,
wie schon erwähnt funktioniert über Klasse CL_HTTP_CLIENT nun ja alles prima. Das Sonderzeichen 'à' entspricht dann in der HTTP-Antwort hexadezimal dem Wert 'C3A0'. Der Hexa-Wert 'C3A0' konvertiert nach UTF-8 als string entspricht dann auch wieder 'à'. Der Hexa-Wert 'C3A0' konvertiert nach iso-8859-1 als string entspricht: 'Ã '. Das Ganze funktioniert jeweils in beide Richtungen (xstring --> string --> xstring ...).
Weist man jedoch einem String in SAP den Wert 'Ã ' zu und konvertiert ihn nach iso-8859-1 in einen xstring ergibt sich der Wert: 'C320', anstatt 'C3A0'. Der Wert 'C320' lässt sich dann auch nicht mehr nach UTF-8 als string konvertieren, es kommt zu einer Ausnahme vom Typ CX_SY_CONVERSION_CODEPAGE.
Die HTTP-Antwort-Daten über Funktionsbaustein HTTP_GET enthalten auch schon direkt den Wert 'Ã ', in zeichemartigem Format. Es gibt keine Antwort-Daten in hexadezimal. Es ergibt sich der Fall aus dem obigen Absatz. Eine Konvertiertung nach iso-8859-1 in hexadezimal ergibt: 'C320'. Eine Konvertierung nach UTF-8 hexadezimal ist in Folge nicht möglich bzw. schlägt fehlt.
Für mich war das jetzt nochmal ganz interessant. Sollte es dem Ein oder Anderen zukünftig weiterhelfen, hat es sich ja gelohnt. Sofern ich da jetzt noch Fehler drin haben sollte, mich gerne korrigieren.
Abschließend erneut ein Danke an alle Beteiligten und viele Grüße + schönes WE! 😊
wie schon erwähnt funktioniert über Klasse CL_HTTP_CLIENT nun ja alles prima. Das Sonderzeichen 'à' entspricht dann in der HTTP-Antwort hexadezimal dem Wert 'C3A0'. Der Hexa-Wert 'C3A0' konvertiert nach UTF-8 als string entspricht dann auch wieder 'à'. Der Hexa-Wert 'C3A0' konvertiert nach iso-8859-1 als string entspricht: 'Ã '. Das Ganze funktioniert jeweils in beide Richtungen (xstring --> string --> xstring ...).
Weist man jedoch einem String in SAP den Wert 'Ã ' zu und konvertiert ihn nach iso-8859-1 in einen xstring ergibt sich der Wert: 'C320', anstatt 'C3A0'. Der Wert 'C320' lässt sich dann auch nicht mehr nach UTF-8 als string konvertieren, es kommt zu einer Ausnahme vom Typ CX_SY_CONVERSION_CODEPAGE.
Die HTTP-Antwort-Daten über Funktionsbaustein HTTP_GET enthalten auch schon direkt den Wert 'Ã ', in zeichemartigem Format. Es gibt keine Antwort-Daten in hexadezimal. Es ergibt sich der Fall aus dem obigen Absatz. Eine Konvertiertung nach iso-8859-1 in hexadezimal ergibt: 'C320'. Eine Konvertierung nach UTF-8 hexadezimal ist in Folge nicht möglich bzw. schlägt fehlt.
Für mich war das jetzt nochmal ganz interessant. Sollte es dem Ein oder Anderen zukünftig weiterhelfen, hat es sich ja gelohnt. Sofern ich da jetzt noch Fehler drin haben sollte, mich gerne korrigieren.
Abschließend erneut ein Danke an alle Beteiligten und viele Grüße + schönes WE! 😊
Seite 1 von 1
Vergleichbare Themen
0
Antw.
Antw.
1161
Views
Views
0
Antw.
Antw.
1470
Views
Views
0
Antw.
Antw.
2378
Views
Views
Unicode-Strings via ABAP-OLE2 to EXCEL (NON-Unicode-SAP-Sys)
von fritz_herma » 15.03.2007 14:17 • Verfasst in ABAP® Core
von fritz_herma » 15.03.2007 14:17 • Verfasst in ABAP® Core
1
Antw.
Antw.
2367
Views
Views
0
Antw.
Antw.
1702
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 19 Stunden von DeathAndPain 4 / 837
vor 19 Stunden von DeathAndPain 4 / 837
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 19 Stunden von DeathAndPain 4 / 837
vor 19 Stunden von DeathAndPain 4 / 837