all-inkl: Nach Serverumzug Umlaute kaputt...

Robbat

Robbat

Aktives Mitglied
Thread Starter
Dabei seit
24.09.2004
Beiträge
233
Reaktionspunkte
0
Also,
da mein all-inkl Webspace letztens immer häufiger ausfiel, habe ich um einen Serverwechsel gebeten... Alles wunderbar, leider sind seitdem die Umlaute meiner Websites kaputt.

Bestes Beispiel, iWeb Spaßseite: www.zwei.sproesslinge.com

Ich habe nun rausgefunden, dass es daran liegt, dass die Umlaute im lokalen Quelltext auch als "ü" stehen und nicht als "ü" usw.
In den websites die ich selber code/mit GoLive mache, ist es ja kein Problem, das zu ändern, aber in der iWeb Seite ist es ein Problem, da ich keinen bequemen Zugriff auf den Quelltext habe!
Ich schreibe schon angeregt mit dem Kundendient von all-inkl, der sagt, es liege an der FTP Übertragung, ich solle es im ASCII mode probieren. Abgesehen davon, dass Captain FTP das ja selber macht (oder nicht?), hat eine Übertragung der html dateien im ASCII mode, keine Besserung herbeigeführt.
Vor dem Serverwechsel hat die Darstellung der Umlaute ja bedingungslos funktioniert!
Was kann ich tun? Hab auch versucht nochmal mit Cyberduck hochzuladen, bringt aber auch nichts...


Danke
Rob
 
Es liegt daran: <head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Dein Text bzw deine HTML Datei ist in UTF-8 kovertiert und somit zeigt er kein ü an.
Versuch mal den Head teil in Latin-1 zu aendern, dann sollte es gehen

mfg

//edit: hier der code:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
Zum Vergrößern anklicken....
 
Nun, iWeb speichert aber meines Wissens die Sachen immer als UTF-8 (die Aussage, mit UTF-8 kein ü darstellen zu können, ist im übrigen falsch).
Man sollte eher den Webserver dazu bringen, das auch als UTF-8 auszuliefern und nicht als iso-8859-1, was er derzeit macht, dann klappts auch mit den Umlauten.

Matt
 
msslovi0 schrieb:
Nun, iWeb speichert aber meines Wissens die Sachen immer als UTF-8 (die Aussage, mit UTF-8 kein ü darstellen zu können, ist im übrigen falsch).
Man sollte eher den Webserver dazu bringen, das auch als UTF-8 auszuliefern und nicht als iso-8859-1, was er derzeit macht, dann klappts auch mit den Umlauten.

Matt
Zum Vergrößern anklicken....

Jepp. Nach wie vor empfiehlt es sich natürlich, named entities zu benutzen, um genau dem Problem entgegenzuwirken. Zwar gibt es UTF8, allerdings muß eben der Webserver konfiguriert werden, und die charset Definition darf nicht doppelt vorliegen (z.B. in dem Dokument selber). Ferner muß jeder editor, der die Seiten editiert, UTF8 beherrschen, und es darf bei der Übertragung zu keiner konvertierung kommen.
Das sind einige Dinge, die man zu beachten hat, und da ist es doch einfacher, eben named entities zu schreiben.
 
incoming schrieb:
und da ist es doch einfacher, eben named entities zu schreiben.
Zum Vergrößern anklicken....

:jaja: ganz meine Meinung! Auch wenn das angesichts der zahlreichen Möglichkeiten die Codierung zu spezifizieren nicht mehr sein muß, sieht man hier sehr gut: wer portabel sein will, verwendet die entities!
 
Ähh. Ahso :p
Also liegt es am Server sprich an all-inkl?
Was soll ich denen jetzt schreiben? Oder muss ich nun was an meinen Dateien änder, ihr werdet mir hier zu intelligent, mit sowas hab ich mich noch nicht beschäftigt ;)

Danke
Rob
 
Du hast zwei Möglichkeiten. Entweder, du bringst all-inkl dazu, den Server so zu konfigurieren, das er die Dokumente als UTF-8 ausliefert. Wenn das irgendein Shared-Hosting-Rechner ist werden sie das aber definitiv nicht machen.

Oder du ersetzt deine ganzen Umlaute durch named entities. Also 'ü' wird zu '&uuml;', 'Ä' zu '&Auml;', 'ß' zu '&szlig;'. Aber im Quelltext eingeben, nicht direkt in iWeb, denn sonst wird daraus '&amp;uuml;'.

Matt
 
msslovi0 schrieb:
Du hast zwei Möglichkeiten. Entweder, du bringst all-inkl dazu, den Server so zu konfigurieren, das er die Dokumente als UTF-8 ausliefert. Wenn das irgendein Shared-Hosting-Rechner ist werden sie das aber definitiv nicht machen.

Oder du ersetzt deine ganzen Umlaute durch named entities. Also 'ü' wird zu '&uuml;', 'Ä' zu '&Auml;', 'ß' zu '&szlig;'. Aber im Quelltext eingeben, nicht direkt in iWeb, denn sonst wird daraus '&amp;uuml;'.

Matt
Zum Vergrößern anklicken....

Eben das war ja mein Problem, bei meinen eigenen Projekten, wo ich den Quellcode schreibe (GoLive) ist das ja kein Problem, aber in den iWeb Quelltext komme ich ja nur nach dem Export rein und genau die Änderungen an den iWeb Sachen will ich ja verhindern (weil ich iWeb eben benutze, da andere an dem Projekt mitarbeiten, die das Know-How nicht haben)...
Außerdem wäre da noch die Sache mit den Absätzen, die ja als "Â" dargestellt werden...

Weiterhin ist es ja komisch, dass die lokalen Dateien im Quelltext "ä,ö,ü" stehen haben, schaue ich mir den Quelltext der Datei auf dem Server an, finde ich im Quelltext die fehlerhafte Darstellung, die man im Endeffekt auch auf der Website sieht :( So einfach scheint die Lösung des Problems nicht zu sein, was die iWeb Seite angeht...
 
Probleme gibt es keine, wenn der Webserver überhaupt keine Kodierung vorgibt oder wenn er UTF-8 vorgibt:
Keine: http://www.parkplatzdieb.de/Willkommen.html [check]
UTF-8: http://flags.blogpotato.de/Willkommen.html [check]

Wenn der Webserver sich einbildet, ISO-8859-1 vorschreiben zu müssen, das Dokument aber eine andere Kodierung hat, kommt es zu den bekannten Problemen:
ISO-8859-1: http://statepolice.de/Willkommen.html [check]

Wenn du keinen Zugriff auf die Webserver-Konfiguration hast kannst du nur noch versuchen, das Charset mittels .htaccess zu überschreiben, in der Hoffnung, dass du das darfst:
Code: 
AddDefaultCharset utf-8

Matt
 
msslovi0 schrieb:
Probleme gibt es keine, wenn der Webserver überhaupt keine Kodierung vorgibt oder wenn er UTF-8 vorgibt:
Keine: http://www.parkplatzdieb.de/Willkommen.html [check]
UTF-8: http://flags.blogpotato.de/Willkommen.html [check]

Wenn der Webserver sich einbildet, ISO-8859-1 vorschreiben zu müssen, das Dokument aber eine andere Kodierung hat, kommt es zu den bekannten Problemen:
ISO-8859-1: http://statepolice.de/Willkommen.html [check]

Wenn du keinen Zugriff auf die Webserver-Konfiguration hast kannst du nur noch versuchen, das Charset mittels .htaccess zu überschreiben, in der Hoffnung, dass du das darfst:
Code: 
AddDefaultCharset utf-8

Matt
Zum Vergrößern anklicken....

Juhuu! Die .htaccess Methode funktioniert!! Vielen Dank :)
Nur kann es ja eigentlich nicht sein, dass jetzt auf einem neuen Server etwas nur mit "Notlösung" funktioniert, was sonst immer funktioniert hat...
Meint ihr es lohnt sich auf einen erneuten Serverwechsel zu bestehen?

Danke nochmal!
Rob
 
You're welcome.

Zum Thema Serverwechsel: Hast du einen eigenen Server bei denen oder nur Webspace auf einer Maschine? Bei letzterem wird ein erneuter Wechsel nichts bringen. Es ist mal davon auszugehen, dass sie ihre Shared-Hosting-Server alle gleich konfiguriert haben. Das es auf deinem vorherigen ging lag wohl daran, das er noch eine alte Config hatte.
 
Hallo!

Ich möchte mich in meinem Anliegen da dran hängen, da ich vor dem gleichen Problem stehe:
eine für eine Freundin in iWeb gestaltete Site sieht nach dem Hochladen am Webspace so aus: (webspace www.heim.at) http://psychotherapeutischepraxis.heim.at/Kontakt.html
Da ich leider kompletter HTML-Laie bin, habe ich eure Vorscläge nicht gut verstanden und ersuche euch, mir nochmal zu erklären, was ich da genau machen kann, damit die Zeichen richtig dargestellt werden ...

herzlichen Dank,
msg
 
Wenn du eine .htaccess-Datei ablegen kannst, eben das tun. Also Textdatei erstellen, lokal als htaccess speichern, hochladen und dort nach .htaccess umbenennen (nennst du sie gleich so, siehtst du sie auf dem lokalen System nicht mehr).
Die Datei hat als Inhalt eine Zeile:
Code: 
AddDefaultCharset utf-8

Klappt das nicht, heim.at beknien, das sie doch bitte kein Charset vorgeben möchten.

Matt
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten