MS Word Ole Automation, ADO und fremde Zeichen

Question

Ich versuche, an das MS Word-Dokument (Delphi 7), aber fremde Zeichen nicht korrekt übertragen (dh " e " statt Wide Texte aus der Datenbank (ADO / MS Access) zu exportieren von " c "):

while not ADOQuery1.Eof do
begin
  WordApplication1.Selection.TypeText(ADOQuery1Text.AsVariant); // TWideStringField
  WordApplication1.Selection.TypeParagraph;
  ADOQuery1.Next;
end;

Ich habe auch versucht CreateOleObject() direkt zu verwenden, aber kein Unterschied.

Was bin ich fehlt?

Danke!

Answer 1

Ich denke, es ist nicht ein Problem mit Word, sondern mit der Art, wie die Zeichenfolge in der Datenbank gespeichert sind. Sie werden wahrscheinlich als Ansi Strings gespeichert, nicht als Unicode / Wide Strings. Und wenn das wahr ist, dann werden sie in irgendeiner Codierung gespeichert, die Sie wissen müssen, wenn Sie wollen, richtig decodiert werden.

Hier ist eine Beispielanwendung zeigt, wie Ansi-String in Wide konvertieren und es in Word speichern:

program Project1;
{$APPTYPE CONSOLE}
uses
  SysUtils,
  ComObj,
  ActiveX,
  CodecUtilsWin32;

procedure Test();
var
  wordApp, wordDoc: Variant;
  ansiStr: string;
  codec: TUnicodeCodec;

  function str2WideStr(const s: string): WideString;
  var
    i: Integer;
  begin
    codec.DecodeStr(@s[1], Length(s), Result);
  end;

begin
  codec := TEncodingRepository.CreateCodecByAlias('ISO-8859-2');

  ansiStr := #$BF#$F3#$B3#$E6; //"zólc"

  wordApp := CreateOleObject('Word.Application'); 
  wordDoc := wordApp.Documents.Add;
  wordApp.Selection.TypeText(str2WideStr(ansiStr));
  wordDoc.SaveAs('C:\sample.doc');
  wordDoc.Close();
  wordApp.Quit(False);
end;

begin
  CoInitialize(nil);
  Test();
end.

Der obige Code verwendet Freeware-Einheit CodecUtilsWin32.pas von Utility Library v.2.0.18

Deshalb schlage ich würde mit TStringField statt TWideStringField und die Saiten wie Wide im obigen Beispiel zu konvertieren.

Answer 2

Haben Sie versucht mit

WordApplication1.Selection.TypeText(ADOQuery1Text.AsWideString); 

Kurz kommt, dass ich weiß, dass Delphi 2009 ein besseres Handling von Unicode hat (gesamte VCL unterstützt jetzt direkt), die höchstwahrscheinlich Ihr Problem beheben würde.