ASCII <-> Ansi Umwandlung

[himitsu]

Auf Unicode stelle ich schon selber um.
(die VCL mit nonVCL zu mischen ist irgendwie witzig)

Ich meinte das aber in Bezug auf "Weil AnsiString eigentlich ProZeichen1ByteString heißen sollte" von Olli#4 ... es ist eben nicht immer ein Byte pro Zeichen :warn:

[Ydobon]

Zitat:

Zitat von DGL-luke

Gibt es diese funktionen nicht schon längst in der codelib? ich hab das doch schon mal gesehen hier... Da war auch als CharToOEM und andersrum tituliert.

CharToOEM und OEMToChar sind API-Funktionen, die Ansi nach OEM wandeln. OEM steckt im Computer, Ansi kommt mit der Software.
Hat aber nix mit Ansi nach Ascii Wandlung zu tun, Ascii sind halt nur die 95 druckbaren Zeichen mit einen Bytewert unterhalb 127. Andere Zeichen lassen sich damit zwangsläufig nicht nach Ascii wandeln.

Ansi hat sich einfach eingebürgert als Bezeichnung für sonstige Codepages, ob nun Singlebyte oder Multibyte.

Zitat:

ANSI: Acronym for the American National Standards Institute. The term “ANSI” as used to signify Windows code pages is a historical reference, but is nowadays a misnomer that continues to persist in the Windows community. The source of this comes from the fact that the Windows code page 1252 was originally based on an ANSI draft—which became International Organization for Standardization (ISO) Standard 8859-1. “ANSI applications” are usually a reference to non-Unicode or code page–based applications.

http://www.microsoft.com/globaldev/r.../glossary.mspx

Als Krücke kann man Multibytestrings sicher auch nicht bezeichnen, da diese in Form von UTF-8 eher die Zukunft sind und z.B. China kein Programm mehr ins Land lässt, das nicht mit GB 18030 umgehen kann.

[xaromz]

Hallo,

Zitat:

Zitat von Ydobon

Als Krücke kann man Multibytestrings sicher auch nicht bezeichnen, da diese in Form von UTF-8 eher die Zukunft sind und z.B. China kein Programm mehr ins Land lässt, das nicht mit GB 18030 umgehen kann.

Momentan sieht es aber so aus, als würden sich WideStrings (2 Byte pro Zeichen) eher durchsetzen als Multibyte-Codierungen. Ist praktischer und der Speicherplatz ist ja inzwischen auch da. Aber dass China immer einen eigenen Standard braucht, ist ja bekannt.

Aber um 'mal wieder zum Thema zurückzukommen: Ich würde auch gerne wissen, wozu man den Code eigentlich verwendet.

Gruß
xaromz

PS: Multibyte ist übrigens keine Form von UTF-8, sondern andersrum :wink: .

[Olli]

Zitat:

Zitat von himitsu

Ich meinte das aber in Bezug auf "Weil AnsiString eigentlich ProZeichen1ByteString heißen sollte" von Olli#4 ... es ist eben nicht immer ein Byte pro Zeichen :warn:

... was aber wieder eine Frage der Kodierung ist. Dann sollte man es vielleicht für die Pedanten als "ProElement1ByteString" bezeichnen :mrgreen:

Zitat:

Zitat von xaromz

Momentan sieht es aber so aus, als würden sich WideStrings (2 Byte pro Zeichen) eher durchsetzen als Multibyte-Codierungen.

Allein deshalb weil Windows NT nativ "WideStrings" spricht ;)
Vor XP konnte Windows ja eigentlich nur UCS2, nichtmal UTF-16 (also mit Surrogates). Es "macht" sich einfach leichter, wenn man die allermeisten Zeichen eindeutig darstellen kann, weil bei 2-Byte quasi gegeben ist.

Zitat:

Zitat von xaromz

PS: Multibyte ist übrigens keine Form von UTF-8, sondern andersrum :wink: .

Das stimmt wohl.

[Ydobon]

Zitat:

Zitat von xaromz

PS: Multibyte ist übrigens keine Form von UTF-8, sondern andersrum :wink: .

Habe ich etwas anderes gesagt? Ich sprach von Multibytestrings in Form von UTF-8 und nicht als Form...

UTF-8 hat aber gegenüber UTF-16 den Vorteil des geringeren Speicherbedarfs, bei reinem Ascii braucht UTF-16 immerhin den doppelten Platz und das für viele Nullen. Wenn das Betriebssystem die Verwaltung übernimmt, doch ein sympathischer Gedanke.

Wenn ich mal die Ansi<->OEM Konvertierung brauche und die Wahl habe eine extra Unit einzubinden oder gleich den API-Aufruf zu verwenden, würde ich sicher die API-Funktion nehmen.

PS: ProElement1ByteString? Was ist ein Element?

[Olli]

Zitat:

Zitat von Ydobon

UTF-8 hat aber gegenüber UTF-16 den Vorteil des geringeren Speicherbedarfs, bei reinem Ascii braucht UTF-16 immerhin den doppelten Platz und das für viele Nullen. Wenn das Betriebssystem die Verwaltung übernimmt, doch ein sympathischer Gedanke.

Weswegen sollte das besser sein? 1.) diese Sicht ist ziemlich einegeengt, weil es schon bei unseren Nachbarn in Polen, Tschechien und anderen Ländern aufhört. 2.) laß uns über Rußland, Ukraine und noch weiter östlich erst garnicht reden ...

Was hier getan wird ist einfach, daß man Speicherplatz gegen CPU-Zeit eintauscht. Und wenn du mich fragst, war das schon zu Zeiten von NT4 (was ja auch nativ UCS2 sprach) kein schlechter Tausch.

Zitat:

Zitat von Ydobon

PS: ProElement1ByteString? Was ist ein Element?

Die kleinste Einheit, die man in diesem String über Infix-Syntax ansprechen kann. Ergo ein Byte bei AnsiString und ein Word bei WideString.

[xaromz]

Hallo,

Zitat:

Zitat von Ydobon

Zitat:

Zitat von xaromz

PS: Multibyte ist übrigens keine Form von UTF-8, sondern andersrum :wink: .

Habe ich etwas anderes gesagt? Ich sprach von Multibytestrings in Form von UTF-8 und nicht als Form...

Da hatte ich doch glatt das "in" übersehen.

@Olli: Der geringere Speicherplatz von UTF-8 ist bei der Datenübertragung/-sicherung durchaus ein Vorteil. Wenn die Daten aber im Rechner bleiben, dann ist der Tausch Speicherplatz gegen CPU-Zeit natürlich vorzuziehen.

Gruß
xaromz