ASCII <-> Ansi Umwandlung

[shmia]

folgende Unit wandelt ASCII nach Ansi und umgekehrt:

Delphi-Quellcode:

unit AsciiAnsi;

interface

function Ascii2Ansi(const s:AnsiString):AnsiString;
function Ansi2Ascii(const s:AnsiString):AnsiString;


implementation

uses Windows;

function Ascii2Ansi(const s:AnsiString):AnsiString;
begin
   Result := s;
   if Result <> '' then
   begin
      UniqueString(Result);
      OemToChar(Pchar(Result), Pchar(Result));
   end;
end;

function Ansi2Ascii(const s:AnsiString):AnsiString;
begin
   Result := s;
   if Result <> '' then
   begin
      UniqueString(Result);
      CharToOem(Pchar(Result), Pchar(Result));
   end;
end;

end.

[Olli]

Ich bin dagegen das unreflektiert in die Codelib einzutragen, weil hier die Begriffe ANSI und ASCII falsch und mißverständlich benutzt werden. Abgesehen davon ist der OEM-Zeichensatz auf einem russischen System eben nicht identisch mit EASCII in westlicher Kodierung. Die Beschreibung als Konvertierung von ASCII nach ANSI und umgekehrt leitet also in die Irre ...

Zitat:

OemToChar: The OemToChar function translates a string from the OEM-defined character set into either an ANSI or a wide-character string.

Tja, was ist nun "OEM-defined"? Jedenfalls ist das Ergebnis nicht auf jedem System uniform!

[fkerber]

Hi!

Auch nach regem Bemühen ist es Matze und mir leider nicht gelungen, wirklich den Code nachvollziehen zu können. Natürlich wollen wir den Code deswegen nicht "wegwerfen" - nur weil wir ihn nicht verstehen :stupid:

Aus diesem Grund wäre es prima, wenn jemand näher erläutern könnte, was genau gemacht wird.
Vor allem folgende Fragen haben sich mir gestellt:

• Warum ist in beiden Fällen der Ein- und Ausgabetyp "ansistring"
• Was genau kann man mit dem Code machen? Für welche Fälle wäre er produktiv nutzbar?

Es wäre wirklich prima, wenn jemand das aufklären könnte!
Vielen Dank!
Ciao, Frederic

[Olli]

Zitat:

Zitat von fkerber

Auch nach regem Bemühen ist es Matze und mir leider nicht gelungen, wirklich den Code nachvollziehen zu können. Natürlich wollen wir den Code deswegen nicht "wegwerfen" - nur weil wir ihn nicht verstehen :stupid:

Aus diesem Grund wäre es prima, wenn jemand näher erläutern könnte, was genau gemacht wird.
Vor allem folgende Fragen haben sich mir gestellt:

• Warum ist in beiden Fällen der Ein- und Ausgabetyp "ansistring"
• Was genau kann man mit dem Code machen? Für welche Fälle wäre er produktiv nutzbar?

Tja, das ist genau eine Frage, die sich jeder stellen sollte. Warum ist Ein- und Ausgabe AnsiString. Weil AnsiString eigentlich ProZeichen1ByteString heißen sollte und der WideString ProZeichen2ByteString. Die Namensgebung in Delphi hat keinerlei, aber wirklich keinerlei Auswirkung auf diese Dinge. Bekanntlich kann man bequem einen UTF-8-kodierten String in einer AnsiString-Variablen ablegen, weil es da eben keinen Zusammenhang zwischen dem Namen (AnsiString) und der Funktion (abspeicher von Strings aus Zeichen mit 1 Byte pro Zeichen) gibt. Man nimmt fälschlicherweise anhand des Namens an, daß der String immer ANSI-Zeichen beherbergen muß, dabei ist ANSI ja nur eine Kodierung, die wie viele andere Kodierungen bestimmte Zeichen in einen 8bit-Zeichensatz quetscht.

Die Funktionen OemToChar und CharToOem machen nichts weiter, als bestimmte Zeichenwerte (ord) in ANSI-Kodierung auf die OEM-Kodierung abzubilden. So daß der Buchstabe Ü beispielsweise immer als Ü angezeigt wird, auch wenn dies auf der Konsole geschieht, welche meist die OEM-Kodierung benutzt, während der Quelltext eines Delphiprogramms üblicherweise in ANSI-Kodierung abgespeichert wird.

[himitsu]

Zitat:

Zitat von Olli

Weil AnsiString eigentlich ProZeichen1ByteString heißen sollte und der WideString ProZeichen2ByteString.

ich dachte Delphi interpretiert den AnsiString als MultiByteString?[delphi]

[xaromz]

Hallo,

Zitat:

Zitat von himitsu

ich dachte Delphi interpretiert den AnsiString als MultiByteString?

nö, AnsiString ist die 1 Byte-Version (nativ von Delphi), WideString die 2 Byte-Version (OLE-Strings) von Strings. "String" ist standardmäßig ein AnsiString.

Gruß
xaromz

[himitsu]

Und warum sind dann die meisten Ansi-Funktionen in Delphi für MultByteStrings ausgelegt?

[Ydobon]

In der Hilfe sieht es so aus:

Zitat:

AnsiString ~2^31 Zeichen 4 Byte bis 2 GB 8-Bit-Zeichen (ANSI), DBCS ANSI, MBCS ANSI usw.
WideString ~2^30 Zeichen 4 Byte bis 2 GB Unicode-Zeichen, Mehrbenutzer-Server und mehrsprachige Anwendungen

Logischerweise verwendet Delphi unter Sprachversionen von Windows, die nur mit Multibytezeichen funktionieren auch solche für Ansi-Strings. 1 bis 4 Byte pro Zeichen, nicht als kleinste Zugriffsmöglichkeit 1 Byte.

[xaromz]

Hallo,

Zitat:

Zitat von himitsu

Und warum sind dann die meisten Ansi-Funktionen in Delphi für MultByteStrings ausgelegt?

Weil Borland sich bisher beharrlich weigert, seine VCL auf Unicode zu portieren. Damit trotzdem Schriften darstellbar sind, die mehr als 256 Zeichen beinhalten, wird die Krücke MultiByteString benutzt. Das ist aber (genauso wir z. B. UTF-8) nur eine Codierung, die der Einfachheit halber in einen AnsiString gepackt wird. Wie Olli schon schrieb, Name und Inhalt müssen nicht immer übereinstimmen.

Gruß
xaromz

[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.

[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