ANSI-Unicode das alte Lied mal wieder

[Codehunter]

Hallo!

Folgendes Problem: MEINE Hauptanwendung und Datenbank sind durchgehend in Unicode realisiert, Sonderzeichen und Fremdsprachen funktionieren in MEINER Anwendung wunderbar. Jetzt habe ich ein "tolles" Warenwirtschaftssystem, das ich über Importdateien mit Belegen füttere. Dieses WaWi ist NICHT von mir und nicht vollständig Unicode-fähig. Die Dateischnittstelle möchte gerne ANSI-Codierung vorfinden.

Jetzt kann sich jeder denken was passiert: Ich gebe eine "Hauptstraße" hinein und bekomme eine "Hauptstra?e" heraus. Was kann ich sinnvollerweise tun, damit wenigstens solche Zeichen übernommen werden die im erweiterten ASCII-Zeichensatz enthalten sind? Auf Kyrillisch und Mandarin kann ich da gut verzeichen, aber ein "ß" sollte schon machbar sein. Gibt es vorgefertigte "Transcode"-Funktionen für sowas?

Grüße
Cody

[Mavarik]

Bisschen Code?

Weil ß geht immer.

[Sir Rufo]

Erstelle die Datei mit dem entsprechenden Encoding und schreibe einfach die Daten hinein.

Z.B. mit http://docwiki.embarcadero.com/Libra...s.SaveToStream da kann man die Codierung mit angeben
oder direkt in eine Datei mit http://docwiki.embarcadero.com/Libra...ngs.SaveToFile

[Codehunter]

@Sir Rufo: Genau das dachte ich auch immer. Aber so einfach ist der Spaß anscheinend nicht:

Delphi-Quellcode:

var
  F, FTmp, FTarget, FOk, FErr, FErrDesc: TFileName;
  Q, Q2: TUniQuery;
  SL: TStringList;
  sSql, FileContent: string;
  Writer: TStreamWriter;
begin
    sSql:= 'SELECT * FROM sync_jobs WHERE file_written=0;';
    if QuerySQL(sSql, Q) > 0 then begin
      while not Q.Eof do begin
        F:= Q.FieldByName('filename').AsString;
        FTarget:= IncludeTrailingPathDelimiter(FFolderBase) + F;
        FileContent:= Q.FieldByName('filecontent').AsString;
        FTmp:= TPath.GetTempPath + TPath.GetGUIDFileName;
        Writer:= TStreamWriter.Create(FTmp, FALSE, TEncoding.ASCII);
        try
          Writer.Write(FileContent);
        finally
          FreeAndNil(Writer);
        end;
        if TFile.Exists(FTarget) then TFile.Delete(FTarget);
        if TFile.Exists(FTmp) and not TFile.Exists(FTarget) then begin
          TFile.Move(FTmp, FTarget);
          if TFile.Exists(FTarget) then begin
            sSql:= Format('UPDATE sync_jobs SET file_written=1 WHERE filename=''%s'' LIMIT 1;', [F]);
            ExecuteSQL(sSql, Q2);
          end;
        end;
        Q.Next;
      end;
    end;

EDIT: Hat sich erledigt. War wohl ne Denkblockade ^^ Lösung:

Delphi-Quellcode:

Writer:= TStreamWriter.Create(FTmp, FALSE, TEncoding.ANSI);

[Fritzew]

Sollte das nicht

Delphi-Quellcode:

Writer:= TStreamWriter.Create(FTmp, FALSE, TEncoding.ANSI);

sein? Was erwartet das WAWI System einfach ANSI oder eine Spezielle Ansi Codepage?

[Codehunter]

Zitat:

Zitat von Fritzew (Beitrag 1341886)

sein? Was erwartet das WAWI System einfach ANSI oder eine Spezielle Ansi Codepage?

Genau das habe ich den Support dort auch gefragt. "ANSI" war die einzige Antwort auf die Frage. Die erwartete Codepage kann man per Konfiguration zwischen "DOS" und "WIN" wählen. Wobei nirgends genau definiert ist was damit gemeint ist (z.B. win1252 oder cp867). Da wird wohl Try&Error helfen :-(

[p80286]

DOS=CP437 WIN=win1252
für den deutschen Sprachraum wird es wahrscheinlich so sein.
Du solltest etwas nachsichtiger sein, für viele Menschen hört auch die Welt hinter Ihrem Horizont auf.

Gruß
K-H

[Codehunter]

Zitat:

Zitat von p80286 (Beitrag 1341899)

DOS=CP437 WIN=win1252
für den deutschen Sprachraum wird es wahrscheinlich so sein.
Du solltest etwas nachsichtiger sein, für viele Menschen hört auch die Welt hinter Ihrem Horizont auf.

Gruß
K-H

Seltsamerweise 1251. Warum auch immer. Zumindest bekomme ich jetzt den deutschen Zeichensatz vernünftig rüber. Damit komme ich schon mal ein ganzes Stück weiter. Aber was zu tun ist wenn von extern echte Unicode-Adressdaten rein kommen (z.B. kyrillische Kunden-Selbstregistrierung im Shop) das weiß ich auch noch nicht. Übersetzungspraktikant samt Luftmatratze in den Serverraum? Mal schauen... ^^

Mit Nachsichtig sein hat das nur begrenzt was zu tun. Ich habe halt zwei Systeme die unbedingt zusammen spielen sollen, aber die Voraussetzungen einfach nicht gegeben sind. Da wird der Auftraggeber Abstriche in Kauf nehmen müssen.

[p80286]

Zitat:

Zitat von Codehunter (Beitrag 1341914)

Seltsamerweise 1251. Warum auch immer. Zumindest bekomme ich jetzt den deutschen Zeichensatz vernünftig rüber.

Irgendwas stimmt da aber nicht. 1251 ist der kyrillische Zeichensatz, der kann kein ßüöä...
Wenn irgendwann in Deiner Kette eine Bildschirm oder Druckausgabe trotzdem ß ö ü ä ausgibt, dann stimmt da irgendwas im ganzen Zusammenspiel nicht. Könnte es sein, das 1250 gemeint war/ist?

Gruß
K-H

[Codehunter]

[QUOTE=p80286;1341939]

Zitat:

Zitat von Codehunter (Beitrag 1341914)

Irgendwas stimmt da aber nicht. 1251 ist der kyrillische Zeichensatz, der kann kein ßüöä...
Wenn irgendwann in Deiner Kette eine Bildschirm oder Druckausgabe trotzdem ß ö ü ä ausgibt, dann stimmt da irgendwas im ganzen Zusammenspiel nicht. Könnte es sein, das 1250 gemeint war/ist?
K-H

Stimmt da hast du recht. Das sieht seltsam aus wenn ich so eine Exportdatei dann im Editor öffne. Aber der Import am Wawi liest das ein und am Ende gibts äöüß. Ich hinterfrage da manche Dinge am Wawi nicht mehr, die Schnittstelle (so man das überhaupt so nennen kann) hat noch andere Bugs die man nur zufällig findet und der Support einem dann undokumentierte Workarounds erklärt.