![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Ich hab die Dateierweiterung in .txt geändert...
Hallo Robert, gooly,
in der drittletzten Zeile seiner *Mail* von 17:37:
auftritt, um die Ankunft eines neuen Datenrahmens während der EA-Optimierung im Strategie-Tester
das ä von während besteht aus einem großen A mit Tilde und einem Symbol, das aussieht wie ein Kreis, der ein X überdeckt.
Gruß
Gerhard
Hallo gooly,
So schaut der Text im NotePad++ (UTF-8) aus:
Separate BookEvent-Zähler, sortiert nach Symbolen, stehen für alle Anwendungen zur Verfügung, die auf dem gleichen Chart laufen. Dies bedeutet, dass jedes Chart mehrere Abonnements für verschiedene Symbole haben kann, und für jedes Symbol wird ein Zähler bereitgestellt. Das An- und Abmelden von BookEvent ändert den Abonnementzähler für bestimmte Symbole nur innerhalb eines Charts. Mit anderen Worten, es können zwei benachbarte Charts zum BookEvent für das gleiche Symbol, aber unterschiedliche Abonnementzählerwerte vorhanden sein.
Im Notepad++ habe ich alle Dateien (UTF-8, da ich sonst jeder einzelne Datei nach ANSI im Notepad++ umkodieren muss) gespeichert.
Dann öffne ich LO und wähle alle diese Dateien aus und lade sie so in den Writer.
Das selbe Ergebnis erhalte ich wenn ich eine Datei im Verzeichnis über Öffnen mit -> LO Writer öffne. Der Text von oben schaut jetzt so aus:Separate BookEvent-Zähler, sortiert nach Symbolen, stehen für alle Anwendungen zur Verfügung, die auf dem gleichen Chart laufen. Dies bedeutet, dass jedes Chart mehrere Abonnements für verschiedene Symbole haben kann, und für jedes Symbol wird ein Zähler bereitgestellt. Das An- und Abmelden von BookEvent ändert den Abonnementzähler für bestimmte Symbole nur innerhalb eines Charts. Mit anderen Worten, es können zwei benachbarte Charts zum BookEvent für das gleiche Symbol, aber unterschiedliche Abonnementzählerwerte vorhanden sein.
Wie gesagt es sind Dateien mit der Endung .xml, aber ohne xml-Tags in UTF-8.
Ich verstehe immer noch nicht, warum Du die xml-Tags entfernst. Für die Rechtschreibprüfung ist das nicht notwendig. Wenn ich eine UTF-8 kodierte Datei mit französischem oder deutschen Umlauten im Writer öffne, sind die Umlaute exakt so vorhanden.
Ich will NUR die Rechtschreibung und den Text kontrollieren nicht die Grammatik von xml!
Frage: Wie stelle ich LO so ein, dass es alle Dateien als UTF-8 codiert erkennt und lädt.
Das ist die falsche Frage. Die Frage sollte lauten: Wie stelle ich die korrekt kodierte Datei zur Verfügung? Und das ist nicht das Problem von LO.
Die Datei wurde von Notepad++ gespeichert, also ein Standardprogramm!
Die Frage bleibt, wie kann ich LO überreden eine UTF-8 Datei korrekt zu laden - denn das tut es nicht!!
Hey gooly,
hmm, ist ne merkwürdige Sache... ich verstehe zwar den Sinn nicht, die XML/Html Datei umzuwandeln, aber sei es drum.
In Notepad++ geöffent - alles ok. Datei ist utf-8.
in Notepad++ wandel sie um in ANSI. -> speichern
Jetzt öffne Sie in LO. Umlaute sind korrekt.
Ja, das ist bei mir auch so! ABER ICH WILL NICHT jede einzelne Datei (diesmal 15) separat in ANSI konvertieren. Wozu habe ich einen Computer, wenn ich dann doch alles händisch machen muss??
Du gehst davon aus, dass die Datei regelkonform formatiert ist, d. h.
entsprechend den Normen mit einem sogenannten BOM (Byte-Order-Mark)
versehen ist. Eine regelkonforme UTF-8-Datei müsste immer mit der
Zeichenfolge "" (0xEF 0xBB 0xBF) beginnen. Tut deine Datei aber nicht.
Und das ist sicherlich nicht der Fehler des Programms, welches diese Datei
/lesen/ soll (hier Writer), sondern ein Fehler des Programms, welches diese
Datei /erstellt/ hat. Feli hat vollkommen Recht damit, überhaupt erst mal
nach einer regelkonformen Datei zu fragen.
Sollte dein Notepad++ (welches übrigens beileibe kein Standardprogramm
ist, wie du behauptest) eine ASCII-Datei (und um eine solche handelt
es sich, wenn kein BOM vorhanden ist) wirklich als UTF-8 interpretieren
(was ich gar nicht mal glaube; vielmer vermute ich, dass du die Haxen
im Text einfach übersehen hast), würde das bestenfalls beweisen,
dass es Schrot^Wnicht regelkonform arbeiten würde. Sorry.
Wolfgang
Hallo Gerhard,
ich habe jetzt nicht den ganzen Faden verfolgt, aber mal eine kleine
Erklärung zusammengebastelt:
das ä von während besteht aus einem großen A mit Tilde und einem
Symbol, das aussieht wie ein Kreis, der ein X überdeckt.
Dieses "A mit Tilde" weist darauf hin, dass an der Stelle tatsächlich
ein UTF-8 "Ä" als zwei ein-Byte-Zeichen missinterpretiert wird.
Zur Erklärung: Bei UTF-8 kommen zur Codierung von Zeichen mehrere Bytes
zum Einsatz. Gut erklärt im Wikipedia-Artikel, Abschnitt Kodierung.
https://de.wikipedia.org/wiki/UTF-8
Wenn man nun die "handelsüblichen" UTF-8 Umlaute verwendet, dann hat
man folgende Zuordnung von Umlaut zu zwei Bytes:
ä - C3 A4
ö - C3 B6
ü - C3 BC
Ä - C3 84
Ö - C3 96
Ü - C3 9C
ß - C3 9F
Wenn ein Programm nun die Eingabe als normale "1 Byte = 1
Zeichen"-Kodierung missinterpretiert, wird der Hexcode "C3" als
entsprechendes Zeichen, nämlich dem "Ã" interpretiert, dass von dem
jeweils anderen Zeichen gefolgt wird (z.B. bei ä das Zeichen "A4" also
dem "¤"). Siehe auch: http://ascii-table.com/ansi-codes.php
Bei einem Austausch von Texten ist es also wichtig, dass das
Zielprogramm die Codierung erkennt. Das geht einfach, sofern der
"Sender" den Text kennzeichnet, wie es in Mails üblich ist, oder bei
Textdateien in denen z.B. eine BOM vorangestellt ist
(https://de.wikipedia.org/wiki/Byte_Order_Mark).
Ansonsten kann es immer mal wieder vorkommen, dass ein UTF-8 Text als
ANSI Text missinterpretiert wird. Insbesondere, wenn dann auch noch
eine "Zwischenablage" ins Spiel kommt. Das ist ein Problem, dass sie
auch nie 100%ig wird verhindern lassen.
Bei großen Textdateien habe ich oft Erfolg, wenn ich sie mit einem
Editor lade, der sie "richtig" darstellt und sie dann als neue Datei
speichere, wobei ich die Codierung und ggf. das Voranstellen der BOM
auswähle. Das macht den Text besser als UTF-8 erkennbar.
Gruß,
Michael
Hallo Wolfgang,
Du gehst davon aus, dass die Datei regelkonform formatiert ist, d. h.
entsprechend den Normen mit einem sogenannten BOM (Byte-Order-Mark)
versehen ist.
Eine BOM ist nicht zwingend vorgeschrieben, aber dann muss der
Empfänger natürlich selber die korrekte Kodierung auswählen.
Ein Programm, dass kein UTF-8 beherrscht, macht auch keinen wirklichen
Fehler, bei der Interpretation der "unsichtbaren" BOM als "". Das
ist prinzipiell leider auch regelkonforme ANSI-Codierung.
Eine regelkonforme UTF-8-Datei müsste immer mit der
Zeichenfolge "" (0xEF 0xBB 0xBF) beginnen. Tut deine Datei aber
nicht.
Sagen wir so: Kaum ein UTF-8 fähiges Programm würde bei einer
enthaltenen BOM auf die Idee kommen, es solle tatsächlich ""
in einer ANSI-kodierten Datei heißen 
Gruß,
Michael
Will mal so sagen:
Wenn man den Weg von Alois wählt ist alles Banane.
Wie soll der Writer denn erkennen, dass es sich um UTF-8 handelt, wenn das nicht explizit angegeben ist. Ich denke mal der Writer interpretiert das erstmal als ANSI. Das mag unter Linux natürlich anders sein.
Hallo Michael,
ich habe mich am Faden eigentlich gar nicht beteiligt, sondern nur mitgelesen, weil ich mich mit der Thematik noch nie befassen musste. Da sind deine Erläuterungen ein guter Tipp.
Der eigentliche Grund für die Mail war aber, darauf hinzuweisen, dass bei gooly auch an anderer Stelle "falsch" interpretiert wird und er deshalb doch eher bei sich suchen müsste anstatt immer zu sagen, dass Writer etwas falsch macht.
Gruß
Gerhard
Hallo Gerhard,
Der eigentliche Grund für die Mail war aber, darauf hinzuweisen, dass bei gooly auch an anderer Stelle "falsch" interpretiert wird und er deshalb doch eher bei sich suchen müsste anstatt immer zu sagen, dass Writer etwas falsch macht.
Also nachdem der TO nun eine Beispieldatei zur Verfügung gestellt hat, konnte ich sein Problem nachstellen.
Allerdings ist es aus meiner Sicht kein Fehler im Writer, dem fehlen die Informationen um was für eine Kodierung es sind handelt, also muss man die Datei so wie es Alois Klotz erläutert hat öffnen.
Richtig ist: Writer macht nichts falsch, nur die Herangehensweise war suboptimal.
Hallo Gooly,
Vielen Dank, aber den Eintrag finde ich nicht?
Was steht denn drüber und drunter?
Ich sehe nur
Text - Textcodierung wählen (kann aber nix wählen)
Einfach "Öffnen" klicken. Der Dialog zur Auswahl der Codierung öffnet sich danach. Dann UTF-8 wählen und fertig.
Beste Grüße
Karl-Heinz
Hallo Wolfgang,
Du gehst davon aus, dass die Datei regelkonform formatiert ist, d. h.
entsprechend den Normen mit einem sogenannten BOM (Byte-Order-Mark)
versehen ist.Eine BOM ist nicht zwingend vorgeschrieben,
Wenn es eine regelkonforme UTF-8-kodierte Textdatei sein soll, doch.
Ein Programm, dass kein UTF-8 beherrscht, macht auch keinen wirklichen
Fehler, bei der Interpretation der "unsichtbaren" BOM als "".
Jein; wenn ein Editor o. ä. eine bestimmte Codierung nicht beherrscht,
dann bleibt ihm natürlich nur zwei Möglichkeiten, nämlich entweder den
Inhalt in einem anderen Format dar zu stellen, oder die Darstellung
kompett zu verweigern. Aber dieser Fall ist genau umgekehrt gelagert,
nämlich dass das betreffende Programm (hier der Writer) die Kodierung
durchaus verstehen würde, wäre sie vorhanden.
Das
ist prinzipiell leider auch regelkonforme ANSI-Codierung.
Nein; /wenn/ ein BOM vorhanden ist (und das Programm dieses versteht),
/hat/ es diese zu berücksichtigen (es sei denn, der Anwender
spezifiziert /explizit/ etwas anderes).
Eine regelkonforme UTF-8-Datei müsste immer mit der
Zeichenfolge "" (0xEF 0xBB 0xBF) beginnen. Tut deine Datei aber
nicht.Sagen wir so: Kaum ein UTF-8 fähiges Programm würde bei einer
enthaltenen BOM auf die Idee kommen, es solle tatsächlich ""
in einer ANSI-kodierten Datei heißen
Das war aber vom OP nicht gefragt; der OP erwartet, dass der Writer sich
regelwidrig verhält, und eine *nicht* als UTF-8 markierte Datei
*trotzdem* als UTF-8 interpretiert, und das sogar automatisch.
Übrigens müsste der Writer beim Anklicken der Datei eigentlich sogar den
OP nach der Kodierung /fragen/; zumindest tut er das bei mir (hab hier
allerdings momentan 'nur' AO, kein LO).
Wolfgang
Halo Wolfgang,
> Hallo Wolfgang,
>
>> Du gehst davon aus, dass die Datei regelkonform formatiert ist, d.
>> h. entsprechend den Normen mit einem sogenannten BOM
>> (Byte-Order-Mark) versehen ist.
>
> Eine BOM ist nicht zwingend vorgeschrieben,Wenn es eine regelkonforme UTF-8-kodierte Textdatei sein soll, doch.
Ich zitiere mal aus: https://de.wikipedia.org/wiki/Byte_Order_Mark
Die UTF-8-Kodierung des BOM besteht aus der Bytesequenz EF BB BF, die
in nicht UTF-8-fähigen Texteditoren und Browsern meist als
ISO-8859-1-Zeichen  erscheinen. Bei UTF-8 stellt sich das Problem
der Byte-Reihenfolge zwar nicht, doch ein BOM am String- oder
Dateianfang ist erlaubt, um die Verwendung von UTF-8 als Kodierung zu
kennzeichnen. Eine sichere Unterscheidung zwischen UTF-8 und den
ISO-8859-Zeichensätzen ist dadurch zwar nicht gewährleistet, da in den
8-Bit-Zeichensätzen alle Bytesequenzen erlaubt sind, auch die
UTF-8-Kodierung des BOM; wenn aber die Alternative speziell UTF-8 oder
ISO 8859-1 ist, ist die pragmatische Annahme, dass die Zeichenfolge
 nicht gemeint ist, durchaus üblich.
Also _erlaubt_ aber nicht zwingend. Bei UTF-16 oder UTF-32 sieht das
natürlich anders aus.
Bei UTF-8 _kann_ es sogar zu _Problemen_ kommen. Zitat:
Wird ein BOM verwendet, kann es jedoch auch zu Problemen mit
Programmen kommen, die kein Byte Order Mark erwarten oder kennen.
Wie meine Anmerkung besagte. Oder zu echten Fehlfunktionen:
So wird in Unix-artigen Umgebungen oft in Skriptdateien der
Shebang-Mechanismus verwendet, bei dem die Zeichenfolge "#!"
ebenfalls am Dateianfang stehen muss. Steht hier ein unerwartetes
BOM, gibt es Probleme.
Also gerade mit UTF-8, wo es theoretisch nicht benötigt würde kann ein
BOM durchaus auch Stress machen.
Insofern: Wenn beim Import einer Textdatei die Umlaute mit "Ã" und
einem weiteren Zeichen dargestellt werden, nochmals explizit als UTF-8
importieren.
Das ist mit den vielen verschiedenen ANSI-Codierungen ja auch nicht
anders.
Gruß,
Michael
Halo Wolfgang,
> Hallo Wolfgang,
>
>> Du gehst davon aus, dass die Datei regelkonform formatiert ist, d.
>> h. entsprechend den Normen mit einem sogenannten BOM
>> (Byte-Order-Mark) versehen ist.
>
> Eine BOM ist nicht zwingend vorgeschrieben,Wenn es eine regelkonforme UTF-8-kodierte Textdatei sein soll, doch.
Ich zitiere mal aus: https://de.wikipedia.org/wiki/Byte_Order_Mark
Wir reden hier vom Writer unter Windows (siehe OP), d. h. von reinen
*Text*dateien.
Also _erlaubt_ aber nicht zwingend.
Der User kann natürlich auch den BOM weg lassen, und statt dessen z. B.
eine Kristallkugel benutzen [1]; aber das ist dann eine proprietäre
Lösung und nicht übertragbar.
[1] btw, wenn du einen Hersteller kennst, dessen Kugeln wirklich
zuverlässig funktionieren, wäre ich durchaus an dessen Adresse
interessiert; meine spinnt in letzter Zeit ... 
Bei UTF-8 _kann_ es sogar zu _Problemen_ kommen. Zitat:
Wird ein BOM verwendet, kann es jedoch auch zu Problemen mit
Programmen kommen, die kein Byte Order Mark erwarten oder kennen.
Wir reden hier vom Writer unter Windows, also von reinen *Text*dateien;
und nicht von Skripten, Datendateien, Programmcode oder sonst was.
Wolfgang
...
Also gerade mit UTF-8, wo es theoretisch nicht benötigt würde kann ein
BOM durchaus auch Stress machen.Insofern: Wenn beim Import einer Textdatei die Umlaute mit "Ã" und
einem weiteren Zeichen dargestellt werden, nochmals explizit als UTF-8
importieren.Das ist mit den vielen verschiedenen ANSI-Codierungen ja auch nicht
anders.
Leider hat sich der TO ja darauf versteift, dass das Problem auf Seiten von LO liegt. Ich würde ihm aber dringend nahelegen, die Möglichkeiten von notepad++ auszunutzen. Hier gibt es nämlich durchaus die Möglichkeit, UTF-8 mit und ohne BOM zu speichern.
Die beste Variante für die Rechtschreibprüfung in einer XML-Datei ist allerdings ein guter XML-Editor wie z.B. XMLSpy (nur Windows) oder Oxygen XML Editor.
Viele Grüße
Feli
Hallo Wolfgang,
>> > Eine BOM ist nicht zwingend vorgeschrieben,
>>
>> Wenn es eine regelkonforme UTF-8-kodierte Textdatei sein soll,
>> doch.
>
> Ich zitiere mal aus: https://de.wikipedia.org/wiki/Byte_Order_MarkWir reden hier vom Writer unter Windows (siehe OP), d. h. von reinen
*Text*dateien.> Also _erlaubt_ aber nicht zwingend.
Der User kann natürlich auch den BOM weg lassen, und statt dessen z.
B. eine Kristallkugel benutzen [1]; aber das ist dann eine proprietäre
Lösung und nicht übertragbar.
Ich gebe dir ja recht: Es macht Sinn, eine UTF-8 Datei mit einem BOM
auszustatten.
Nur ist dies nicht _zwingend_ und du weißt ggf. nicht, wer eine
bestimmte Text-Datei mit welchen Mitteln erzeugt hat. Darum kann es
immer wieder passieren, dass ein Import (oder Öffnen) einer Textdatei
fehl schlägt. Nicht mehr und nicht weniger.
Wenn "gooly" also fordert, das Writer eine Datei erkennen soll, so geht
das prinzipiell an der Realität vorbei. Auch der "Produzent" der
UTF-8 Textdatei kann dafür nicht "haftbar" gemacht werden, wenn er kein
BOM schreibt. Das ist zwar fragwürdig, aber eben keine Regelverletzung.
Da dies so ist, wird es immer mal wieder einen "Sprung oder Trübung in
der Glaskugel" geben. Ebenso wie bei der Verwendung verschiedener
ANSI-Kodierungen, wo ebenso falsche Codierungen auftreten können.
Gruß,
Michael...
...der nur Aufzeigen wollte, dass eine automatische Erkennung
_beliebiger_ UTF-8 Texte aus _beliebigen_ Quellen nicht funktionieren
kann, so dass man Writer damit auch keinen "Fehler" unterstellen
sollte. Ähnliches kann mit jedem "Textprogramm" passieren.
Hallo Feli,
Leider hat sich der TO ja darauf versteift, dass das Problem auf
Seiten von LO liegt. Ich würde ihm aber dringend nahelegen, die
Möglichkeiten von notepad++ auszunutzen. Hier gibt es nämlich
durchaus die Möglichkeit, UTF-8 mit und ohne BOM zu speichern.
Exakt! Der Anspruch den "gooly" hier stellt, ist prinzipbedingt nicht
erfüllbar.
Es wird für ein Programm, das Texte ohne Metadaten (wie Codierung oder
Sprache) öffnen soll, immer einen "Interpretationsspielraum geben.
Statt solche Probleme mit immer mehr Pseudointelligenz von
Office-Paketen lösen zu wollen, muss man halt hin und wieder nach
Informationen suchen und das Problem mit dem dadurch Gelernten lösen.
Gruß,
Michael...
...der es prinzipiell für einen Irrglauben hält, dass man für
professionellen Umgang mit Daten _nur_ die _richtige_ Software braucht
und auf Fachwissen verzichten kann.