Stringkonvertierung

[DeddyH]

Delphi-Quellcode:

const
  Test = 'Achtung Farb„nderung';
var
  s: string;
begin
  SetLength(s, Length(Test));
  OEMToCharBuff(PAnsiChar(Test), PChar(s), Length(Test));
  ShowMessage(s);
end;

Sah gut aus.

[HPB]

Zitat von DeddyH:

Delphi-Quellcode:

const
  Test = 'Achtung Farb„nderung';
var
  s: string;
begin
  SetLength(s, Length(Test));
  OEMToCharBuff(PAnsiChar(Test), PChar(s), Length(Test));
  ShowMessage(s);
end;

Sah gut aus.

Habe ich gerade ausprobiert. Die Umlaute sind nicht vorhanden.

[DeddyH]

Komisch, bei mir schon.

[edit] @Blup: Lies mal die Bemerkungen zu OEMToChar/CharToOEM, Dein Code wird unter Delphi > 2007 knallen. Außerdem rät Microsoft selbst von der Verwendung ab.[/edit]
[edit2] Sry, ich hab übersehen, dass Du alles als AnsiStrings deklariert hast. Damit bleibt nur noch Punkt 2. [/edit2]

[Jumpy]

Vllt. was zur Codierung, könnte helfen:

Zitat:

Die DATANORM-Schnittstelle ist auf eine minimale Hardware-Konfiguration zugeschnitten und erlaubt somit den weitreichenden Einsatz. Alle Datensätze bestehen aus reinem ASCII-Text, wobei jeder Satz exakt 128 Zeichen lang und durch eine Zeichenschaltung (Carriage return/0DH 0AH) abgeschlossen ist.

Der erlaubte Zeichenvorrat lehnt sich an den IBM-Zeichensatz an, wobei jedoch nur die unteren 128 Zeichen erlaubt sind. Lediglich die deutschen Sonderzeichen bilden hier eine Ausnahme und tragen weiterhin die Positionscodes des erweiterten ASCII-Zeichensatzes.

Quelle:
http://www.textarchiv.alojado.de/tex...en-ap1387.html

[p80286]

Nun wenn Du die Daten nicht mehr zurück liefern mußt, dann laß doch gleich alles durch eine Übersetzungstabelle laufen:

Delphi-Quellcode:

for i:=1 to length(mystring) do
  mystring[i]:=asciitab[mystring[i]];

Die kannst Du anpassen wie Du es gerne hättest.
(diesen OEmtoAnsi's traue ich nur so weit wie ich sie selbst geschrieben habe)

Gruß
K-H

[Blup]

Dann stimmt vermutlich die im Windows eingestellte OEM-Code-Page nicht.
Stell mal in den Ländereinstellungen auf Englisch(USA) und speichern.
Danach wieder auf Deutschland(Deutsch), speichern und Windows neu starten.

Zitat:

[edit] @Blup: Lies mal die Bemerkungen zu OEMToChar/CharToOEM, Dein Code wird unter Delphi > 2007 knallen. Außerdem rät Microsoft selbst von der Verwendung ab.[/edit]

Zitat:

Security Considerations

Using this function incorrectly can compromise the security of your application.

Ich hab nicht vor diese Funktion inkorrekt zu benutzen. Deshalb auch schön in eigene Funktionen gekapselt die mit AnsiString und PAnsiChar arbeiten.
Das sollte auch nach Delphi 2007 keine Probleme verursachen.

In neueren Delphi-Versionen könnte man auch das mal versuchen, kann ich aber grad nicht testen:

Delphi-Quellcode:

function ConvertCodePage(const S: _RawByteStr; AFromCodePage, AToCodepage: Word): _RawByteStr;
begin
  Result := S;
  SetCodePage(Result, AFromCodePage, False); // Codepage der Ausgangsdaten nur festlegen
  SetCodePage(Result, AToCodepage, True);    // Codepage umstellen und Daten konvertieren
end;

sl.Text := ConvertCodePage(sl.Text, 437, 850);

[DeddyH]

Ich hatte ja noch einmal editiert. Trotzdem: wenn der Hersteller schon schreibt

Zitat:

Warning Do not use.

dann nehme ich das ernst.

[DeddyH]

Zitat von Blup:

Zitat:

Security Considerations

Using this function incorrectly can compromise the security of your application.

Ich hab nicht vor diese Funktion inkorrekt zu benutzen.

Nach genauerer Betrachtung tust Du das aber. Die Deklaration als AnsiString/PAnsiChar bewirkt ja nicht, dass da nun CharToOEMA/OEMToCharA aufgerufen wird, das muss man schon explizit tun. Deshalb gilt

Zitat:

If the OemToChar function is being used as an ANSI function, the string can be translated in place by setting the lpszDst parameter to the same address as the lpszSrc parameter. This cannot be done if OemToChar is being used as a wide-character function.

auch weiterhin, zumindest ab Delphi 2009.

[Blup]

Zitat von DeddyH:

Nach genauerer Betrachtung tust Du das aber. Die Deklaration als AnsiString/PAnsiChar bewirkt ja nicht, dass da nun CharToOEMA/OEMToCharA aufgerufen wird, das muss man schon explizit tun. Deshalb gilt

Zitat:

If the OemToChar function is being used as an ANSI function, the string can be translated in place by setting the lpszDst parameter to the same address as the lpszSrc parameter. This cannot be done if OemToChar is being used as a wide-character function.

auch weiterhin, zumindest ab Delphi 2009.

Wenn ich das richtig verstehe ruft die Funktion OemToChar
bis Delphi 2007 -> OemToCharA
ab Delphi 2009 -> OemToCharW auf.
Ok, dann häng ich da gleich noch ein A dran...

[himitsu]

Eigentlich sollte OemToCharA ja OemCP_to_AnsiCP heißen, womit dann auch klarer wird, warum da keiner an Unicode gedacht hat.
Außerden ist OEM nunmal eine ANSI-CodePage und hat damit auch garnichts in einem UnicodeString zu suchen.
Also wenn, dann sollte man es doch besser richtig machen, also via MultiByteToWideChar von CP_OEMCP nach Unicode.

Und warum MS von dessen Verwendung abrät, liegt daran, daß viele es verwenden, um InSpace die einzelnen "SingleByte"-Zeichen der OEM-CP in die Ansi-CP umzuwandeln.
Da aber je nach Ansi-CP das eben auch mal eine MultyByte-CodePage sein kann und fast kein Schwein das beachtet, gibt es da ein Problem mit der Puffergröße und es endet zu oft in einem Buffer-Overflow.
z.B. Deutsch und Englisch sind ja SingleByte ... drum merken es viele Programmierer garnicht, daß sie totalen Mist verzapft haben.
So sind also auch alle hier gezeigten Lösungsvorschläge nicht unbedingt "sicher" oder zumindestens funktionieren nicht immer richtig (siehe #12).

Darum ist das Dateisystem nun eben auch immer englisch und wird lokalisiert, genausio wie das Systemlaufwerk auch fast immer nur noch C: ist, da zuviele Idioten mit hardgecodeten Pfaden arbeiten.