Down- und Upload: Text gleich - hexadezimal ungleich
4 Beiträge
•
Seite 1 von 1
4 Beiträge
Seite 1 von 1
Hallo,
ich lade eine Datei als .txt runter und später wieder hoch. Beim Abgleich der Datenbank-Daten mit den upgeloadeten (sie sollen gleich sein) wirft mir SAP ein Feld raus, das textlich ("VERTRAGSSTRAFE 2% = 524,87# UND AUFTRAGSSPERRE")auch absolut identisch ist (Typ und Länge sowieso). Erst bei der hexadezimalen Ansicht fällt auf, dass an einer Stelle beim Download die 80 steht und beim Upload die 23, scheinbar im Zusammenhang mit der #.
Hat irgendwer eine Idee, wodurch der Unterschied entsteht?
(Eine Vermutung ist: Die # kam in den Text, da das ?-Zeichen nicht abgelegt werden konnte. Aber ganz ergibt das keinen Sinn, weil auf der Datenbank ja nun die # abgelegt ist. Also sollte es beim Down- und Upload ja auch wieder identisch sein, oder?)
Im Voraus vielen Dank!
Gruß, kle (21.12.05)
ich lade eine Datei als .txt runter und später wieder hoch. Beim Abgleich der Datenbank-Daten mit den upgeloadeten (sie sollen gleich sein) wirft mir SAP ein Feld raus, das textlich ("VERTRAGSSTRAFE 2% = 524,87# UND AUFTRAGSSPERRE")auch absolut identisch ist (Typ und Länge sowieso). Erst bei der hexadezimalen Ansicht fällt auf, dass an einer Stelle beim Download die 80 steht und beim Upload die 23, scheinbar im Zusammenhang mit der #.
Hat irgendwer eine Idee, wodurch der Unterschied entsteht?
(Eine Vermutung ist: Die # kam in den Text, da das ?-Zeichen nicht abgelegt werden konnte. Aber ganz ergibt das keinen Sinn, weil auf der Datenbank ja nun die # abgelegt ist. Also sollte es beim Down- und Upload ja auch wieder identisch sein, oder?)
Im Voraus vielen Dank!
Gruß, kle (21.12.05)
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo kle,
1. Meines Wissens werden alle Zeichen, die nicht dargestellt werden können, als # dargestellt.
2. Kann es sein, daß der Zeilenumbruch einmal als CR/LF und einmal als LF dargestellt ist (vgl. FTP als ASCII/Binär zwischen Unix und Windowsmaschinen)
Hoffentlich helfen Dir diese Gedanken.
MfG
Thomas R.
1. Meines Wissens werden alle Zeichen, die nicht dargestellt werden können, als # dargestellt.
2. Kann es sein, daß der Zeilenumbruch einmal als CR/LF und einmal als LF dargestellt ist (vgl. FTP als ASCII/Binär zwischen Unix und Windowsmaschinen)
Hoffentlich helfen Dir diese Gedanken.
MfG
Thomas R.
Hallo Thomas,
herzlichen Dank für Deine schnelle Antwort. 1. ist schon mal hilfreich. 2. gute Idee, kann aber meines Erachtens nicht sein, da der Datensatz einzeilig abgelegt ist (zumindest passt er, wenn ich ihn in Excel öffne, in eine Zeile).
Beste Grüße,
kle
herzlichen Dank für Deine schnelle Antwort. 1. ist schon mal hilfreich. 2. gute Idee, kann aber meines Erachtens nicht sein, da der Datensatz einzeilig abgelegt ist (zumindest passt er, wenn ich ihn in Excel öffne, in eine Zeile).
Beste Grüße,
kle
Hallo kle,
wenn Du mit der Aussage recht hast, dass das Zeichen im String im R/3 vor dem Download 0x80 und danach 0x23 ist, dann liegt das daran, dass das Nummernzeichen # den Hex-Wert 0x23 hat.
Das bedeutet dann auch, dass es zu einer Zeichenumsetzung kam.
Da das EUR-Zeichen nicht im regulären (0x00 - 0x7f) oder erweiterten (0x00 - 0xff) ASCII-Zeichensatz definiert ist, scheint Ihr einen Zeichensatz zu verwenden, der das Zeichen 128(0x80) als EUR-Zeichen darstellt.
In Unicode liegt das EUR-Zeichen bei 0x20ac (decode-unicode.org)
Nachtrag:
gemäß Zeichensatzanzeige (Windoof) kann man das EUR-Zeichen mit Tastenkombination Alt-128 eingeben. (damit sind wir aber trotzdem nicht weiter...
)
wenn Du mit der Aussage recht hast, dass das Zeichen im String im R/3 vor dem Download 0x80 und danach 0x23 ist, dann liegt das daran, dass das Nummernzeichen # den Hex-Wert 0x23 hat.
Das bedeutet dann auch, dass es zu einer Zeichenumsetzung kam.
Da das EUR-Zeichen nicht im regulären (0x00 - 0x7f) oder erweiterten (0x00 - 0xff) ASCII-Zeichensatz definiert ist, scheint Ihr einen Zeichensatz zu verwenden, der das Zeichen 128(0x80) als EUR-Zeichen darstellt.
In Unicode liegt das EUR-Zeichen bei 0x20ac (decode-unicode.org)
Nachtrag:
gemäß Zeichensatzanzeige (Windoof) kann man das EUR-Zeichen mit Tastenkombination Alt-128 eingeben. (damit sind wir aber trotzdem nicht weiter...
)
Gruß
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
1541
Views
Views
2
Antw.
Antw.
794
Views
Views
CDS-View/AMDP-Klasse: WHERE-Bedingung 'ungleich'
von Anne_A » 22.04.2024 10:10 • Verfasst in ABAP® für Anfänger
von Anne_A » 22.04.2024 10:10 • Verfasst in ABAP® für Anfänger
7
Antw.
Antw.
843
Views
Views
10
Antw.
Antw.
10565
Views
Views
1
Antw.
Antw.
1742
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor einer Stunde von ralf.wenzel 104 / 9989
vor einer Stunde von ralf.wenzel 104 / 9989
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
Umherspringende Methoden im quelltextbasierten Class Builder
vor einer Stunde von ralf.wenzel 104 / 9989
vor einer Stunde von ralf.wenzel 104 / 9989