Ini Read geht teilweise nicht

  • Ich habe ein kleines problem mit der IniRead funktion. Bestimmte Teile aus der Ini werden gelesen andere aber nicht


    alles was auf den Key Pfade zugreift funktioniert nicht.

    ich habe auch Testweise eine msgbox mit IniRead versucht, die Ausgabe bleibt aber Leer.

    Ich seh wahrscheinlich den Wald vor lauter Bäumen nicht.

    Kann mir wer helfen?

  • Probier mal statt

    Code
    $config = "\\192.168.9.170\Export\office\buero\XXXXX\vordrucke\programme\Config\Meeting.ini"

    das hier:

    Code
    $config = "\\\\192.168.9.170\\Export\\office\\buero\\XXXXX\\vordrucke\\programme\\Config\\Meeting.ini"

    Einmal editiert, zuletzt von DasIch (7. Januar 2020 um 11:01)

  • Wo hast du denn mir MsgBox getestet, ob die Keys ausgelesen werden? In der Funktion start()? Ich sehe nicht, dass du sie überhaupt aufrufst.

    Ansonsten sahen für mich die IniRead Befehele Inhalte richtig aus. Wenn das nicht funktioniert, würde ich am ehesten erwarten, dass die Datei gerade überhaupt nicht erreichbar war. Prüf das dann mal.

    Edit: Oh, der Vorschlag von DasIch sieht aber schon interessant aus :S

    Grüße autoiter

  • Bei der IP müssten es glaube ich vier slashes sein. Glaube aber nicht, dass es daran liegen wird. Der Einwand von AutoIter klingt am logischsten, wenn der Code den du uns gepostet hast komplett ist, dann fehlt einfach der Aufruf der Funktion.

  • Prüfe mal, ob die INI-Datei in der Kodierung UTF-8 gespeichert ist.

    Dann würde der erste Eintrag, bei Dir die Sektion [Pfade], komplett ignoriert !


    EDIT :

    Datei test-utf8.txt nach .ini umbenennen (.ini kann man im Forum nicht hochladen :rolleyes:)

    Gruß Musashi

  • ich hab den Code der MSG Box mit eingefügt und ein Bild angehängt.

    die Ini Datei wird ja gelsen.

    bis auf [Pfade] wird alles korrekt ausgegeben.

    Edit:

    Habe gerade nachgeschaut ja ist als UTF 8 gespeichert

    Einmal editiert, zuletzt von Echree (7. Januar 2020 um 11:25)

  • Habe gerade nachgeschaut ja ist als UTF 8 gespeichert

    Dann solltest Du sie mal als ANSI speichern.

    Bei UTF-8 wird der Datei EF BB BF (Dezimal : 239 187 191) vorangestellt. Das führt dazu, dass IniRead die erste Zeile 'überliest'. Ist die erste Zeile ein Kommentar, ist das egal.

    Bei Dir ist es aber die Sektion [Pfade] , die dann, wie bereits gesagt, komplett ignoriert wird.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Dann solltest Du sie mal als ANSI speichern.

    Bei UTF-8 wird der Datei EF BB BF (Dezimal : 239 187 191) vorangestellt. Das führt dazu, dass IniRead die erste Zeile 'überliest'. Ist die erste Zeile ein Kommentar, ist das egal.

    Bei Dir ist es aber die Sektion [Pfade] , die dann, wie bereits gesagt, komplett ignoriert wird.

    Gruß Musashi

    Das ist ja heftig, wusste ich auch noch nicht. Dachte man hat mit den Kodierungen "einfach" nur ne andere Kodierung für verschiedene Sprachen. Weshalb IniRead das jetzt überliest, verstehe ich aber immer noch nicht. ;(

    Was auch noch interessant wäre: Wie verhält sich IniWrite() im UTF-8 Modus. Wird dort direkt die erste Zeile beschrieben, wäre das ja theoretisch ein Fehler.

    Passiert das eigentlich nur bei der Funktion IniRead*() ? Wenn ich jetzt FileReadLine() o.Ä verwenden würde, hätte man dann das gleiche Szenario mit dem EF BB BF?

    Ich wollte das jetzt nicht ausprobieren, weil ich von der Sache bisher eh keine Ahnung habe. :/

  • Ich hab sie nun als ANSI gespeichert. Funktionoiert.

    Musste in die Ini aber trotzdem noch für andere Leute die die Ini editieren Kommentare einfügen.

    Habe am am Anfang jetzt noch [Info] eingefügt. Damit geh ich auch dem Problem aus dem Weg wenn einer die Datei mal ausversehen Falsch speichern sollte.

    PDFs werden nun wie gewünscht am richtigen Ort erstellt und gespeichert.

  • IniRead geht davon aus, dass die Datei als ANSI gespeichert wurde und kennt zudem auch keinen BOM, weshalb dieser als Inhalt der Datei mit eingelesen wird.

    Aus Sicht von IniRead steht der BOM () dann nicht in einer eigenen Zeile, da dieser ja ohne Zeilenendekennung (CRLF) vorangestellt wird.

    [Pfade]CRLF

    Dadurch kann die Sektion "[Pfade]" nicht mehr erkannt werden, weil als erstes Zeichen in der Zeile die öffnende Klammer nicht gefunden wird.

    Fügt man hinter dem BOM bzw. vor "[Pfade]" eine Zeilenendekennung ein, dann funktioniert es auch mit "UTF-8 mit BOM".

    CRLF

    [Pfade]CRLF

    FileReadLine macht hier keine Probleme, denn es erwartet kein ANSI und kann einen BOM erkennen.

  • Auf jeden Fall extrem interessant.

    Dann findest du dieses Verhalten sicher auch interessant:

    Wird Zeit das ich in Zukunft standardmäßig irgendein _IniRead verwende

    Besser du überprüfst IniFiles einmalig beim Start deines Scripts mit einer speziellen Funktion.

    Z.B. so:

  • IniRead geht davon aus, dass die Datei als ANSI gespeichert wurde und kennt zudem auch keinen BOM, weshalb dieser als Inhalt der Datei mit eingelesen wird.

    Stimmt !

    AutoIt verwendet für die Verarbeitung von .ini-Dateien Funktionen aus der Microsoft KERNEL32.DLL. IniRead ist meines Wissens 'nur' ein Wrapper für die Funktion 'GetPrivateProfileString' (ggf. noch mit A am Ende). GetPrivateProfileString(A) geht aber immer von einer ANSI (nicht verwechseln mit ASCII) Kodierung aus.

    Fügt man hinter dem BOM bzw. vor "[Pfade]" eine Zeilenendekennung ein, dann funktioniert es auch mit "UTF-8 mit BOM".

    CRLF
    [Pfade]CRLF

    Sofern man Einfluss auf den Aufbau der .ini hat, wäre auch eine simple Kommentarzeile zu Beginn ausreichend. Wichtig ist halt nur, dass Zeile 1 keine relevanten Elemente enthält.

    (Dass die Lehrmeinung bzgl. ".ini-Dateien und Kommentare" nicht eindeutig ist, weiß ich ;))

    Bitnugger : Könntest Du bitte mal einen Blick in meinen Beitrag Sammelthread "AutoIt Interne Funktionen : Erwartetes Ergebnis -> Tatsächliches Ergebnis" werfen - falls Du es nicht bereits getan hast. Ist das einigermaßen verständlich ? Die Sache mit GetPrivateProfileString(A) wollte ich dort nicht unbedingt breittreten, oder meinst Du, dass würde Sinn machen.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Könntest Du bitte mal einen Blick in meinen Beitrag Sammelthread "AutoIt Interne Funktionen : Erwartetes Ergebnis -> Tatsächliches Ergebnis" werfen - falls Du es nicht bereits getan hast. Ist das einigermaßen verständlich ?

    Das ist sehr gut verständlich, nur mit "ignoriert/übergangen" bist du mindestens einen Millimeter von der Wahrheit entfernt - denn die erste Sektion wird schlicht und einfach nicht erkannt, weil der BOM mit in dieser Zeile steht und somit das erste Zeichen keine öffnende Klammer "[" ist. ;)

    GetPrivateProfileString(A) zu erwähnen ist gut, dadurch bekommt man zumindest einen Einblick, warum es mit BOM zu Problemen kommt.


    Zitat von Musashi
     Wer dieses Verhalten der Standard IniRead* Funktionen aber nicht kennt wird sich ggf. wundern, warum Einträge nicht eingelesen werden ;).

    Nicht "Einträge", sondern nur "der erste Eintrag"...