Probleme mit Sonderzeichen bei Culture auf Englisch

  • VB.NET

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von sonne75.

    Probleme mit Sonderzeichen bei Culture auf Englisch

    Hallo,

    ich benutze die INI-DLL aus dem Forum hier und habe Probleme beim Einlesen der Sonderzeichen, allerdings nur wenn Culture auf Englisch steht, sonst nicht. Bei Deutsch funktioniert alles tadellos.
    Ich habe 3 Sonderzeichen in einer TXT-Datei (zwei Mal "±" und einmal "°"), die von dieser INI-DLL in Sections und Keys unterteilt ist. Die Sonderzeichen befinden sich in Values. Wenn ich den String in Chars zerlege und abfange, ob das Char grösser als 255 ist (c>"ÿ"), dann springt er auch an (nur bei Englisch), ich kann da ein richtiges einsetzen (ein extra Char-Array, den ich später wieder in String konvertiere), dann funktioniert es.

    Das Problem ist aber, dass ich nicht erkennen kann, welches Zeichen jetzt an der Reihe sein soll, das "±" oder das "°", da es für das System das gleiche unbekannte Zeichen zu sein scheint (es wird eine schwarze Raute mit weißem Fragezeichen drin dargestellt).

    Und vor allem, warum funktioniert es bei Deutsch problemlos? Bis zu Comboboxen kommt das Programm ja noch gar nicht, der Fehler passiert schon beim Einlesen von der Festplatte.

    Mit Encoding einzulesen ist keine Lösung, weil ich gerne weiter diese INI-DLL nutzen will und nicht alles zu Fuß schreiben will.

    EDIT: habe jetzt das unbekannte Zeichen in INT64 konvertiert, jedes Mal war es der gleiche Wert: 65533, für beide Zeichen.

    EDIT2: Hat vielleicht jemand die Sourcen noch von der INI2-DLL? Ich konnte leider nur die DLL bekommen... Der Thread dazu ist hier

    LG

    EDIT3: Habe jetzt eine Möglichkeit gefunden, wie ich mit einer anderen Codierung die Txt-Datei einlese, aber es funktioniert trotzdem nicht, bzw. nur auf Deutsch:

    VB.NET-Quellcode

    1. Dim objReader As New StreamReader(path, System.Text.Encoding.Default)
    2. str = objReader.ReadToEnd()
    3. idc.LoadIni(str)
    4. objReader.Close()


    Früher nur

    VB.NET-Quellcode

    1. idc.LoadFile(path)

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „sonne75“ ()

    MAch mal ein kleines Projekt, in dem Du ausschließlich diesen Effekt untersuchst:
    String-Zuweisung
    String abspeichern mit CultureInfo (statt INI)
    Dein Test, ohne INI.
    Und dann poste die paar Zeilen.

    sonne75 schrieb:

    ob das Char grösser als 255 ist (c>"ÿ")
    Wozu soll das gut sein?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ich verstehe nicht ganz, was du meinst. Wo soll ich den String abspeichern, mit welcher Methode?

    Wozu ich es abfrage? Ich will nicht, dass er mir die Raute mit Fragezeichen in die Combobox schreibt, an dieser Stelle kann ich wenigstens ein anderes Zeichen (hardcodiert) zuweisen.

    sonne75 schrieb:

    Ich verstehe nicht ganz, was du meinst.
    Du sollst ein Minimalprojekt (also ohne INI) machen, das Deinen Effekt reproduziert.
    Da können wir es nachvollziehen, ohne einen Rattenschwanz nachziehen zu müssen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Das Problem ist, dass es wohl an der INI-DLL liegt. Denn wenn ich einfach die gleiche Datei als String einlese und dann durchsuche, dann findet er wunderbar "±", egal in welcher Sprache (habe Button in 2 Sprachen genannt, um wirklich sicher zu gehen, dass er auf Englisch schaltet).
    Und nu? Es muss doch irgendwie eine Möglichkeit geben, diese Ini weiter zu benutzen, es wäre jetzt sehr viel Aufwand alles selbst zu schreiben, ich nutze es sehr viel :(

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „sonne75“ ()

    sonne75 schrieb:

    Es muss doch irgendwie eine Möglichkeit geben, diese Ini weiter zu benutzen
    Dann gib dem INI-Projekt eine entsprechende CultureInfo und nutze sie bei allen entsprechenden Befehlen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    RodFromGermany schrieb:

    sonne75 schrieb:

    Es muss doch irgendwie eine Möglichkeit geben, diese Ini weiter zu benutzen
    Dann gib dem INI-Projekt eine entsprechende CultureInfo und nutze sie bei allen entsprechenden Befehlen.



    Wie denn? Wenn ich nur eine DLL davon habe? Die Source kann man in diesem Thread nicht mehr runterladen, sonst hätte ich ja debuggen können.

    EDIT: Wenn ich wüsste, an welcher Stelle in der INI-DLL der Fehler passiert, könnte ich eine Klasse ableiten und diese Methode (GetValue) neu schreiben. Woran könnte es denn da liegen? Denn erst String in richtiger Kodierung einlesen und dann diesen String an INI übergeben funktioniert ja auch nicht (siehe Code im ersten Beitrag).

    Und vor allem, was nutzt mir diese CultureInfo, wenn ohne diese DLL alles funktioniert, unabhängig von Culture. Ich lese String ein (mit StreamReader und Default-Kodierung) und durchsuche dann mit For Each jedes Zeichen.

    sonne75 schrieb:

    Wie denn? Wenn ich nur eine DLL davon habe?
    Open Source INI-Parser 2.1Du weißt, was Open Source bedeutet?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ich dachte, ich hätte deutlich im ersten Beitrag schon geschrieben, dass man nicht mehr an die Sourcen drankommt. Der Download-Link funktioniert schon lange nicht, Anfang April hat jemand wenigstens seine DLL reingestellt, die er auf dem PC noch hatte.

    Aber ich sehe schon, ich muss mir die INI-Klasse in abgespeckter Version neu schreiben (ohne Klassen Key und Section, einfach paar Methoden, ob Key und Section existieren und Value vom Key holen).

    sonne75 schrieb:

    dass man nicht mehr an die Sourcen drankommt.
    Dann solltest Du dazu einen Thread aufmachen, ich denke doch, dass diese Quellen noch iwo rumgeistern.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ich habe in dem Thread schon nachgefragt. In welcher Kategorie soll der Thread denn eröffnet werden? Und vor allem ist er nach 1-2 Tagen schon so weit hinten, dass derjenige, der noch Sourcen hat, ihn bestimmt übersieht. Aber einen Versuch wäre es wert.

    Ich habe jetzt angefangen meine Klasse dazu zu schreiben, ich kann die ganzen Überprüfungen, ob Key und Section existieren, ja trotzdem von der INI-DLL vornehmen lassen...
    Ich habe es jetzt selbst programmiert, hätte ich gewusst, dass es nur 5 Minuten dauert selbst eine Ini-Datei nach Section und Key durchzuparsen, hätte ich keine 2 Stunden zur Fehlersuche investiert :)

    Ich denke, ich werde auch die Suche nach Key und Section selbst machen, dann brauche ich seine DLL überhaupt nicht...

    sonne75 schrieb:

    dann brauche ich seine DLL überhaupt nicht...
    Dann solltest Du auch gleich auf DataTable und XML umsteigen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ne, das ist mir dann doch zu viel. Ich komme ja aus C und LabView Welt und gerade in LabView nutzt man sehr viel Config-Dateien mit Sections und Keys, das Prinzip gefällt mir. Mir geht es nur darum die Comboboxen beim Programmstart mit Einträgen zu füttern, viel mehr passiert da nicht (plus andere Informationen, die zu diesen Comboboxen gehören).