Probleme mit Umlauten

  • Ersteller scheibenwischer
  • Erstellt am
scheibenwischer

scheibenwischer

Aktives Mitglied
Thread Starter
Dabei seit
30.01.2004
Beiträge
359
Reaktionspunkte
1
Grüß Euch!

Hab ein Problem mit Umlauten, daß mich langsam aber sicher in den Wahnsinn treibt! :mad: Keine Ahnung woran das liegen könnte.

Habe eine Website mit etlichen Scripts zu warten, in denen natürlich auch Umlaute und Sonderzeichen vorkommen.
Wenn ich mit dem RBrowser solche Files vom Server lade, und dann entweder mit TextEdit oder SubEthaEdit öffne, dann werden die Umlaute komplett verhunzt dargestellt.
Das ist insofern ein Riesenproblem, als ich diese Site natürlich auch regelmäßig sichern, sprich herumterladen will. Bloß wenn die Files dabei "zerstört" werden, dann ist das natürlich sinnlos. :rolleyes:

Hat jemand eine Ahnung, wo ich ansetzen kann, um dieses Problem in den Griff zu bekommen?
 
Du mußt die Zeichen in HTML maskieren ä = &auml; Wenn du viele Texte damit hast, kannst du alle zu maskierenden Zeichen mit dem "Unicode Checker"-Tool (bei VersionTracker) umwandeln. Einfach den zu wandelnen Text komplett makieren und das Ganze dann über Dienste => Unicode => Unicode -> HTML Entities umwandeln. In besthenden HTML-Dateien dabei auf "Preserving > < & and " " achten, damit dir deine <html>-Tags nicht zerschossen werden.

Gruß,
Tobias
 
In einigen Fällen hab ich mir mit HTML beholfen, aber das kann man so auch nicht immer machen.
z.B. Hab ich ein File, in dem ein Standard-Text für Mails steht. Wenn ich dort den HTML-Code für die Sonderzeichen verwende, wird der ja nicht umgewandelt, sonden 1:1 so anzegeigt, wie er im File drinnensteht.

Auf einer DOSe hab ich's auch schon ausprobiert. Dort hab ich allerdingskeine Probleme. Dort werden die Sonderzeichen im Standard-Editor brav angezeigt. :confused:
 
Die Editoren interpretieren einfach den Zeichensatz falsch. Unter Subetha kannst Du das nach dem Öffnen der Datei entsprechend ändern:

Format->Dateikodierung
 
Agmemon schrieb:
Die Editoren interpretieren einfach den Zeichensatz falsch. Unter Subetha kannst Du das nach dem Öffnen der Datei entsprechend ändern:

Format->Dateikodierung
Zum Vergrößern anklicken....

Das hab ich auch schon ausprobiert, und war mit allen Kodierungen. Hab's nicht geschaft. Der Zeichensalat schaut bei den verschiedenen Kodierungen zwar unterschiedlich aus, aber die Umlaute selbst werden nie richtig angezeigt. :(

Oder vielleicht check ich's auch ganz einfach nur nicht.
Ich hab eines dieser Problemfiles angehängt.
Vielleicht erbarmt sich ja jemand meiner und versucht mir im Detail zu erklären, wie ich das richtig anstelle... :)
 
OK, anders interpretieren bringt nichts. Dass Problem ist, das die Umlaute in zwei Buchstaben umgesetzt wurden. Ich vermute mal, das beim Download vom Server UTF16 (2 Byte) in UTF8 oder eine andere Codierung (1 Byte) umgesetzt wurde. Daraus resultiert, das aus einem Zeichen zwei geworden sind.

Ist RBrowser ein FTP-Client? Dann spiele doch mal ein wenig mit dem Tranfer-Mode (bin/ascii).
 
Sorry...das File von zuvor war nicht das originale. Da hab ich schon in irendwas anderes konvertiert. Standardmäßig kommt das File nur mit einem Zeichen anstatt der Umlaute herunten. Hab' nochmal angehängt.

Mit den Transferarten hab ich mich jetzt auch noch gespielt --> Kein Erfolg.

Was ganz komisches ist mir noch aufgefallen:

Die Files haben ursprünglich die Dateiendung .tpl. Wenn ich die TPL-Dateien als TXT abspeichere, dann werden die Zeichen plötzlich korrekt angezeigt. Wenn ich TPL-Dateien als solche abspeichere, bleibt aber alles beim Alten und die Umlaute werden falsch dargestellt.

Die Sache wird für mich immer verwirrender. :confused:
Kann ja wohl nicht sein, daß der SubEthaEdit derartige Probleme nur wegen der Dateiendungen macht, oder?
 
Wenn ich Deine angehängte datei mit SubEtha öffne und die Dateikodierung von Mac auf Windows Latin 1 umstelle und sage, er soll neu interpretieren, dann sind die Umlaute wieder da. :)
 
Genau! Weil es eben ein txt-File ist. Mit den tpl-Files funkt es aber nicht. (Beispiel kann ich leider nicht raufladen, weil nicht erlaubt).
Ich müßte also die TPLs in TXT umbenennen und neu interpretieren. Bei ein paar 100 Files ist das aber ein wenig mühsam.

Mir geht das einfach nicht ein... :confused:
 
Hi, habe es jetzt auch mit der Endung tpl versucht. Macht bei mir aber keinen Unterschied zur Endung txt.

Aber in den SubEtha Einstellungen habe ich einen Punkt gefunden, mit dem Du das Problem umgehen kannst: Dort kann man die Standardkodierung einstellen. Wenn Du da Windows latin angibst, wird die Datei immer richtig geöffnet.

Ist zwar keine Lösung aber vielleicht ein Workaround. :(
 
Beibt mir wohl nix anderes über, als mir mit Workarounds zu behelfen. Mich ärgern solche Geschichten ohne Ende! Bin jetzt draufgekommen, daß meine ganzen Datanbank-Sicherungen fürn A**** sind, weil diese blöden Editoren die Umlaute einfach nicht raffen. Jetzt müßte ich 1000e Files in TXT und dann wieder auf die eigentliche Endung umbenennen, damit ich's wieder zum Laufen bekomme. Das ist ja wohl echt das allerletzte! :mad: motz

Jedenfalls danke, Agmemon, für deine Hilfe und Bemühungen! :)
 
Kein Problem, aber gib nicht den armen Editoren die Schuld, die können dafür nichts. Normale Text-Dateien haben nunmal keine Encoding-Information. Und in der Zeit vor HTML und XML hat das keinen interessiert.

In den heutigen Zeiten kommt es allerdings zu Problemen, vor allem, da man mit Daten über die Systemgrenze hinaus arbeitet. Ich habe genau in diesem Bereich ein riesen Problem bei einem Kunden. Dort ist noch ein Verwaltungsprogramm, entwickelt für DOS, im Einsatz, weil die Entwickler die Umsetzung auf Windows verschlaffen haben, und immer noch daran arbeiten.

Diese Software erstellt Ausdrucke, indem der Text in eine Textdatei geschrieben wird und per copy-Befehl an den Drucker geschickt wird. In Zeiten von GDI-Druckern war das in einem reinen Windows-Netzwerk schon ein Problem. Nun befindet sich aber ein CUPS-Printserver im Netz der jetzt auch die Umlaute nicht umsetzen kann, da er nicht mit den notwendigen Encoding-Informationen versorgt wird. :(

Aufgrund der immer wieder auftretenden Probleme mit Textdateien habe ich mir angewöhnt, nur noch mit UTF-8 zu arbeiten, und wenn möglich das Encoding anzugeben (HTML, XML) und Escaping einzusetzen.

Bei deinen 1000 Dateien bedeutet das zwar viel Arbeit und hilft nicht bei deinen Mail-templates, ausser Du regulierst das ganze Scriptseitig, aber in Zukunft kann das einiges an Ärger sparen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten