|
| |
VB.NET - Ein- und Umsteiger| Re: RTrim beim Auslesen von Char-Variablen | |  | | Autor: Preisser | | Datum: 07.06.13 15:24 |
| Hallo,
Manfred X schrieb:
Ja, es sind verschiedene Funktionen.
Was ich damit sagen wollte, ist, dass Chr() und Asc() (nehme ich an) aus der alten Basic-Zeit stammen, also es noch kein Unicode gab. Dort bestand ein Zeichen dann wohl aus einem Byte, und die Funktionen gaben einfach den Wert zurück.
Jedoch verwendet ja .Net (und auch VB6 teilweise) Unicode für Zeichen, d.h. ein Zeichen ist ein 16-Bit-Wert. In C# kann man einfach von einem Zeichen den Wert herausbekommen, indem man ein char in ein Int konvertiert:
char c = '沧';
int wert = c;
Console.WriteLine(wert); // ergibt 27815 In VB.Net hingegen funktioniert dies nicht, und VisualStudio zeigt an, dass man dafür AscW() verwenden kann.
Dim c As Char = "沧"c
Dim wert As Integer = AscW(c)
Console.WriteLine(wert) ' ergibt 27815 Asc() hingegen benutzt Encoding.Default um das Zeichen in ein (oder mehrere, bei Multibyteencodings) Byte zu konvertieren. Wenn man in obigem Beispiel Asc() verwenden würde, würde es 63 ("?") zurückgeben, da das chinesische Schriftzeichen nicht in Windows-1252 vorkommt.
D.h. Asc() verwendet den lokalen Windows-Zeichensatz wie Windows-1252, um ein Zeichen in ein Byte zu konvertieren. Allerdings ist es ziemlich ineffizient, viele Zeichen auf diese Weise in Bytes zu konvertieren - dafür gibt es ja die Encoding-Klasse, der man einen String übergeben kann und die dann ein Byte-Array zurückgibt, was effizienter ist. Weiterhin kann man ja bei Chr() keinen Zeichensatz angeben, sondern es wird automatisch der lokale Windows-Zeichensatz verwendet - allerdings ist es in vielen Fällen so, dass man eher UTF-8 verwendet z.b. um eine Textdatei o.ä. zu speichern.
Daher machen Asc() und Chr() in .Net eigentlich keinen Sinn. Ich persönlich sehe auch das Problem, dass Umsteiger aus VB6 (die auch damals schon Chr() usw. statt ChrW() verwendeten, da sie nichts von Unicode wussten) weiterhin annehmen dass ein String aus Bytes und nicht aus 16-Bit-Unicode-Werten besteht, wenn sie Code sehen, der Chr() oder Asc() verwendet.
Daher würde ich empfehlen, in solche Fällen explizit das entsprechende Encoding (Encoding.Default) zu verwenden und mit deren Methoden Zeichen in Bytes zu konvertieren, damit einem bewusst wird, dass hier ja eine tatsächliche Konvertierung von Stringzeichen in Bytes stattfindet - was bei AscW() ja nicht der Fall ist, da hier einfach nur der Unicodewert des Zeichens zurückgegeben wird.
Wenn man jedoch nur den Wert eines Chars auslesen will, würde ich auf jeden Fall ChrW() bzw. AscW() verwenden.
Beitrag wurde zuletzt am 07.06.13 um 15:31:49 editiert. | |
 | 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 |
 |
|
sevISDN 1.0 
Überwachung aller eingehender Anrufe!
Die DLL erkennt alle über die CAPI-Schnittstelle eingehenden Anrufe und teilt Ihnen sogar mit, aus welchem Ortsbereich der Anruf stammt. Weitere Highlights: Online-Rufident, Erkennung der Anrufbehandlung u.v.m. Weitere InfosTipp des Monats Neu! sevEingabe 3.0 
Einfach stark!
Ein einziges Eingabe-Control für alle benötigten Eingabetypen und -formate, inkl. Kalender-, Taschenrechner und Floskelfunktion, mehrspaltige ComboBox mit DB-Anbindung, ImageComboBox u.v.m. Weitere Infos
|
| |
|
Copyright ©2000-2025 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.
Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel
|
|
November 2025
Sie sind aktuell nicht angemeldet.
