Darstellungsproblem mit Umlauten und Sonderzeichen

[ClemensSchnitzler]

per Webgrab habe ich eine Tabelle auf einer externen Webseite in meine zu bearbeitende Seite integriert. Das klappt wunderbar, bis auf die Darstellung der Umlaute und diverser Sonderzeichen. Ich habe schon im Header von charset=iso-8859-1 zu z. B. utf-8 gewechselt, konnte damit aber leider keine Änderung erreichen.

Das Original findet Ihr unter folgendem Link:
http://www.sis-handball.de/SIS/HANDBALL ... E=/sis.css

Die "gegrabte Seite findet Ihr hier:
http://handball.c-schnitzler.de/spielte ... 7/damen-i/

Es wäre nett, wenn Ihr Euch das mal anschauen und mir weiterhelfen könntet.

Vielen Dank

Gruß

Clemens

[emergence]

der gegrabbte content ist utf-8, deine seite iso8859-1

text/html; charset=iso-8859-1 als meta tag zu setzen alleine reicht da nicht....
der gegrabbte content müsste von utf-8 auf iso8859-1 konvertiert werden...
dafür gibts in php -> iconv , eventuell tuts auch utf8_decode

[ClemensSchnitzler]

Das Problem ist, sdass ich das Ganze in einer 4.4.4er Version Contenido schon mal laufen hatte. Unter 4.6.15 funktioniert es so nicht mehr.

Verantwortlich dafür ist meines Erachtens folgender Code in welchem sich ein Fehler befindet.

Code: Alles auswählen

<?php 
$search = array ("'Ä'",  
                 "'Ö'",           
                 "'Ü'",                 
                 "'ß'",                
                 "'ä'",
                 "'ö'",
                 "'ü'"); 
                 
$replace = array ("&Auml;",
                  "&Ouml;",
                  "&Uuml;",
                  "&szlig;",
                  "&auml;",
                  "&ouml;",
                  "&uuml;");
 

Damit fängt mein Webgrab-Modul an, scheint aber nicht ausgeführt zu werden.

[emergence]

sicher nicht richtig sind die simple quotes bei $search -> die '
haben dort nichts verloren....
EDIT: in dem fall doch richtig da es für preg_replace ist und -> ' als delimiter gesetzt ist...

das hat aber nichts mit der utf8 <-> iso8859-1 konvertierung zu tun...

wenn man sich ein utf-8 zeichen in einer iso8859-1 umgebung ansieht(ich nehm jetzt mal das ü) hat man etwas wie das hier:

ü

dein suchen und ersetzten läuft somit ins leere...

[ClemensSchnitzler]

Gut, dann liegt es daran nicht. Ich verstehe nur nicht, dass das auf einer 4.4.er Version funktioniert. Gut, dort ist ein älteres PHP und eine ältere MySQL installiert.

Siehe hier: http://handballmainz05.de/front_content ... t=1&lang=1

php -> iconv ist auf dem Server mit der 4.6.15er Version installiert und aktiv. Weißt Du vielleicht, was ich nun wie machen muss, um das Problem zu lösen?

Viele Grüße

Clemens

[emergence]

Ich verstehe nur nicht, dass das auf einer 4.4.er Version funktioniert.

sieh dir den quellcode der alten seite an... dort wird utf-8 verwendet...
deshalb stimmen die umlaute die von einer anderen utf8 seite kommen...
auch via firefox ersichtlich... da kann man es auch umstellen -> dann siehst du den selben effekt wie bei der anderen seite

zwei tipps hab ich dir bereits geben -> iconv und utf8_decode -> d.h bitte selbst schlau machen...

[ClemensSchnitzler]

Hallo emergence,

vielen Dank für Deine bisherige Hilfe. Mit Deiner Lösung kann ich leider nicht ganz konform gehen, da ich überzeugt bin, dass dies ein Problem von Contenido ist.

Ich habe mir den Quelltext der Seite mal genauer angeschaut. Da habe ich festgestellt (nach Deinem Hinweis, dass charset iso8859-1 anstatt utf-8 definiert ist), trotz dass ich utf-8 definiert habe durch den internen Metatag-Generator von Contenido weiter unten im Qelltext wieder iso8859-1 eingetragen wird.

Wie im Post http://contenido.org/forum/viewtopic.php?p=97832#97832 beschrieben habe ich diesen Generator nun abgeschaltet, die Tabelle con-code geleert und auch den cache gelöscht. Innerhalb von contenido werden die Sonderzeichen aber immer noch nicht korrekt dargestellt. Nun bin ich hingegangen und habe den Quelltext intern gespeichert. Wenn ich mir das nun im Browser anschaue ist die Darstellung korrekt. Auch wenn ich diese Datei auf den Server lade, die Darstellung bleibt korrekt.

Also ist es wohl so, dass innerhalb von Contenido irgend etwas passiert, was zur falschen Darstellung der Zeichen führt. Und danach bin ich leider noch am suchen.

Viele Grüße

Clemens

[emergence]

da ich dennoch anderer meinung bin (und keine überzeugungsarbeit leiste), kann ich dir nur viel erfolg bei deiner suche wünschen...

sag bescheid wie deine lösung aussieht...

[Dodger77]

Also ist es wohl so, dass innerhalb von Contenido irgend etwas passiert, was zur falschen Darstellung der Zeichen führt.

Das wird wahrscheinlich nicht der Fall sein. Evtl. liegt das nur an der Apache-Konfiguration. Denn deine Meta-Angaben zum Encoding werden nicht verarbeitet, wenn der Apache ganz andere Angaben per HTTP-Header macht. Und in deinem Fall sieht es so aus, als würde genau das geschehen. Es wäre mal einen Versuch wert, in deinen Mandantenordner eine ".htaccess" mit folgendem Inhalt zu packen (bzw. eine vorhandene Datei zu ergänzen):

Code: Alles auswählen

AddDefaultCharset utf-8

[ClemensSchnitzler]

@ Dodger77
Vielen Dank, das habe ich versucht. Ich verwende die Version 4.6.15 ModRewrite von Polycoder. In die dazugehörige .htaccess-Datei habe ich zuerst ganz am Anfang

Code: Alles auswählen

AddDefaultCharset utf-8

eingefügt. Das Ergebnis war, dass ich nur noch Fehler 500 geliefert bekam.
Dann habe ich den Code gang am Ende eingefügt, aber auch hier gab es nur den Fehler 500.

@emergence
Auch Dir vielen Dank. Du musst keine Überzeugungsarbeit leisten. Allein fehlt mit eine Idee der Vorgehensweise zur Umsetzung Deiner Lösungsvorschläge. Laut der php.ini des Servers ist der Converter iconv aktiv. Ich gehe davon aus, dass ich diesen in meiner Modulkonfiguration ansprechen und auffordern muss auch das zu tun, was er soll. Vielleicht kannst Du meine Gedankengänge in die richtige Richtung lenken.

So wie ich das sehe bekommt iconv die Anweisung über folgenden Code

Code: Alles auswählen

#include <iconv.h>

iconv_t iconv_open (const char* charset=iso-8859-1, const char* charset=utf-8)
	

#include <iconv.h>

int iconv_close (iconv_t cd);

Ist dies eine Anweisung die nun serverseitig, das heist in der php-Konfiguration definiert wird oder gebe ich das in der Modulkonfiguration ein, in welcher die Seite gegrabbt wird?

Viele Grüße

Clemens

[Dodger77]

@ Dodger77
Vielen Dank, das habe ich versucht.

OK, das habe ich mir gerade nochmal angeschaut. Contenido setzt den Header selbst nochmal in der front_content.php. Dafür wird dann der Wert genommen, der unter "Administration->Sprachen" angegeben ist. Hast du den Meta-Tag etwa manuell im Layout angegeben?

[ClemensSchnitzler]

Ja, UTF-8 betrifft fünf Seiten des Webauftritts. Dafür habe ich ein eigenes Layout in welchem der Tag mitgegeben wird. Der Rest ist alles ISO.

Da in meinem Header ziemlich oben UTF-8 definiert war und durch Contenido weiter unten im Header ISO zusätzlich eingetragen wurde, habe ich dann in der con.functions2.php den Eintrag, dass Contenido den Header erzeugt, gelöscht. Seitdem steht im Quelltext nur noch das durch mich definierte charset. Die Tabelle concode habe ich geleert. Es blieb aber alles beim alten.

[Dodger77]

Jetzt verstehe ich das erst. Das wird so wahrscheinlich nicht funktionieren, da das Charset ja nicht nur durch die META-Angabe bestimmt wird, sondern in erster Linie durch den HTTP-Header. Und dieser wird in der front_content.php gesetzt durch:

Code: Alles auswählen

/*
 * Send HTTP header with encoding
 */
header("Content-Type: text/html; charset={$encoding[$lang]}");

Die Browser orientieren sich i.d.R. am HTTP-Header, der META-Tag ist für die zweitrangig. Und durch obigen Code wird halt das Encoding gesetzt, dass unter "Administration->Sprachen" angegeben ist.

Ich halte es daher auch für sinnvoller, das Encoding nicht für eine Einzelseite gesondert zu setzen, sonder wie emergence geschrieben hat, den gegrabbten Code per iconv oder utf8_decode in ISO umzuwandeln.

Alternativ könntest du natürlich auch die komplette Website als UTF8 ausliefern.

[ClemensSchnitzler]

Alternativ könntest du natürlich auch die komplette Website als UTF8 ausliefern.

Wenn ich in den Mandanteneinstellungen auf utf-8 wechsle bekomme ich auf dem Rest der Seiten das Problem, dass die Umlaute nicht mehr angezeigt werden.

Dass ich anders eingreifen; dass heißt für mich komplizierter eingreifen muss habe ich mittlerweile verstanden. Ich weiß leider aber nicht wie ich vorgehen muss.

@emergence
Auch Dir vielen Dank. Du musst keine Überzeugungsarbeit leisten. Allein fehlt mit eine Idee der Vorgehensweise zur Umsetzung Deiner Lösungsvorschläge. Laut der php.ini des Servers ist der Converter iconv aktiv. Ich gehe davon aus, dass ich diesen in meiner Modulkonfiguration ansprechen und auffordern muss auch das zu tun, was er soll. Vielleicht kannst Du meine Gedankengänge in die richtige Richtung lenken.

So wie ich das sehe bekommt iconv die Anweisung über folgenden Code

Code: Alles auswählen

#include <iconv.h>

iconv_t iconv_open (const char* charset=iso-8859-1, const char* charset=utf-8)
   

#include <iconv.h>

int iconv_close (iconv_t cd);

Ist dies eine Anweisung die nun serverseitig, das heist in der php-Konfiguration definiert wird oder gebe ich das in der Modulkonfiguration ein, in welcher die Seite gegrabbt wird?

Ich habe halt nur definitiv keine Idee wie ich da vorgehen muss

Gruss
Clemens

[Dodger77]

In meinem letzten Post sind die Funktionen iconv und utf8_decode übrigens verlinkt. Schau dir die mal an. Als einfachstes würde ich in deinem Webgrab-Modul mal etwas in der Form:

Code: Alles auswählen

$code = iconv("UTF-8","ISO-8859-1",$code);

testen.