[gelöst]StrToDate klemmt

[wp_xyz]

Ich habe jetzt mal einen Bugreport mit Patch geschrieben, so dass der BOM automatisch erkannt und übergangen wird.

Das wiki werde ich mir demnächst vornehmen und so umschreiben, dass klar wird, dass die offizielle Version nun in fpc enthalten ist.

[Nixsager]

Da lag ich ja mal richtig.

Aber ich dachte, ScanDateTime sucht in einem String nach einer Zeitangabe.
Oder liege ich da falsch?

[wp_xyz]

Das ist schon richtig, aber da die Datei einen BOM enthielt, waren die beiden Bytes, die als Tagesziffern interpretiert werden sollten, keine Ziffern sondern die ersten beiden des BOM (#$EF#$BB), was weder von StrToDate noch von ScanDateTime akzeptiert wird.

[Nixsager]

Dann liegt das nicht nur an der BOM-Markierung.
Denn wenn nur ein Zeichen vor der Datumsangabe steht schmiert es ab, und mit 'hh:mm' scheint es auch nicht zu funktionieren.

[wp_xyz]

Versteh ich nicht, natürlich darf vor dem Datum kein weiteres Zeichen im String stehen, die Anweisung ScanDateTime('dd.mm.yyyy', str) nimmt die ersten beiden Zeichen und interpretiert sie als Ziffern der Tagesnummer.

Poste ein Beispiel zu dem 'hh:mm' Problem. Dir ist schon bewusst, dass das Symbol für die Minuten das 'n' nicht, nur gelegentlich, wenn der Zusammenhang klar ist, kann man auch das 'm' nehmen.

[Nixsager]

Aber ich dachte, ScanDateTime sucht in einem String nach einer Zeitangabe.

Ich dachte mir schon das du mich nicht verstehst.
Ich dachte, 'ScanDateTime' sucht in einem String wie 'Heute ist der 21.12.2004 und wir habe 12:43 Uhr.' und gibt das Datum und die Uhrzeit zurück.
Aber wenn ScanDateTime so nicht gedacht ist, ist das mit dem BOM nicht unbedingt ein Fehler.

[wp_xyz]

Das geht natürlich auch, du musst nur die Suchmaske für ScanDateTime so gestalten, dass der Text überlesen wird: alles, was nicht zum Datum und zur Uhrzeit gehört, einfach in doppelte Anführungszeichen setzen.

Code: Alles auswählen

const
  s = 'Heute ist der 21.12.2004 und wir haben 12:43 Uhr';
var
  dt: TDateTime;
begin
  dt := ScanDateTime('"Heute ist der "dd.mm.yyyy" und wir haben "hh:nn" Uhr', s);
  WriteLn(DateTimeToStr(dt));                                                    

[Marsmännchen]

Wenn ich eure Diskussion richtig verstehe: ScanDateTime ist also nicht sowas wie eine RegEx, die ein bestimmtes Muster an einer beliebigen Stelle in einer Zeichenkette sucht.

Ich hab jetzt noch ein anderes Problem: Das Einlesen aus der CSV klappt jetzt wunderbar. Die Zeilen werden in Records gepackt, die ich in einem Array verwalte. Wenn ich aber aus diesem Array heraus einen String benutze, um die Caption eines TStaticText zu ändern, dann werden alle deutschen Umlaute durch ein '?' ersetzt. Nach meiner Recherche hier im Forum sollte das eigentlich daran liegen, dass die LCL Unicode erwartet. Aber mein Quellcode ist UTF-8, die CSV-Datei ist UTF-8 und auch der Versuch, den String mit SysToUTF8 zu übergeben ändert nix. Das habe ich alles versucht und das waren auch die Tipps aus entsprechenden Posts hier im Forum zu älteren Beiträgen mit genau dem gleichen Problem.

Habt ihr eine Idee, woran das liegen kann?

[wp_xyz]

Die LCL verwendet UTF-8, nicht Unicode (falls du darunter Delphi's UTF-16 verstehst - wobei UTF-8 genaugenommen auch eine Unicode-Codierung ist). Falls deine Eingangsdatei, so wie die weiter oben gepostete, wirklich UTF8 ist, musst du keine Konvertierungen mehr machen. SysToUTF8 hat hier nichts verloren. Wie hast du denn die Strings in den Records deklariert? Bitte nur "string", nix "unicodestring", "widestring" o.ö.

[Marsmännchen]

Hi,

sorry, Unicode ist Quatsch, ich meinte UTF-8 und so hatte ich das auch in der Dokumentation gelesen.

Mein Record verwendet puren String:

Code: Alles auswählen

 TLeseTag = record
    Datum    : TDate;
    Lesetext : String;
    Verse    : Integer;
    Gelesen  : Boolean;
  end;    

Der String wird von einem TCSVParser gefüllt und der sollte kein Encoding vornehmen laut Dokumentation dazu:

Both UTF-8 encoding and Windows-xxx codepages can be used with the CsvDocument library. The library uses string type for all string operations and will not do any encoding conversion for you.

Die Deklaration der CurrentCell-Property des Parsers sagt auch klar aus, dass die einen String (keine Widestring usw.) zurückgibt.

Heute is zu spät, aber ich glaube, ich muss mir morgen mal ne Testroutine schreiben . Mal sehen, ob ich den Punkt finde, wo die Umlaute zu Fragezeichen werden...

[Marsmännchen]

... ich konnte doch nicht die Finger von lassen und habe getestet, wie die Strings in den Records ankommen. Es geht um folgenden Code:

Code: Alles auswählen

FileStream := TFileStream.Create(DateiName, fmOpenRead);
 
    Parser.Delimiter:=',';
    Parser.SetSource(FileStream);
    for i := Low(FLeseplan) to High(FLeseplan) do
      begin
        With FLeseplan[i] do
          begin
            Parser.ParseNextCell;
 
            Datum:= ScanDateTime('dd.mm.yyyy',Parser.CurrentCellText);
            Parser.ParseNextCell;
            Lesetext:= Parser.CurrentCellText;
            testform1.Memo1.Text := testform1.Memo1.Text + Parser.CurrentCellText + #13;
            Parser.ParseNextCell;
            Verse:= StrToInt(Parser.CurrentCellText);
            Parser.ParseNextCell;
            if Parser.CurrentCellText = 'True' then
              Gelesen := True
            else
              Gelesen := False;
 
          end;
 
      end;
      testform1.Show;

Ich habe den String aus Parser.CurrentCellText unmittelbar weitergeleitet an ein Memo und dort ausgegeben. Siehe da: Da sind schon die Umlaute durch Fragezeichen ersetzt!

Laut Notepad++ ist die Codierung der csv-Datei UTF-8. Kann man das noch mit anderen Mitteln überprüfen?

EDIT: Ich hatte spaßeshalber mal die Kodierung meines Sourcecodes auf Ansi gestellt (falls die csv-Datei aus unerfindlichen Gründen Ansi ist, dann hätten sich die beiden ja verstehen sollen, meinte ich). Hat aber auch nix genützt...

[wp_xyz]

Wie hast du eigentlich den BOM weggemacht? Vielleicht ist da etwas "ver"konvertiert worden?

Den BOM kannst du übrigens auch direkt in deiner Lese-Routine überspringen, indem du nach Parser.SetSource den Stream weitersetzt:

Code: Alles auswählen

  ...
  Parser.SetSource(FileStream);
  FileStream.Position := BOMSize(FileStream);
  ...

Die Routine BOMSize() prüft, ob zu Beginn des Stream ein BOM vorhanden ist und gibt seine Größe zurück:

Code: Alles auswählen

function BOMSize(AStream: TStream): Integer;
var
  b: array[0..2] of byte;
begin
  FSourceStream.Position := 0;
  if (b[0] = $EF) and (b[1] = $BB) and (b[2] = $BF) then 
    Result := 3
  else
  if (b[0] = $FE) and (b[1] = $FF) then 
    Result := 2
  else
  if (b[0] = $FF) and (b[1] = $FE) then 
    Result := 2
  else
    Result := 0;
end; 

Ich hoffe, die Codierung deiner Quellen ist wieder sauber zurückgesetzt. Lade die Quell-Dateien in Notepad++ und prüfe, ob sie UTF-8 sind (ohne BOM).

[Marsmännchen]

ICH BIN SOOOO DOOOOOOOOF

Ich meiner ganzen Rumpfuscherei habe ich nie in meiner zu UTF8 konvertierten csv-Datei überprüft, ob da überhaupt die Umlaute noch drin sind. Sind sie nicht. Sie müssen schon früher, als ich die Texte aus dem Writer bzw. Calc-Dokument rauskopiert und dann in die CSV-Datei reinkopiert habe, im Orkus gelandet sein.

Und ich geh euch hier die ganze Zeit mit meinem Gejammer auf die Nerven... und ihr gebt euch so eine Mühe, mir zu helfen

Aua Aua Aua Aua...

Es tut mir echt leid. War ein klassischer Fall von Brett vor dem Kopf. Ich werde jetzt nochmal versuchen, die Texte einschließlich Umlaute in die CSV-Datei rüberzuschieben. Vermutlich wird es dann gehen (was mich dann gar nicht mehr richtig freuen wird )

Danke nochmal für euren Einsatz

[wp_xyz]

Kein Problem. Nur aus Fehlern lernt man. Und für FPC ist der Fehler mit dem BOM gefunden worden.

[Marsmännchen]

Habe die Ursprungsdatei jetzt nochmal konvertiert. Jetzt sind alle Umlaute da. Keine Ahnung, was beim ersten Mal schief gegangen ist