Re: Schnittstelle - Winsock, String, Unicode

vehe wrote:
[bitte vollständigen Namen eintragen, danke]

Ich muss eine Schnittstelle realisieren, die Daten über TCP/IP
austauscht. Der Client wurde in Java umgesetzt und der Server muss in
VB6 geschrieben sein. Ich habe ein kleines Demo-Programm vorliegen und
verwende ein Winsock-Control. Die Verbindung zur (Java-) Applikation
wird hergestellt und Daten werden von dieser Applikation an den
VB6-Server gesendet und von ihm korrekt empfangen. Wird nun eine
Bestätigung in Form von <ACK> an den Client gesendet, erscheint im
Textfeld "??????"
Java arbeitet mit Big Endian Unicode, was auch höchstwahrscheinlich
der Grund für diese o. g. Darstellung ist.

Kannst Du den entsprechenden code, durch den Daten gesendet/empfangen
werden, posten?

Daten werden bei TCP/IP als octet-stream (bytestream) übertragen. Die
Bytereihenfolge wird hierbei als "Network Byte Order" bezeichnet. Wenn
Du also Daten vorliegen hast, die aus 16- oder 32-bit-sequenzen
bestehen, sollten diese vor dem Senden konvertiert werden, und zwar
"host to network", die entsprechende Funktion heißt dann z.B. htonl()
für long (32-bit-werte) und htons for short (16-bit-werte). Der
Empfänger konvertiert dann in die andere Richtung, also "network to
host", ntohl() und ntohs(). Das müsstest Du theoretisch für jedes
einzelne Zeichen des unicode-strings machen, sofern Du tatsächlich
unicode Strings übertragen willst/musst. So wird eine
Grundkompatibilität hergestellt, sodaß das Speicherformat auf den Hosts
keine Rolle spielt.

Aber:
Es ist nicht besonders empfehlenswert, Unicode für tcp/ip zu verwenden.
TCP ist ein reines Transportprotokoll für einen octet-stream. Bei einer
proprietären Client/Server-Anwendung ist es daher das einfachste, nur
8-bit-sequenzen zu übertragen, weshalb Unicode-Strings zuvor konvertiert
werden müssen. Das geht aber nur, wenn der Unicode-String ausschließlich
Zeichen aus dem 8bit ziel-Zeichensatz enthält, oder noch besser nur 7bit
US-ASCII (sofern nicht garantiert werden kann, daß Sender und Empfänger
denselben Zeichensatz verwenden).

"Zwischen" TCP und den zu übertragenen Daten sollte noch ein
"Application Layer Protocol" liegen, d.h. ein Mechanismus, der den
eigentlichen Daten Ihre Bedeutung verleiht (Dazu zählt z.B. die von Dir
verwendete "<ACK>"-Sequenz als "Bestätigung"). Sollten wirklich
Unicode-Strings unterstützt werden (um Mehrsprachigkeit zu ermöglichen),
dann sollte dieses Protokoll z.B. eine Kennzeichnung oder Kodierung
dieser Strings ermöglichen. Die einfachste Variante wäre dann,
betreffende Datenfelder grundsätzlich als UTF8 zu kodieren, und beim
Empfang wieder zu dekodieren.

Bei UTF8 werden alle Unicode-Zeichen kodiert, die nicht als 7bit
US-ASCII darstellbar sind. Der String "für" mit ursprünglich 6 byte
(Unicode) wird dann zu einem 4-byte langen, utf8-kodierten String. f und
r bleiben erhalten, aus dem ü werden zwei zeichen. Diese kodierung ist
auf der Gegenseite eindeutig umkehrbar.

Beim Senden/Empfangen ist zudem darauf zu achten, daß die Daten auch
tatsächlich als byte-sequenz (in VB: byte-array) empfangen werden.
winsock.getData ist dann auch ein parameter mitzugeben, welcher Datentyp
verwendet werden soll (bei strings 'vbString', bei einem byte-array
'vbArray OR vbByte'.

Winsock.senddata sendet kein Unicode, auch wenn der String zeichen
enthält, die nicht mit 8bit darstellbar sind (das kann Datenverlust
bedeuten!). Das bedeutet für die Java-Seite, daß empfangene
byte-sequenzen nicht gleich in einen (unicode-) string "gesteckt" werden
dürfen, sondern entsprechend konvertiert werden müssen. Allerdings kenne
ich mich mit Java nicht aus und weiß auch nicht, wie die
socket-Programmierung auf java-seite aussieht.

Inzwischen stellt sich mir die Frage, ob diese Schnittstelle überhaupt
realisierbar ist.

Doch, das ist sicher machbar. :)
Wie gesagt, poste mal die entsprechenden Code-Abschnitte (beides, vb und
java).


Viele Grüße,
Andreas

.

Relevant Pages

  • Re: Help me!! Why java is so popular
    ... You are basically arguing that "Java is slow because it is slow". ... > Also, a JVM can pay attention to usage, provide caching, adapt at run ... I have no use for unicode in my ...
    (comp.lang.java.programmer)
  • Re: JNI / localization / filenames
    ... fact that Java and Unicode don't match. ... fundamental assumption of the Java programming language and APIs. ... characters and enables the Java platform to continue to track the Unicode ... of 16-bit quantities using UTF-16. ...
    (comp.lang.java.programmer)
  • Re: how do I expand a unicode string to its visual UTF8 representation?
    ... What Java uses internally to represent String ... Java was conceived with Unicode 3.0 in mind, ... which does *not* represent a character ...
    (comp.lang.java.programmer)
  • Re: how to communicate unsigned char* to Java
    ... Actually at this point I think I figured out the code in Java fore reading ... However, my compiler doesn't recognize FileStream and BinaryWriter, ... Strings in Java are Unicode. ... said that java is having unicode-16 for string which is indeed 16 bit ...
    (microsoft.public.win32.programmer.networks)
  • Re: Neu in 1.6: getpass
    ... wenn Java ... >> Fehlerhaft implementieren ... ... es wohl noch Probleme mit dem Zeichen rechts unten in der Ecke. ... Next by Date: ...
    (de.comp.lang.java)
Loading