[Bug erledigt] Umlaute aus einer externen ANSI-Datei werden in MicroEd nicht angezeigt

  • [Bug erledigt] Umlaute aus einer externen ANSI-Datei werden in MicroEd nicht angezeigt

    Ich habe jetzt ein anderes Problem festgestellt, das aber wahrscheinlich mit den Problemen aus den Threads "HTML-Vorlagen inkompatibel, müssen anders geschrieben werden" und "Einfügen von UTF-8-Zeichen aus Zwischenablage in Textkörper erzeugt falsche Kodierung" zusammenhängt.

    Wenn man eine externe Text-Datei im ANSI-Format erstellt und darin Umlaute verwendet, diese Datei dann als Text-Vorlage in TB!-Kontoeigenschaften über %INCLUDE einfügt und als Zeichensatz "UTF-8" einstellt, sieht man im MicroEd nur leere Quadrate anstelle von Umlauten. Im Windows- und HTML-Editor werden Umlaute jedoch richtig angezeigt. Früher funktionierte das aber auch mit MicroEd (so z.B. noch in v7.4.4). Das Problem tritt seit v7.4.8 auf und ist daher auch in der aktuellen v8.0.18 vorhanden.

    Die Vorgehensweise ist folgende:

    1. Eine Text-Datei (z.B. C:\NEU.TXT) mit MS Notepad erstellen. Inhalt:

    Quellcode

    1. ä ö ü ß
    Beim Speichern als Codierung "ANSI" wählen. Alternativ kann man einen anderen Text-Editor nehmen. Wichtig ist nur, dass es eine ANSI-Datei wird.

    2. In TB! ein Konto wählen und dort in den Kontoeigenschaften unter "Vorlagen | Neue Nachricht" nur das einfügen:

    Quellcode

    1. %INCLUDE="C:\NEU.TXT"


    3. Darunter bei "Verwendeter Zeichensatz" -> "Unicode (UTF-8)" wählen. Falls er nicht zur Auswahl steht, muss man ihn vorher über "Optionen | Benutzereinstellungen | Weitere Einstellungen | Zeichensätze (XLAT)" aktivieren.

    4. Jetzt eine neue Nachricht starten.

    5. Über "Optionen | Nachrichtenformat" (oder in der Statusleiste) kann man zwischen verschiedenen Editoren hin und her schalten. Windows- und HTML-Editor zeigen die Umlaute, MicroEd aber nur vier leere Quadrate.

    Es gibt im BT bereits einen Eintrag dazu:

  • Hier geht's vor allem darum, dass es früher auch mit MicroEd funktioniert hat und jetzt weiterhin mit den Windows und HTML Editoren funktioniert. Man fragt sich natürlich, wieso plötzlich mit MicroEd nicht mehr? Eine Antwort von Ritlabs steht noch aus.

    Im Übrigens haben Benutzer mit vielen externen ANSI-Dateien, die sie jetzt in UTF-8 konvertieren müssten, dasselbe Problem wie du mit deinen TXT-Vorlagen, die du alle in HTML konvertieren müsstest (s. auch #0001377).
  • Trotz des Changelogs ist es nicht in v8.2.4.1 behoben.


    GwenDragon schrieb:

    Deswegen nehme ich für solche Dateien immer UTF-8 kodiert.
    Heutzutage schon. Wenn man aber noch viele Dateien aus der alten Zeit hat, als es noch kein Unicode gab oder Unicode nicht so verbreitet war bzw. unterstützt wurde, dann müsste man sie jetzt alle in UTF-8 konvertieren, was umständlich wäre. Wie gesagt, bis v7.4.8 ging's noch.
  • Ich verstehe es auch nicht, warum beim Einlesen in The Bat! kein Unicode Sniffing gemacht und bei Bedarf umkodiert wird, dann würden wir solche Probleme nicht haben.
    Vorlangen umstellen is ein Graus und da es frührr korrekt ging, eigentlich unnötig. Aber es musste ja ein neuer Editor in 8.x her :(
    The Bat! Pro 8.x BETA (32bit) | Win 10 Pro x64 | GnuPG 2.2.x | XMP + Regula


    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.
  • So wie ich es sehe, wird es keine weitere Änderung geben. In der o.g. v8.2.4.1 hat man den Parameter für %INCLUDE geändert. Das Makro sollte jetzt wie folgt verwendet werden:

    Quellcode

    1. %INCLUDE("Dateipfad",<Codepage>)
    2. z.B.
    3. %INCLUDE("C:\Neu.txt",1252)
    Codepages kann man z.B. von der Wiki-Seite nehmen. ISO-8859-1 bzw. Latin-1 wäre dann also 819. Der Zeichensatz muss dabei dem Zeichensatz der externen Datei mit der Vorlage entsprechen. Bei ANSI geht sowohl 819 als auch 1252.

    %INCLUDE="Dateipfad" (wie in der Online-Hilfe angegeben) kann man wohl immer noch verwenden, aber ohne den Codepage-Zusatz kann es zu dem o.g. Problem führen.
  • Sowas habe ich mir gedacht.
    Au weh! Das wird für manche, die nicht schon länger überall UTF-8 nutzen, unlustig die Templates zu ändern.

    Da ich seit ein paar Jahren nur noch UTF-8 in den Konten nutze und auch meine Dateien immer als UTF-8 schreibe, betrifft es mich zum Glück nicht.
    The Bat! Pro 8.x BETA (32bit) | Win 10 Pro x64 | GnuPG 2.2.x | XMP + Regula


    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.
  • GwenDragon schrieb:

    betrifft es mich zum Glück nicht.
    Jetzt spielt es keine primäre Rolle mehr, welchen Zeichensatz die externe Datei hat. Es geht nur noch darum, dass jeder, der %INCLUDE verwendet, die Vorlage anpassen müsste. Für UTF-8-Dateien müsste man also %INCLUDE("C:\NEU.TXT",65001) nehmen, denn laut BT liest TB! seit wann auch immer alle externen Dateien standardmäßig als ANSI.
  • sanyok schrieb:

    denn laut BT liest TB! seit wann auch immer alle externen Dateien standardmäßig als ANSI.
    WATT? Meine Dateien für %ICLUDE sind UTF8+BOM.
    Dann würde ja noch mehr kaputtich sein bei den Kodierungen, wenn es als ANSI einliest.
    Ich krieg ne Krise, wenn das wirklich so läuft.
    The Bat! Pro 8.x BETA (32bit) | Win 10 Pro x64 | GnuPG 2.2.x | XMP + Regula


    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.
  • Original-Zitat aus BT:

    aslius schrieb:

    Dears, by default TheBat reads included files as ANSI
    It also can detect UTF16, but not UTF8 :(
    Also wurden all deine UTF-8 Dateien nie als UTF-8 gelesen. Bei Umlauten spielt's vielleicht keine Rolle, aber wenn man Unicode-Zeichen verwendet, dann müsste es einen Zeichensalat geben. Jedenfalls hat aslius deswegen den neuen Codepage-Parameter eingeführt.
  • sanyok schrieb:

    aber wenn man Unicode-Zeichen verwendet, dann müsste es einen Zeichensalat geben.
    Ich habe jetzt ein paar Tests mit v8.2.4.2 gemacht. Wenn man eine externe UTF-8 Datei ohne BOM mit Unicode-Zeichen hat und das Makro %INCLUDE nach dem alten Prinzip ohne Codepage verwendet, dann sieht man Unicode-Zeichen nur in MicroEd. Sobald man on-the-fly auf Windows oder HTML Editor umschaltet, bekommt man den vermuteten Zeichensalat, auch bei den Umlauten. Abhilfe schafft nur der Codepage-Parameter. Dann sieht man sowohl Unicode-Zeichen als auch Umlaute auch in den Windows und HTML Editoren.

    UTF-8 mit BOM hingegen scheint in allen Editoren richtig dargestellt zu werden. Das widerspricht aber der Aussage von aslius.

    Da deine mit BOM sind, ist es dir wohl bisher nie aufgefallen.
  • Erkennt nur Windows-1252 und UTF-16 bei inkludierten Dateien? Was für ein beknacktes Verhalten bei The Bat!

    Codepage-Parameter? Darf doch nicht wahr sein.
    Wir haben 2018, da kann man schon verlangen, dass Unicode verwendbar ist ohne irgendwelche uralten MS-DOS-Codepage-Parameter.
    The Bat! Pro 8.x BETA (32bit) | Win 10 Pro x64 | GnuPG 2.2.x | XMP + Regula


    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.
  • GwenDragon schrieb:

    Wir haben 2018, da kann man schon verlangen, dass Unicode verwendbar ist ohne irgendwelche uralten MS-DOS-Codepage-Parameter.
    Nicht jeder verwendet Unicode. In vielen Ländern sind weiterhin ihre eigenen Zeichensatztabellen beliebt, in Russland z.B. "Windows-1251". Ich habe dabei festgestellt, dass selbst mit dem neuen Codepage-Parameter eine externe Windows-1251 Datei nicht richtig gelesen wird, selbst wenn man den Editor-Zeichensatz von UTF-8 auf "Kyrillisch (Windows)" ändert.