Evtl. Charset-Problem beim Empfang von Daten aus Polen

[morgworm]

Hallo, ich habe folgendes Problem:

Beliebige Binärdateien sollen von weltweit arbeitenden Nutzern eines in Delphi geschriebenen Tools in BLOB-Felder einer Oracle Datenbank geladen werden. Aus historischen Gründen wird die BDE verwendet. Dabei werden die Dateien in mehrere Teile gesplittet (wegen BDE-Cache-Begrenzungen) und beim Auslesen wieder zusammengesetzt.

Das Ganze funktioniert wunderbar, solange dieser Vorgang von deutschen Rechnern aus geschieht. Von Polen aus schleichen sich immer nach dem gleichen Muster Fehler ein. (Die Dateifragmente stehen dann schon falsch in der Datenbank, d.h. das Auslesen/Zusammensetzen funktioniert einwandfrei.)

Ich habe die Fehler mittels einer generierten Testdatei analysiert und folgende Vergleichsübersichten erstellt (Links "lvalue": Originalzeichen, Rechts: Änderung bei Daten von polnischen Rechnern), die NUR die Änderungen enthält, d.h. alle anderen Zeichen werden korrekt übermittelt (bis auf ein paar mit ASCII-Codes>240, die mein Programm komischerweise ignoriert hat):

Delphi-Quellcode:

--------HEX-------DEZ--------------BIN-------
ƒ=?    83=3F    131=63      10000011=00111111
ˆ=?    88=3F    136=63      10001000=00111111
Œ=S    8C=53    140=83      10001100=01010011
 =T    8D=54    141=84      10001101=01010100
 =Z    8F=5A    143=90      10001111=01011010
˜=?    98=3F    152=63      10011000=00111111
 =t    9D=74    157=116     10011101=01110100
Ÿ=z    9F=7A    159=122     10011111=01111010
¡=?    A1=3F    161=63      10100001=00111111
¢=?    A2=3F    162=63      10100010=00111111
£=L    A3=4C    163=76      10100011=01001100
¥=A    A5=41    165=65      10100101=01000001
ª=S    AA=53    170=83      10101010=01010011
¯=Z    AF=5A    175=90      10101111=01011010
²=?    B2=3F    178=63      10110010=00111111
³=l    B3=6C    179=108     10110011=01101100
¹=a    B9=61    185=97      10111001=01100001
º=s    BA=73    186=115     10111010=01110011
¼=L    BC=4C    188=76      10111100=01001100
½=?    BD=3F    189=63      10111101=00111111
¾=l    BE=6C    190=108     10111110=01101100
¿=z    BF=7A    191=122     10111111=01111010
À=R    C0=52    192=82      11000000=01010010
Ã=A    C3=41    195=65      11000011=01000001
Å=L    C5=4C    197=76      11000101=01001100
Æ=C    C6=43    198=67      11000110=01000011
È=C    C8=43    200=67      11001000=01000011
Ê=E    CA=45    202=69      11001010=01000101
Ì=E    CC=45    204=69      11001100=01000101
Ï=D    CF=44    207=68      11001111=01000100
Ñ=N    D1=4E    209=78      11010001=01001110
Ò=N    D2=4E    210=78      11010010=01001110
Õ=O    D5=4F    213=79      11010101=01001111
Ø=R    D8=52    216=82      11011000=01010010
Ù=U    D9=55    217=85      11011001=01010101
Û=U    DB=55    219=85      11011011=01010101
Þ=T    DE=54    222=84      11011110=01010100
ð=d    F0=64    240=100     11110000=01100100

Erkennt jemand ein Muster und kann eine Fehlerursache erahnen? Mich wundert, wie so etwas passieren kann, da doch ausdrücklich Binärdaten übertragen werden sollen.

Die BLOB-Felder werden per cds.Params.ParamByName('blbFile').LoadFromStream(f sPart, ftOraBlob) gefüllt.

Das entsprechende SQL dazu ist: INSERT INTO tblName (...) VALUES (...) RETURNING INTO :blbFile

Wäre für Ideen/Hinweise sehr dankbar!

Gruß François

[Bernhard Geyer]

Was für SQL-Feldtypen haben die Problematischen Felder?

[morgworm]

Das sind BLOB-Felder.

[Bernhard Geyer]

Bist du dir sicher das die Fehler durch den Eintrag in der DB auftreten oder nicht schon zuvor?

[morgworm]

Hmm... z.B. schon beim FileStream-Erzeugen?

Also es läuft ja so: Lokal hat der Benutzer eine Datei zu liegen - für die wird ein readonly-FileStream erzeugt. Der wird dann aufgeteilt in mehrere Teil-FileStreams, die gefüllt werden über fsPart.CopyFrom(fsFileStream, iReadByteSize), d.h. durch Byte-weises Kopieren. Diese werden dann über LoadFromStream vollständig in ein BLOB-Feld gestreamt.

Mehr passiert da nicht. An welcher Stelle kann da ein Fehler auftreten? Arbeiten FileStreams irgendwie auf ASCII-Basis?

Was man prüfen könnte, wäre, wie die Teil-Streams (fsPart) aussehen, bevor sie in die DB geladen werden... aber wenn da wirklich schon eine Veränderung zum Original sein sollte, würde das ja bedeuten, dass man in Polen eigentlich gar keine FileStreams sinnvoll verwenden kann, was eigenartig wäre.

[Bernhard Geyer]

Welchen Inhalt sollen diese FileStreams denn haben? Mit was werden sie gefüllt? Gibt der User Irgendwas in irgendeinem Formular ein und das wird dann binär gespeichert?

[DGL-luke]

Warum werden für die Teilstreams Filestreams und nicht Memorystreams benutzt?

Kannst du Code posten?

[morgworm]

Welchen Unterschied würde es machen, MemoryStreams zu verwenden?
Ich könnte das mal ausprobieren. Es gibt, soweit ich weiß, keinen besonderen Grund, warum wir einen FileStream statt eines MemoryStreams nehmen.

Mehr realen Code als meine wörtliche Beschreibung möchte ich nicht unbedingt preisgeben. Es passiert nicht mehr als ich beschrieben habe.

[Bernhard Geyer]

TFileStream sollte hier nichts ausmachen.

Es wäre aber seeehr gut zu sehen ob die Änderungen wirklich von der DB verursacht werden (Oracle ist ja auch nicht fehlerfrei).

Ansonsten geb ich dir den Tipp: Setzt eine VM-Ware auf und installier dort ein polnisches Windows. Anschließend kompilierst du deine Exe mit externen Debug-Infos und installierst in der VM den Borland Remote Debugger. Starte dein Anwendung in der VM und verbinde dich mit dieser Exe in der VM.

[morgworm]

@Bernhard: Der FileStream wird auf einer beliebigen lokalen Datei eines Benutzers, die er in unser System hochladen möchte, gebildet. Was für eine Datei das ist, kann ich nicht beeinflussen - es muss mit jeglichen Dateien wie Bildern, ZIP-Files, TXT, TAR, etc funktionieren.

Es wird nichts in einem Formular o.ä. gespeichert außer der Pfad zu der lokalen Datei des Benutzers, die er hochladen möchte. "Binär" an den Daten sind also nur ggf. die Daten der Datei selbst - nichts sonst irgendwie Generiertes.