ABAKUS

Hi,

ich habe eine Seite (www.mallorca-residence.biz / net / es) komplett in UTF-8 aufgebaut da ich hier so gut wie alle Zeichensätze für alle Sprachen verwenden kann. Leider wird das Suchergebniss in der enkodierten version angezeigt obwohl ich in den Meta die Sprache drin habe, den Zeichensatz und zusätzlich den PHP header mit UTF-8 setze. Warum erkennen das die Suchmaschinen nicht ?!

Hier mal ein Beispiel was Poodle ausspuckt:
https://www.gritechnologies.com/tools/s ... idence.biz

Gruß
Christian

Das Problem ist hier wohl das Poodle-Tool. Die ignorieren den Zeichensatz und geben die Seite mit ISO-8859-15 um ohne vorher die UTF8-Zeichen umzuwandeln. Der Googlebot wird da ein bisschen intelligenter drangehen...

ich habe eine Seite (www.mallorca-residence.biz / net / es) komplett in UTF-8 aufgebaut

Warum erkennen das die Suchmaschinen nicht ?!

Weil die erste Aussage falsch ist. Die Seite ist als Ascii gespeichert, nicht als UTF-8. Steht dann im Header UTF-8 drin, so ist das ein Widerspruch und führt zu den bei google beobachtbaren inkonsistenten Ergebnissen.

@oldInternetUser:
Das verstehe ich nicht. Die Seite enthält UTF-8 Zeichen und wird mit Header UTF-8 ausgeliefert. Wo siehst du da Probleme?
Nebenbei ist der Fehler nicht bei Google sichtbar, dort sind noch keine Daten der Seite zu sehen. Der Fehler taucht in einem anderen Tool wo die UTF-8 Zeichen ausgegeben werden, der Header ab ISO-8859-15 Kodierung ankündigt.

wie speicherst du die seite? bietet dein editor dir die möglichkeit, sie als utf8 zu speichern?

@mariow:

(1) @Webpicasso hat vor ein paar Tagen einen Thread mit demselben Problem in bezug auf google gestartet, da war die Seite noch in google drin.

(2) Dir scheint der Unterschied zwischen der relativen Darstellung desselben Ascii-Datenstromes mithilfe verschiedener Codepage-Angaben sowie der absoluten Darstellung eines mit korrektem BOM beginnenden Unicode-Datenstromes (UTF-8 oder UTF-16) unbekannt zu sein. Handelt es sich um einen Ascii-Datenstrom und wird dieser mit UTF-8-Header ausgeliefert, so kann das Ergebnis bei höheren Zeichen nur Unsinn sein - außer das Tool ist ebenfalls so grottenschlecht (bzw. bei Browsern: fehlertolerant), daß es den Unsinn ignoriert.

Sprich: Die Seite enthält definitiv keine UTF-8-Zeichen, sie enthält Ascii sowie einen fehlerhaften Header, der von Browsern ignoriert wird, da denen das BOM fehlt.

@oldInternetUser:

Ahso, den vorherigen Thread hab ich nicht bemerkt, bin daher nur von dem hier benannten Tool ausgegangen.
Was meine Unkenntnis angeht, hast du vermutlich recht. Mit Zeichenkodierungen habe ich mich bisher nicht intensiv beschäftigt, schlage mich damit nur rum, wenn es nicht anders geht. Tatsächlich kann ich da bei der hier angegebenen Webseite keine wesentlichen Unterschiede zu anderen Webseiten mit UTF-8 oder selbst erzeugten UTF-8 Dateien feststellen.

Aber du scheinst dich ja gut auszukennen: Ist es nicht so, dass UTF-8 bei Webseiten in fast allen Fällen nur genutzt wird um einzelne Zeichen zu kodieren? Solche Seiten also eigentlich nie als vollständiger UTF8-Datenstrom ausgeliefert werden?

danke erstmal für die Antworten

@oldInternetUser:

Wenn ich in ein Formular einen Text eingeben (Codierung auf UTF-8) und diesen dann in eine Datenbank speichere sollte das doch dann auch UTF-8 sein oder nicht ?! Mein Problem ist, dass die Seiten komplett dynamisch sind mit BOM meinst Du wahrscheinlich den HEX-Mark der am anfang einer Datei steht. Also eine statische Seite als UTF8 speichern ist ja kein Thema und das wird dann auch richtig dargestellt aber wie mache ich das mit dynamischen Seiten ?

Habe gerade noch etwas getest:
Wenn das file mit UTF-8 codierung gespeichert wird dann passt es auch nicht: https://www.mallorca-residence.biz/test.html

Gruß
Chris

@Webpicasso: Bei mir zeigt die 'test.html' russische Zeichen an, nun ist die Datei korrekt als UTF-8 gespeichert. Füge noch

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

in den Header ein, dann dürfte das von allen Browsern erkannt werden.

Bei dynamischen Seiten hängt es (1) vom Script ab, das die Daten entgegennimmt und eventuell umcodiert, (2) vom Datenbankfeld (muß nvarchar statt varchar sein - oder binär, dann müssen die Datenströme aber erst recht korrekt codiert werden) und (3) vom Script, das die Inhalte holt und als Html ausgibt. Da gibt es beliebig viele Klippen.

@mariow:

Ist es nicht so, dass UTF-8 bei Webseiten in fast allen Fällen nur genutzt wird um einzelne Zeichen zu kodieren?

Erarbeite dir die Kenntnisse und lies dann in einigen Monaten nochmals deine Beiträge durch - Du wirst entgeistert sein. Das ganze dmoz wird als UTF-8 ausgeliefert, aus genau den Gründen, die @Webpicasso im ersten Beitrag erwähnt hat.