| |
Fortgeschrittene ProgrammierungRe: StrConv auf einem DBCS-System (z.B. China-Taiwan) | | | Autor: Blackbox | Datum: 05.02.18 20:17 |
| Hallo Woellmi,
StrConv hat Konstante für verschiedene asiatische Dialekte.
vbFromUnicode ist für alle Unicode-Variante. Das bedeutet aber,
dass Vb intern Unicode in einen BSTR (CCOMBSTR) umsetzt und diese
dann als String verwendet. VB verwendet nur diesen BSTR.
Zur Erinnerung ein BSTR ist Speicher, der mit der Anzahl der Zeichen in dem
String und dann die eigentlichen Buchstaben in Unicode sind. Somit:
"10 H e l l o" .... Würde VB als String für "Hello" umgesetzt aussehen, obwohl
Hello, da sind wir uns einig, nur 5 Buchstaben enthält.
Da ich Dein Problem nicht direkt nachvollziehen kann ein Vorschlag:
nehme anstatt der Konstante
vbUnicode
vbFromUnicode
diese Konstante:
vbWide
ich habe diese Konstante für mich noch nie gebraucht.
Beitrag wurde zuletzt am 05.02.18 um 20:32:59 editiert. | |
Re: StrConv auf einem DBCS-System (z.B. China-Taiwan) | | | Autor: Woellmi | Datum: 06.02.18 08:37 |
| Hallo Blackbox,
danke für Deine Info.
Dies hatte ich auch gedacht. Es sieht ja in der Doku so aus, als ob "vbWide" und "vbNarrow"
extra für den asiatischen Bereich als Entsprechungen zu "vbUniCode" und "vbFromUniCode"
gedacht sind, doch leider bringt dies nichts.
Ich habe es mal anders probiert, und so wenigstens eine 1:1 Hin- und Rückwandlung geschafft.
Folgender Code bringt tatsächlich auf deutschen, wie auf chinesischen Rechnern das identische Ergebnis.
Ich weise dem Befehl zu, dass er nicht mit der System LOCID, sondern immer mit der deutschen LOCID
arbeiten soll.
Dim abtA1() As Byte
Dim abtA2() As Byte
Dim sT1 As String
Redim abtA1(3)
abtA1(0) = 46
abtA1(1) = 47
abtA1(2) = 48
abtA1(3) = 49
'//1. ANSI Byte-Array in String wandeln
sT1 = StrCov(abtA1, vbUnicode, 7&)
'//Test: LenB(sT1) => 8 => OK
'//2. Test Rücktransformation: String in ANSI Byte-Array
abtA2 = StrConv(sT1, vbFromUnicode, 7&)
'//Kontrolle: abtA1 == abtA2 => OK, klappt also Nun kommt die nächste Hürde. Die Umwandlung hat scheinbar geklappt, nun muss der
neue String in den Stream eingepflanzt werden.
D.h. ein vorhandener String wird um die Länge des Neuen "sT1" erweitert,
also in diesem Fall "8 Spaces" und dann wird per "MID$" der neue String eingepflanzt.
Auch hier klappt etwas im Unicode System noch nicht.
Mal sehen, wie man dies hier ändern muss.
Also vielen Dank "Blackbox".
Es ist schon seltsam, an was man alles denken muss, um auf einem Unicode System
funktionsfähig zu bleiben. Und dabei geht es noch nicht einmal um die Darstellung von
chinesischen Schriftzeichen.
Tschaui
Woellmi | |
Re: StrConv auf einem DBCS-System (z.B. China-Taiwan) | | | Autor: Blackbox | Datum: 06.02.18 09:21 |
| Hallo Woelmi,
*lange_Antwort_on*
denke daran, dass VB Funktionen extra für UniCode hat. Diese Funktionen enden mit einem W.
ChrW ... usw und auch MIDB(). Mit dem Object Browser kannst du diese spezielle Funktionen sehen. Und wenn gar nichts will, so tun eigene Typen Wunder. Es ist schier unglaublich, wie schräg VB UDT's intern umsetzt.
Am Anfang eines Projekts sollte man sich in VB entscheiden, ob die Anwendung vollen Unicode Support bietet oder nicht. Diese erweiterten Funktionen sollte man also, wenn man sich für Unicode entschieden hat, immer verwendet werden und nicht nur in ein paar Prozeduren.
*lange_Antwort_off*
Kurze Antwort: Nimm die MIDB()-Funktion ;)
Beitrag wurde zuletzt am 06.02.18 um 09:26:31 editiert. | |
Re: StrConv auf einem DBCS-System (z.B. China-Taiwan) | | | Autor: Woellmi | Datum: 06.02.18 17:32 |
| Hallo Blackbox,
danke für die Hinweise.
- mein Projekt sehr alt und sehr groß
- seit "2 Jahrzehnten!" war UNICODE für "dieses Projekt" uninteressant
(wie für alle anderen Projekte auch)
- jetzt plötzlich kommt die Anforderung (toll)
=> Ein schneller Umstieg ist praktisch unmöglich! (z.B. C# o.ä.)
- Ich möchte erreichen/rausbekommen, dass/ob die Anwendung in den wesentlichen
Funktionen brauchbar/änderbar ist.
=> Nun wird der Aufwand gescheckt, mal sehen was geht. [bisher recht viel ]
- Es werden nur 2 Sprachen primär unterstützt ENU+GER (die Controls sind ja in der GUI
auch nicht alle Unicode fähig) (Ich weis, es steht die Frage: Macht dass alles Sinn?)
- Es geht nun schon erstaunlich viel und mir liegen einige Funktionen sehr am Herzen.
Doch gerade hier ist viel Testen erforderlich
Die andere Frage ist, wie schnell komme ich mit z.B. C# zu einem Ergebnis,
was diesem Projekt funktionell nahe kommt. Da in der "normalen" Arbeitszeit
praktisch keine Zeit zum "Lernen" gewährt wird (!), müsste ich "wie damals mit VB2-6"
und aktuell mit C# wieder alles zu hause lernen. Da bin ich ja schon wieder dabei,
aber auch dies dauert. Produktiv sein sieht anders aus.
Nun genug gejammert.
Ich hatte doch geschrieben, dass ich mit:
sT1 = StrConv(abtA1(), vbUnicode, 7&) .. auf beiden Systemen zum identischen Ergebnis gekommen bin.
Leider gilt dies nur für meine wenigen Testdaten und die resultierende String-Länge (Len + LenB).
Beim Originalbild (10kByte) weichen auf dem Unicode System doch wieder ettliche Zeichen ab,
wieso auch immer.
Also nochmal von vorn. Bzw. Fkt. "Bild in PDF" wird abgeschaltet, der Rest funktioniert.
Jetzt werde ich erstmal weiter im Netz recherchieren. Evtl. finde ich ja doch noch
einen brauchbaren Ansatz.
Vielen Dank für die Antwort und sorry für meine langen Texte
Tschaui
Woellmi | |
Woellmi, du bist ein Globalisierungsopfer | | | Autor: Blackbox | Datum: 06.02.18 19:15 |
| es gibt überall welche. | |
| Sie sind nicht angemeldet! Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
Einloggen | Neu registrieren |
|
|
Neu! sevPopUp 2.0
Dynamische Kontextmenüs!
Erstellen Sie mit nur wenigen Zeilen Code Kontextmenüs dynamisch zur Laufzeit. Vordefinierte Styles (XP, Office, OfficeXP, Vista oder Windows 8) erleichtern die Anpassung an die eigenen Anwendung... Weitere InfosTipp des Monats TOP Entwickler-Paket
TOP-Preis!!
Mit der Developer CD erhalten Sie insgesamt 24 Entwickler- komponenten und Windows-DLLs. Die Einzelkomponenten haben einen Gesamtwert von 1605.50 EUR...
Jetzt nur 599,00 EURWeitere Infos
|