[gelöst] Textkodierung Umlaute in UTF-8

[Kutscher58]

Ich bearbeite gerade eine Film-Untertiteldatei mit Gnome-Subtitles. Das klappt normalerweise immer ganz prima. Aber ab und an gibt es immer mal wieder Probleme mit den Umlauten. Manchmal kann man das mit 'Suchen&Ersetzen' lösen. Manchmal aber sieht es so aus wie hier:

Wenn Sie auf mich geh�rt h�tten,
s��en wir jetzt im Stau fest,

Hier steht für ä/ö/ü und ß jeweils das gleiche Zeichen und lässt sich mit 'Suchen&Ersetzen' also nicht lösen. Mit 'file' habe ich die Originalkodierung in UTF8 analysiert.

Ich habe auch schon probiert, den Text in ein Textbearbeitungsprogramm zu laden und in diversen gängigen westlichen Kodierungen abzuspeichern. Dann stehen da zwar andere Zeichen, aber es sind ebenso immer die gleichen.

hat noch jemand eine Idee, was ich noch probieren könnte?


Gruß vom
Kutscher


...

 

[RME]

Hallo,

Hier steht für ä/ö/ü und ß jeweils das gleiche Zeichen...

Meinst Du damit dass:

-1- auf dem Bildschirm das gleiche Zeichen dargestellt wird, oder

-2- dass die Kodierung dieser Zeichen die gleiche ist? (wenn Du die Datei mit einem hex-Editor anschaust[z.B. okteta], oder mit 'less' in der Konsole).

Wenn nur -1- zutrifft kannst Du die Kodierung der Datei nach Wunsch verändern (z.B. mit 'recode').

Wenn jedoch -2- zutrifft (gleiche Kodierung) kannst Du nichts mehr machen. In diesem Fall ist das Problem in einem früheren Schritt entstanden (als die Kodierung noch verschieden war).

Noch eine diesbezügliche Bemerkung: Je nachdem was Du für einen Text-Editor gebrauchst, und insbesondere, wie dieser Editor konfiguriert ist, machst Du die Kodierung möglicherweise beim abspeichern der editierten Datei kaputt. Dies ist z.B. bei KWrite der Fall wenn auf ISO 8859-15 gesetzt, aber die Datei utf-8 (oder umgekehrt) kodiert ist.

Gruss,
Roland

 

[Kutscher58]

Hallo,

Meinst Du damit dass:

-1- auf dem Bildschirm das gleiche Zeichen dargestellt wird, oder

-2- dass die Kodierung dieser Zeichen die gleiche ist? (wenn Du die Datei mit einem hex-Editor anschaust[z.B. okteta], oder mit 'less' in der Konsole).

Wenn nur -1- zutrifft kannst Du die Kodierung der Datei nach Wunsch verändern (z.B. mit 'recode').

Wenn jedoch -2- zutrifft (gleiche Kodierung) kannst Du nichts mehr machen. In diesem Fall ist das Problem in einem früheren Schritt entstanden (als die Kodierung noch verschieden war).

Noch eine diesbezügliche Bemerkung: Je nachdem was Du für einen Text-Editor gebrauchst, und insbesondere, wie dieser Editor konfiguriert ist, machst Du die Kodierung möglicherweise beim abspeichern der editierten Datei kaputt. Dies ist z.B. bei KWrite der Fall wenn auf ISO 8859-15 gesetzt, aber die Datei utf-8 (oder umgekehrt) kodiert ist.

Gruss,
Roland

Hallo Roland,

danke für Deine Antwort. Ich habe mir die Datei mit Okteta angesehen, aber das ist für mein Niveau einfach zu hoch. Da müsste ich mich doch erst tiefer in die Materie einarbeiten. Geht aber im Moment aus Zeitmangel nicht.

Ich habe aber versucht die Datei mit Recode in der Konsole nochmal neu zu kodieren und habe folgende Meldung erhalten:

ln@linux-99oe:~/Dokumente> recode Collateral-german.srt UTF-8
recode: Request `Collateral-german.srt' is erroneous
ln@linux-99oe:~/Dokumente>

Ich gehe also mal davon aus, dass die Datei wohl in früheren Vorgängen zerschossen wurde. Schade.


Gruß

....

 

[RME]

Hallo,

ln@linux-99oe:~/Dokumente> recode Collateral-german.srt UTF-8
recode: Request `Collateral-german.srt' is erroneous
ln@linux-99oe:~/Dokumente>

Dies bedeutet dass "Collateral-german.srt" keine bekannte Kodierung ist (woher hast Du diese Bezeichnung?).

Eine typische anwendung von 'recode' wäre:

> recode latin1..u8 < in.html > out.htm

oder

> recode windows-1252..u8 < in.txt > out.txt

(input darf nicht = output sein)

Du erhälst eine Liste der von 'recode' unterstützten Kodierungen mit:

> recode -l

(siehe die man page für 'recode')

Du kannst eine Datei auch (wie üblich mit Linux) auf andere Art als mit 'okteta' octal darstellen. Hier ein Beispiel:

Eine Test-Datei namens "od_test.txt"

> cat od_test.txt
123 abc
>

Mit 'od' (dump files in octal and other formats) darstellen:

Zuerst ascii (-a option):

> od -a od_test.txt
0000000   1   2   3  sp   a   b   c  nl
0000010
>

(sp = space, nl = newline)

und octal (-b option):

> od -b od_test.txt
0000000 061 062 063 040 141 142 143 012
0000010
>

Jetzt siehst Du dass:

    '1' = octal 061
    '2' = 062
    '3' = 063
  space = 040
    'a' = 141
    'b' = 142
    'c' = 143
newline = 012

Auf diese Weise könntest Du feststellen was die Kodierung der Problemzeichen in Deiner Datei ist; entweder immer gleich, oder verschieden. Je nachdem ist dann das weitere Vorgehen.

Ebenso würde die Kodierung Dir sagen von welchem Typ diese ist (z.B. WINDOWS-1258, oder latin3, oder UTF-8, etc). Ist die Kodierung UTF-8, dann werden für Umlaute etc. zwei (oder mehr) Bytes pro Zeichen verwendet; andere Kodierungen nur ein Byte.

Eine einfachere Methode wüsste ich nicht.

Gruss,
Roland

 

[Kutscher58]

Danke für die Hilfe. Aber die Datei war sicherlich defekt. Für jeden Umlaut stand jeweils immer das gleiche Hexadezimalzeichen (c3). Ich hab's aus Zeitgründen jetzt manuell abgeändert.

Gruß und Dank vom
Kutscher




...

 

[Kutscher58]

Für alle die es noch interessiert. Ich habe im Nachhinein eine einfache Lösung gefunden.

Das Programm 'Aegisub' liest so gut wie alle Untertitelformate und hat auch hier die Datei richtig wiedergegeben. Die Original *.sub Datei habe ich dann als *.srt abgespeichert und danch ganz normal mit 'Gnome Subtitles' bearbeitet.


Gruß vom
Kutscher