eine 2012 gespeicherte HTML-Seite zeigt mir auf dem Samsung S5 sämliche Umlaute als ? an. Auf dem PC unter MSIE, FF, Opera ist dies nicht so. Allerdings wird eine aktuelle gespeicherte Seite auf dem S5 richtig angezeigt.
Samsung geht wohl hartnäckig von UTF-8 codiertem HTML aus, das vermutlich aber in ISO8859 vorliegt. MSIE, FF, Opera sind da wohl "flexibler" und erkennen, daß das HTML in ISO8859 codiert ist.
Ich sehe nun auch unter MSIE, FF und Opera keine Umlaute mehr und auf dem S5 hat sich nichts verändert. Bild 1 zeigt die Umlaute unter FF und Windows, Bild 2 unter FF und Ubuntu. So wie in Bild 2 werden die Umlaute auch auf dem S5 dargestellt. In Bild 3 lasse ich mir unter FF und Ubuntu den Quelltext anzeigen. Bereits hier werden mir die Umlaute nicht mehr angezeigt ???
Benenne ich *.htm in *.txt um, sehe ich die Umlaute wie üblich.
Jetzt blicke ich nicht mehr durch :-(
Samsung geht wohl hartnäckig von UTF-8 codiertem HTML aus, das
vermutlich aber in ISO8859 vorliegt. MSIE, FF, Opera sind da wohl
"flexibler" und erkennen, daß das HTML in ISO8859 codiert ist.
So scheint es zu sein, denn mit ISO8859 stimmt nun unter MSIE, FF und Opera alles wieder. Nicht aber bei Samsung.
Für die Alben in der Galerie gibt es offensichtlich ein 120 Dateien Limit, denn danach bleibt hier unter Ubuntu zuverlässig die Übertragung stehen. Dann tauchen die Ordner der HTML-Dateien in der Galerie auf und so weiter. Nach derart viel Theater habe ich das Speichern von HTML-Dateien verworfen.
Überhaupt klappt das Sortieren von Bildern mittels Zeitstempel nur bei jpg Dateien. Hat man in seinem Album zusätzlich Bilder in anderen Bildformaten (gif, png, bmp) oder Videos, klappt das mit dem Sortieren nicht mehr. Hier hat es geholfen, den Zeitstempel der jpg Dateien zu entfernen, dann sortiert das S5 zuverlässig in der Reihenfolge der Übertragung.
Für die Alben in der Galerie gibt es offensichtlich ein 120 Dateien
Limit, denn danach bleibt hier unter Ubuntu zuverlässig die Übertragung
stehen. ....
Überhaupt klappt das Sortieren von Bildern mittels Zeitstempel nur bei
jpg Dateien.
Erklär mal was du da machst. Mit welcher Software übertragst Du die Dateien? Und was haben die jpg mit den html zu tun?
OK, aber da ist DOCTYPE groß geschrieben. Vielleicht ist das wichtig.
Ich finde es allerdings fragwürdig, keine HTML Version anzugeben. Die dahinter stehende Annahme, dass alle Versionen ab 5.0 immer zueinander kompatibel sein werden finde ich ziemlich naiv. Als hätten wir damit keine Erfahrung aus der Vergangenheit. Naja, so ist das jetzt halt. Gut, dass das nicht meine Idee war. Ich wasche meine Hände in Unschuld.
Mir fällt da gerade was ein: Hatten wir nicht erst vor kurzem die Diskussion, dass ISO8859-1 in HTML 5 nicht mehr zulässig ist? Jupp, wird prompt vom W3C Check moniert.
Erklär mal was du da machst. Mit welcher Software übertragst Du die
Dateien?
Keine Software. Einfach beide Geräte (Notebook und Smartphone) mit dem originalen Samsung USB-Kabel verbinden und dann von einem Ordner in den anderen Ordner kopieren.
Und warum speicherst du die HTML-Datei nicht einfach als UTF-8?
Die betreffende Seite habe ich vor ca. 10 Jahren gespeichert.
Die Seite ist heute nicht mehr im Netz.
Der Hintergrund ist, dass ich einige Projekte (mit allen möglichen Dateitypen) auf dem Smartphone haben wollte. Ich dachte, das verhält sich wie auf dem Notebook. Dem ist aber nicht so. Also werde ich unterwegs weiterhin das Notebook nutzen.
Da frage ich mich nach wie vor, wie man das in Sprachen geht,
die überhaupt garkeine lat. Zeichen haben:
Auch nicht anders als bei uns. Die verwenden entweder eine 8-Bit-Codepage, die halt anders aussieht bei uns, oder sie verwenden UTF-8.
Früher™ war man halt der Ansicht, mit Varianten von 7-Bit-ASCII zurechtzukommen, und es gab mal eine deutsche Ausführung davon, die eckige und geschweifte Klammern sowie Backslash und vertikalen Strich durch Umlaute ersetzte, und noch ein Zeichen, das ich jetzt nach über drei Jahrzehnten vergessen habe, wurde durch das ß ersetzt.
Wenn Du also Behördenpost bekommst, in der in Deinem Namen eine "[" auftaucht, ist damit ein 'Ä' gemeint. Das wiederum lässt darauf schließen, daß der entsprechende Datensatz irgendwann vor 1995 angelegt wurde ...
Da frage ich mich nach wie vor, wie man das in Sprachen geht,
die überhaupt garkeine lat. Zeichen haben:
Da kennt dann hoffentlich ein freundlicher Post-Mitarbeiter die üblichen Fehl-Kodierungen und bastelt aus den handschriftlichen Umlauten etc. wieder die richtige Kodierung, hier Kyrillisch...
Im Japanischen wird das Problem als
Mojibake (japanisch 文字化け, „Buchstabenverwandlung“) bezeichnet,
im Russischen als krakosjábry (кракозябры) und im
Chinesischen als luànmǎ (亂碼 / 乱码, „wirre Kodierung“).
Früher™ war man halt der Ansicht, mit Varianten von 7-Bit-ASCII
zurechtzukommen, und es gab mal eine deutsche Ausführung davon, die
eckige und geschweifte Klammern sowie Backslash und vertikalen Strich
durch Umlaute ersetzte, und noch ein Zeichen, das ich jetzt nach über
drei Jahrzehnten vergessen habe, wurde durch das ß ersetzt.
Das war ungefähr zu der Zeit, als wir für die Erbsen-Nadeldrucker noch eigene character-set EEPROMs gebastelt und gebrannt hatten, um dem Anspruch der Behörden bzw. Gesetzesvorgaben Genüge zu tun. Gleiches für die 3270 Terminals.
Wenn Du also Behördenpost bekommst, in der in Deinem Namen eine "["
auftaucht, ist damit ein 'Ä' gemeint. Das wiederum lässt darauf
schließen, daß der entsprechende Datensatz irgendwann vor 1995 angelegt
wurde ...
Tja, scheint EBCDIC zu sein, und man kann sich offensichtlich nicht für eine Zeichencodierung entscheiden, und das Zeichen geht durch unterschiedliche Zeichensätze ...
Ä und [ teilen sich beide in EBCDIC den Codepoint 0x4A, einmal in Codeset 273 (deutsch als Ä), und in 500 (international, aber auch speziell Schweiz) als [ ...
Scheint also noch irgendein Mainframe-System zu sein