AJAX und Sonderzeichen

[SebastianJu]

Hallo,

ich habe gerade mein erstes AJAX geschrieben. Der Code der dabei benutzt wird wird von der normalen Seitendarstellung genutzt und auch vom Ajax. Die gesamte Seite ist als iso-8859-1 kodiert.

Wenn die Seite normal aufgebaut wird sind alle Sonderzeichen korrekt dargestellt. Sobald ich aber die Ergebnisliste per AJAX darstelle sind alle Sonderzeichen Fragezeichen. Obwohl die Seitencodierung natürlich gleich geblieben ist und der ausgeführte Code im Prinzip der selbe ist.

Liegt das am Javascript? Kann ich da irgendwo die Codierung setzen?

Hier mal mein Code:

<script type="text/javascript">  
  function searchFor(suchbegriff){  
    var xmlhttp;  
    if (window.XMLHttpRequest){  
      // code for IE7+, Firefox, Chrome, Opera, Safari  
      xmlhttp=new XMLHttpRequest();  
    }else if (window.ActiveXObject){<div></div>  
      // code for IE6, IE5  
      xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");  
    }else{  
      alert("Es tut uns leid aber Ihr Browser unterstützt keine XMLHTTP Funktionalität.");  
    }  
  
    xmlhttp.onreadystatechange=function(){  
      if(xmlhttp.readyState==4){  
        document.getElementById("tablediv").innerHTML=xmlhttp.responseText;  
      }  
    }  
    var url="###formdirection###";  
    url=url+"?eID=ajaxsearch";  
    url=url+"&ajaxquery="+suchbegriff;  
    url=url+"&ajaxcid=###ajaxcid###";  
    url=url+"&pagelink=###pagelink###";  
    url=url+"&templatefile=###templatefile###";  
    url=url+"&sid="+Math.random();  
    xmlhttp.open("GET",url,true);  
    xmlhttp.send(null);  
  
    return false;  
  }

Danke!
Sebastian

[SebastianJu]

Ich glaube ich habe eine temporäre Lösung gefunden. Die Echoausgabe wird mit utf8_encode codiert wenn es ein ajaxaufruf ist und das wird unterlassen wenn es ein normaler aufruf ist. Jetzt sieht es normal aus.

Vermutlich keine perfekte Lösung aber erstmal läufts... :)

[dedlfix]

Hi!

Ich glaube ich habe eine temporäre Lösung gefunden. Die Echoausgabe wird mit utf8_encode codiert wenn es ein ajaxaufruf ist und das wird unterlassen wenn es ein normaler aufruf ist.

Ajax verwenden zu wollen und dabei nicht konsequent auf UTF-8 für das gesamte Projekt zu setzen, führt zu solchen Kodierungsinkompatibilitäten. Es geht dann ja auch weiter, wenn du mit Ajax Daten an den Server sendest. Die sind auch UTF-8-kodiert, wenn du ihnen keine Spezialbehandlung mit http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#escape@title=escape() zukommen lässt.

Vermutlich keine perfekte Lösung aber erstmal läufts... :)

Fürwahr nicht.

Lo!

[fastix®]

Moin!

Wie wäre es damit, statt xmlhttp.open("GET",url,true); auszuführen mit alert(url) die Zieladresse auszugeben und zu prüfen, was der Server wirklich sendet (inklusive Header)?

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[SebastianJu]

Moin!

Wie wäre es damit, statt xmlhttp.open("GET",url,true); auszuführen mit alert(url) die Zieladresse auszugeben und zu prüfen, was der Server wirklich sendet (inklusive Header)?

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

Die Zieladresse?
Und welchen Header meinst du? Es ist ja nur ein Stück HTML-Code dass das AJAX abfragt. Keine HTML-Header...

[Beat]

Die Zieladresse?
Und welchen Header meinst du? Es ist ja nur ein Stück HTML-Code dass das AJAX abfragt. Keine HTML-Header...

Prüfe mit einem Tool, was für Header der Server sendet, auch wenn du selbst keine definierst.

Wenn der HTTP-Request in der Antwort keine Information zum Zeichenencoding findet, welches Encoding wird dann angewendet?

Es kann aber sein, dass der Server eine Content-type Angabe mit Encoding sendet, gegen dein Wissen.

mfg Beat

[hotti]

hi,

Liegt das am Javascript?

Du kriegst eine Response und baust die mit JS ein. Diese Response (Zeichenkodierung) solltest Du Dir mal anschauen, auch den HTTP-Header der vornweg gesendet wird.

Kann ich da irgendwo die Codierung setzen?

Du hast eine iso-8859-1 codierte Seite wo Du was einbauen willst. Schicke die Zeichen in der Ajaxresponse mit derselben Codierung (header s.u.), dann stimmt auch die Darstellung.

header:
Content-type: text/html; charset=iso-8859-1

Hotti

[dedlfix]

Hi!

Du hast eine iso-8859-1 codierte Seite wo Du was einbauen willst. Schicke die Zeichen in der Ajaxresponse mit derselben Codierung (header s.u.), dann stimmt auch die Darstellung.

Diese Empfehlung ist so nicht richtig. Die Darstellung hängt nicht von der Kodierung ab, in der die angezeigte Seite irgendwann mal ausgeliefert wurde. Diese ist überhaupt nicht mehr von Belang. Für die Response des Ajax-Requests interessiert nur dessen Kodierung. Wenn diese passend zur tatsächlich verwendeten Kodierung angegeben wurde, kann da jede Kodierung verwendet werden, die der Borowser versteht.

header:
Content-type: text/html; charset=iso-8859-1

Das wäre ein Beispiel für die Deklarierung von ISO-8859-1.

Lo!

[SebastianJu]

header:
Content-type: text/html; charset=iso-8859-1

Aber wo kann ich dass denn setzen? Ich meine der Ajax-Request ruft ein PHP-Script auf welches dann nur einen String zurückliefert. Also keine extra Metatags...

Oder ist damit sowas im php-code gemeint?:

header('Content-type: text/html; charset=iso-8859-1');

Ich kann grad nicht testen aber ist es das?

[hotti]

hi,

header('Content-type: text/html; charset=iso-8859-1');

GEnau. Damit legst Du content-type und charset (was _ein_ header ist) für die Response fest. Wenn Du wissen willst, ob das PHP auch wirklich macht, musst Du Dir die header anschauen, entweder mit einem NEtzwerkanalysetool wie wireshark oder einem Browser-Plugin.

Hotti

[SebastianJu]

Alles klar. Probier ich montags. Danke!

[SebastianJu]

Alles klar. Probier ich montags. Danke!

Mit der iso-Codierung hat es nicht geklappt. Warum auch immer. Mit utf-8 aber schon.

Seltsam da die Seitencodierung so aussieht:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

[Der Martin]

Hallo,

Seltsam da die Seitencodierung so aussieht:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

ist dir auch klar, dass diese Zeile nur als Fallback zum Tragen kommt, wenn der Server im HTTP-Header keine Angabe zur Zeichencodierung macht - und im Normalfall völlig Banane ist?

Ciao,
 Martin

[SebastianJu]

Hallo,

Seltsam da die Seitencodierung so aussieht:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

ist dir auch klar, dass diese Zeile nur als Fallback zum Tragen kommt, wenn der Server im HTTP-Header keine Angabe zur Zeichencodierung macht - und im Normalfall völlig Banane ist?

Ciao,
Martin

Nein, das war mir nicht klar. Aber der Server sendet doch auch nur den Zeichensatz wenn dieser im php gesetzt wurde oder? Ansonsten wenn er einen Standardwert nutzen würde wäre dieser Metatag ja nutzlos...

[Der Martin]

Hi,

ist dir auch klar, dass diese Zeile nur als Fallback zum Tragen kommt, wenn der Server im HTTP-Header keine Angabe zur Zeichencodierung macht - und im Normalfall völlig Banane ist?
Nein, das war mir nicht klar. Aber der Server sendet doch auch nur den Zeichensatz wenn dieser im php gesetzt wurde oder?

die meisten Webserver sind so konfiguriert, dass sie immer eine charset-Angabe senden, die als Default eingestellt ist. Mit PHP kannst du diese Angabe nur "überschreiben".

Ansonsten wenn er einen Standardwert nutzen würde wäre dieser Metatag ja nutzlos...

Nutzlos nicht - er ist dann nützlich, wenn der Server tatsächlich keinen Defaultwert angibt und auch mit PHP (oder einer anderen Scriptsprache) kein entsprechender Header gesetzt wurde; oder wenn das Dokument nicht über HTTP übertragen wird, sondern beispielsweise aus dem Filesystem geladen wird.

Ciao,
 Martin

[dedlfix]

Hi!

Mit der iso-Codierung hat es nicht geklappt. Warum auch immer. Mit utf-8 aber schon.

Du brauchst den HTTP-Header "Content-Type" mit charset-Angabe. Natürlich muss die tatsächlich verwendete Kodierung auch der gemachten Angabe entsprechen.

Seltsam da die Seitencodierung so aussieht:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

Das Request nach dem ursprünglichen Dokument und der Ajax-Request sind zwei getrennte Dinge. Vom Server gemachte Kodierungsangaben (oder deren Ersatz als HTML-Meta-Element) gelten nur für die jeweilige Response.

Lo!

[SebastianJu]

Hi!

Mit der iso-Codierung hat es nicht geklappt. Warum auch immer. Mit utf-8 aber schon.

Du brauchst den HTTP-Header "Content-Type" mit charset-Angabe. Natürlich muss die tatsächlich verwendete Kodierung auch der gemachten Angabe entsprechen.

Seltsam da die Seitencodierung so aussieht:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

Das Request nach dem ursprünglichen Dokument und der Ajax-Request sind zwei getrennte Dinge. Vom Server gemachte Kodierungsangaben (oder deren Ersatz als HTML-Meta-Element) gelten nur für die jeweilige Response.

Lo!

Dann merkt sich der Browser die unterschiedlichen Codierungen für jeden Contentteil? Ich dachte es gibt eine Codierung für die ganze Seite...

[Der Martin]

Hallo,

Ich dachte es gibt eine Codierung für die ganze Seite...

nein, für jedes Request/Response-Pärchen separat. Ein AJAX-Request kann eine andere Codierung verwenden (normalerweise UTF-8) als das ursprünglich geladene Dokument.

Ciao,
 Martin

[SebastianJu]

Alles klar. Probier ich montags. Danke!

Mit der iso-Codierung hat es nicht geklappt. Warum auch immer. Mit utf-8 aber schon.

Seltsam da die Seitencodierung so aussieht:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

Jetzt wirds noch komischer. Auf der selben Seite habe ich jetzt noch eine Livesuche mit Ajax gemacht. Es gibt da jetzt also eine Tabelle mit Daten und darüber eine Suchbox. Wenn man da was eingibt und Submit klickt wird der erste Javarequest abgeschickt und die Tabelle neu gefüllt.
Die Livesuche zeigt jetzt schon während man klickt wie bei der Googelsuchbox Vorschläge an.

Das seltsame ist. Mit utf8 klappt es diesmal nicht. Aber mit iso8859-1... :o

Das php-Script ist eigentlich genauso eingebunden wie das erste... Obwohl ich eigentlich die Codebestandteile kenne die ich eingebunden habe.

Na irgendwo muss ja wohl ein Unterschied sein. Trotzdem seltsam...

[dedlfix]

Hi!

Na irgendwo muss ja wohl ein Unterschied sein. Trotzdem seltsam...

Wenn du dich auf den Zufall verlässt und immer nur die Stellen flickst, die gerade kaputt sind, wirst du am Ende möglicherweise einen Mischmasch haben und immer noch/mehr Probleme an der einen oder anderen Stelle. Deshalb meine Empfehlung: Steig komplett auf UTF-8 um. Dazu ist es notwendig die beiden sehr allgemein formulierten Grundsätze zu beachten: Jedes beteiligte System (Browser, Server, Datenhaltung) muss mit UTF-8 umgehen können, wenn es die Daten nicht nur unverändert durchreicht. Jeder Empfänger muss vom Absender über die verwendete Kodierung unterrichtet werden. Der Teufel steckt im Detail, weil man die verschiedenen Stellen kennen muss, an denen eine Kodierinformation auf welche Weise wirkt. Im SELFHTML-Wiki habe ich mal angefangen, das Thema umfassend zu beleuchten: http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung.

Lo!

[hotti]

hi,

Du hast eine iso-8859-1 codierte Seite wo Du was einbauen willst. Schicke die Zeichen in der Ajaxresponse mit derselben Codierung (header s.u.), dann stimmt auch die Darstellung.

Diese Empfehlung ist so nicht richtig.

Genau die wurde hier im Forum mal gegeben. Natürlich kannst Du auch anders codierte Zeichen einbauen, das hängt von der Aufgabenstellung ab.

Schönen Sonntag,
Hotti

[dedlfix]

Hi!

Du hast eine iso-8859-1 codierte Seite wo Du was einbauen willst. Schicke die Zeichen in der Ajaxresponse mit derselben Codierung (header s.u.), dann stimmt auch die Darstellung.
Diese Empfehlung ist so nicht richtig.
Genau die wurde hier im Forum mal gegeben. Natürlich kannst Du auch anders codierte Zeichen einbauen, das hängt von der Aufgabenstellung ab.

Vielleicht war das für den Fall einer Formularabsendung. Da hält sich in der Regel der Browser für die Formulardatenkodierung an die Kodierung der Seite, in der das Formular steht. Es ist nicht vorgesehen, dass der Browser dem Server in einem Request mitteilt, welche Kodierung verwendet wird. Das form-Attribut accept-charset, mit dem sich der HTML-Seiten-Ersteller eine oder mehrere Kodierungen wünschen kann, arbeitet nicht in allen Kombinationen (Browser zu Kodierung) korrekt. In diesem Formularfall ist es jedoch ein meines Wissens nach ungeschriebenes Gesetz, dass der Browser den Formularinhalt in der Formularseitenkodierung absendet.

Und welchen Fall haben wir hier vorliegen? Einen genau entgegengesetzten: Der Webserver sendet etwas an einen Browser. Und da gibt es die Möglichkeit, eindeutig über den charset-Parameter des Content-Type-Headers die Kodierung mitzuteilen.

Lo!

[Struppi]

ich habe gerade mein erstes AJAX geschrieben. Der Code der dabei benutzt wird wird von der normalen Seitendarstellung genutzt und auch vom Ajax. Die gesamte Seite ist als iso-8859-1 kodiert.

So wie es aussieht, stimmt das nicht. Du kannst dir das schnell anzeigen lassen, in dem z.b. im Firefox dir die Seiteninformationen anzeigen läßt (Kontextmenü).

Wenn die Seite normal aufgebaut wird sind alle Sonderzeichen korrekt dargestellt. Sobald ich aber die Ergebnisliste per AJAX darstelle sind alle Sonderzeichen Fragezeichen.

Das ist typisch für für ISO kodierte Zeichen in einer UTF Kodierten Seite.

Liegt das am Javascript? Kann ich da irgendwo die Codierung setzen?

Nein. Jein.

Es liegt nicht am JS, aber du kannst dort z.T. die kodierung die gesendet wird angeben (mit der Methode overrideMimeType), was aber im Normalfall überflüssig ist. Da das Problem ja im response steckt, nicht im request.

var url="###formdirection###";
    url=url+"?eID=ajaxsearch";
    url=url+"&ajaxquery="+suchbegriff;
    url=url+"&ajaxcid=###ajaxcid###";
    url=url+"&pagelink=###pagelink###";
    url=url+"&templatefile=###templatefile###";
    url=url+"&sid="+Math.random();

Hast du mal versucht ob auch Umlaute o.ä. übertragen werden? Du musst auch die Parameter eines AJAX Objektes URL kodieren. Am sinnvollsten mit http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#encode_uri_component@title=encodeURIComponent

Struppi.

[SebastianJu]

ich habe gerade mein erstes AJAX geschrieben. Der Code der dabei benutzt wird wird von der normalen Seitendarstellung genutzt und auch vom Ajax. Die gesamte Seite ist als iso-8859-1 kodiert.

So wie es aussieht, stimmt das nicht. Du kannst dir das schnell anzeigen lassen, in dem z.b. im Firefox dir die Seiteninformationen anzeigen läßt (Kontextmenü).

Aha. Da steht dann auch: text/html; charset=iso-8859-1

Komisch daran ist dass das eine Ajax nur mit UTF8 funktioniert aber nicht mit iso und das andere nur mit iso aber nicht mit utf8... Obwohl die aufgerufenen php-skripte eigentlich nicht unterschiedlich sind.

var url="###formdirection###";
    url=url+"?eID=ajaxsearch";
    url=url+"&ajaxquery="+suchbegriff;
    url=url+"&ajaxcid=###ajaxcid###";
    url=url+"&pagelink=###pagelink###";
    url=url+"&templatefile=###templatefile###";
    url=url+"&sid="+Math.random();

Hast du mal versucht ob auch Umlaute o.ä. übertragen werden? Du musst auch die Parameter eines AJAX Objektes URL kodieren. Am sinnvollsten mit http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#encode_uri_component@title=encodeURIComponent

Umlaute werden übertragen aber eben nur richtig angezeigt wenn die codierungen angegeben sind die ich oben angegeben habe. Bei der anderen Codierung sind die Umlaute jeweils andere Zeichen.

[Struppi]

ich habe gerade mein erstes AJAX geschrieben. Der Code der dabei benutzt wird wird von der normalen Seitendarstellung genutzt und auch vom Ajax. Die gesamte Seite ist als iso-8859-1 kodiert.

So wie es aussieht, stimmt das nicht. Du kannst dir das schnell anzeigen lassen, in dem z.b. im Firefox dir die Seiteninformationen anzeigen läßt (Kontextmenü).

Aha. Da steht dann auch: text/html; charset=iso-8859-1

Das wiederspricht deinen Schilderungen, wenn du in einer ISO Seite UTF-8 kodierte Zeichen hast, dann siehst du immer zwei seltsame Zeichen und kein Fragezeichen.

Komisch daran ist dass das eine Ajax nur mit UTF8 funktioniert aber nicht mit iso und das andere nur mit iso aber nicht mit utf8... Obwohl die aufgerufenen php-skripte eigentlich nicht unterschiedlich sind.

Deine ganzen Schilderungen sind komisch, da sie so nicht sein können. Es gibt aber noch mehr Stellen, wo die Kodierung dir einen Strich durch die Rechnung machen könnte. Dazu müßte man aber das ganze mal sehen.

var url="###formdirection###";
    url=url+"?eID=ajaxsearch";
    url=url+"&ajaxquery="+suchbegriff;
    url=url+"&ajaxcid=###ajaxcid###";
    url=url+"&pagelink=###pagelink###";
    url=url+"&templatefile=###templatefile###";
    url=url+"&sid="+Math.random();

Hast du mal versucht ob auch Umlaute o.ä. übertragen werden? Du musst auch die Parameter eines AJAX Objektes URL kodieren. Am sinnvollsten mit http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#encode_uri_component@title=encodeURIComponent

Umlaute werden übertragen ....

Auch Sonderzeichen wie %/$&?
Ohne Kodierung kann das nicht gut gehen.

Struppi.

[SebastianJu]

Das wiederspricht deinen Schilderungen, wenn du in einer ISO Seite UTF-8 kodierte Zeichen hast, dann siehst du immer zwei seltsame Zeichen und kein Fragezeichen.

Mal sind es Fragezeichen mit so einem schwarzen Viereck mit weißem Fragezeichen und mal 2 komische Zeichen.

Mir ist noch etwas aufgefallen. Ich erzeuge ja bei Abschicken des Formulars per Javascript einen Ajaxrequest der die Tabelle eingeschränkt neu erstellt.

Dabei ist die Tabelle aufgebaut mit den Anfangsbuchstaben und darunter jeweils die passenden Worte dazu.

Jetzt habe ich bemerkt dass die Tabelle erzeugt per normalem Seitenaufbau zwar normal aussieht aber wenn ich das selbe per Ajax mit Ö mache dann funktioniert es nicht ganz korrekt.

Denn wenn ich utf-8 als Codierung für den ajax nehme dann ist der Überschriftenbuchstabe ein Fragezeichen und die Texte bzw passenden Stickwörter sind korrekte Umlaute.

Wenn ich aber iso8859-1 nehme dann ist der Überschriftenbuchstabe korrekt aber nicht mehr die Sonderzeichen im Text.

Also muss da sogar innerhalb eines Requests unterschiedliche Codierung da sein...

Ich denke dass das vielleicht mit den Mysql-Requests zusammenhängt:

$query = "SELECT ucase(SUBSTRING(ABC_Titel,1,1)) as sign from $dbtable where ABC_Titel like \"".$_GET['ajaxquery']."%\" group by sign";

Damit erzeuge ich die Liste der Anfangsbuchstaben. Aus der Spalte ABC_Titel.

Und den restlichen Text hole ich mir mit (wobei $col der jeweilige Buchstabe ist der mit obigem Request geholt wurde):

$query = "SELECT ABC_Titel, ABC_Text1, ABC_Text2 from $dbtable where ucase(SUBSTRING(ABC_Titel,1,1)) ='$col' and ABC_Titel like \"".$_GET['ajaxquery']."%\" order by ABC_Titel";

Eigentlich unnötiger Code was aber daran liegt dass das Ganze im selben Skript abgearbeitet wird wie der normale Seitenaufbau der Tabelle. Also ohne Ajax.

Das heißt für mich dass der einzelne Buchstabe aus der ersten Abfrage anders codiert sein muss als der String aus der zweiten Abfrage. Obwohl aus dem selben Feld. Oder nicht?

Ich glaube nicht dass ich an den allgemeinen Codierungen groß etwas ändern kann weil mein Teil ist eigentlich nur eine Extension. Ein Glossar um genau zu sein. Wie die Datenbanken und restliche Webseitenteile formatiert sind darauf hab ich eigentlich keinen großen Einfluss...

[dedlfix]

Hi!

Denn wenn ich utf-8 als Codierung für den ajax nehme dann ist der Überschriftenbuchstabe ein Fragezeichen und die Texte bzw passenden Stickwörter sind korrekte Umlaute.
Wenn ich aber iso8859-1 nehme dann ist der Überschriftenbuchstabe korrekt aber nicht mehr die Sonderzeichen im Text.

Was heißt "du nimmst"? Entweder deine Daten sind UTF-8-kodiert _und_ du deklarierst das auch so, oder du bekommst ein nicht sinnvolles (oder nur zufällig richtiges) Ergebnis. Wenn du das Replacement Character siehst, dann ist UTF-8 deklariert, aber es kommt keine gültige UTF-8-Bytesequenz sondern zum Beispiel ein einzelnes Zeichen aus dem Bereich 80..FF, was die Nicht-ASCII-Zeichen in ISO-8859 sein können. Der andere Fall ist, dass eine UTF-8-Sequenz kommt, aber ISO-8859-1 deklariert ist. Dann werden die Bytes der Sequenz als je ein Zeichen interpretiert.

Also muss da sogar innerhalb eines Requests unterschiedliche Codierung da sein...

So sieht es aus.

Ich denke dass das vielleicht mit den Mysql-Requests zusammenhängt:

Hast du dich mal informiert, wie es richtig gemacht wird? Beispielsweise da: SELFHTML-Wiki - Zeichencodierung/MySQL.

$query = "SELECT ucase(SUBSTRING(ABC_Titel,1,1)) as sign from $dbtable where ABC_Titel like \"".$_GET['ajaxquery']."%\" group by sign";

Und den Kontextwechsel solltest du auch beachten, wenn du keine SQL-Injection-Lücken haben möchtest.

Das heißt für mich dass der einzelne Buchstabe aus der ersten Abfrage anders codiert sein muss als der String aus der zweiten Abfrage. Obwohl aus dem selben Feld. Oder nicht?

Die Frage ist, an welcher Stelle du das feststellst. Direkt nach dem Auslesen aus dem DBMS oder erst im Browser? Hast du dem DBMS mitgeteilt, in welcher Kodierung du die Daten haben möchtest? Stehen sie korrekt kodiert im DBMS (im phpMyAdmin muss alles richtig angezeigt werden)? Und im weiteren Verlauf: Teilst du dem Browser mit, welche Kodierung er zu erwarten hat?

Ich glaube nicht dass ich an den allgemeinen Codierungen groß etwas ändern kann weil mein Teil ist eigentlich nur eine Extension. Ein Glossar um genau zu sein. Wie die Datenbanken und restliche Webseitenteile formatiert sind darauf hab ich eigentlich keinen großen Einfluss...

Es kommt nicht direkt auf das große Ganze an, weil jedes Request-Response-Paar ein eigenständiges Gebilde darstellt und zwei dieser Paare durchaus jeweils unterschiedliche Kodierungen verwenden können. Wenn du mit anderen Teilen interagierst, musst du natürlich deren Gegebenheiten beachten, wenn du sie nicht umstellen kannst.

Lo!

[SebastianJu]

Was heißt "du nimmst"? Entweder deine Daten sind UTF-8-kodiert _und_ du deklarierst das auch so, oder du bekommst ein nicht sinnvolles (oder nur zufällig richtiges) Ergebnis. Wenn du das Replacement Character siehst, dann ist UTF-8 deklariert, aber es kommt keine gültige UTF-8-Bytesequenz sondern zum Beispiel ein einzelnes Zeichen aus dem Bereich 80..FF, was die Nicht-ASCII-Zeichen in ISO-8859 sein können. Der andere Fall ist, dass eine UTF-8-Sequenz kommt, aber ISO-8859-1 deklariert ist. Dann werden die Bytes der Sequenz als je ein Zeichen interpretiert.

Mit nehmen meinte ich dass ich einen header setze in der php-Datei.

header('Content-type: text/html; charset=utf-8');

Hast du dich mal informiert, wie es richtig gemacht wird? Beispielsweise da: SELFHTML-Wiki - Zeichencodierung/MySQL.

Ich habe mir das mal angesehen und versucht per mysql_set_charset('utf8', $conn); die Verbindung zur Datenbank auf utf8 zu setzen. Ergebnis war die Fehlermeldung:

Ausführen der Abfrage nicht möglich: Illegal mix of collations (latin1_german2_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'like'

was dann wohl zeigt welche Codierung die Datenbank hat. (Mir fehlen im Moment die Zugangsdaten zu phpmyadmin aber bei dieser Codierung bin ich ziemlich sicher dass einfach die Standardcodierung genommen wurde)

Ich kenne jetzt keine Codierung die ich jetzt da für den Header nehmen könnte. Am Liebsten wäre es mir natürlich wenn die Livesuche mit jeder Art von Codierung umgehen könnte. Wäre es zB möglich einen String zu nehmen und per php-Funktion die Codierung zu bestimmen? So dass je nach Ergebnisursprung die richtige Codierung benutzt würde?

Und den Kontextwechsel solltest du auch beachten, wenn du keine SQL-Injection-Lücken haben möchtest.

Ich hab jetzt mysql_real_escape_string() dazu...

Die Frage ist, an welcher Stelle du das feststellst. Direkt nach dem Auslesen aus dem DBMS oder erst im Browser? Hast du dem DBMS mitgeteilt, in welcher Kodierung du die Daten haben möchtest? Stehen sie korrekt kodiert im DBMS (im phpMyAdmin muss alles richtig angezeigt werden)? Und im weiteren Verlauf: Teilst du dem Browser mit, welche Kodierung er zu erwarten hat?

Ich habe jetzt mal den header-tag weggelassen und das Ergebnis sieht genauso aus wie wenn ich utf8 verwendet hätte. Also text ok aber buchstabe nicht. Außerdem scheint irgendwas mit der Interpretation nicht zu stimmen. Denn in utf8 bzw keinem header werden links mit einem umlaut falsch interpretiert. ZB. ~~~html <a href="index.php?id=elektrogeraete" class="internalLink">Elektrogeräte</a><br />

`<a class="internalLink" href="index.php?id=elektroger">Elektroger</a>äte`{:.language-html}  
  
Also sowohl der Link als auch der Anker falsch. Was für ein Thema...  
  

> Es kommt nicht direkt auf das große Ganze an, weil jedes Request-Response-Paar ein eigenständiges Gebilde darstellt und zwei dieser Paare durchaus jeweils unterschiedliche Kodierungen verwenden können. Wenn du mit anderen Teilen interagierst, musst du natürlich deren Gegebenheiten beachten, wenn du sie nicht umstellen kannst.  
  
Klingt nach einer ziemlich undynamischen Sache wenn man das nicht automatisiert auswerten und verarbeiten könnte. Ich hoffe das geht irgendwie... Schließlich wäre es ziemlich nervig wenn man bei einer neuen Implementierung das Ganze wegen anderer Codierung wieder per Hand umstellen müsste.

[dedlfix]

Hi!

Mit nehmen meinte ich dass ich einen header setze in der php-Datei.
header('Content-type: text/html; charset=utf-8');

Das ist nur ein Teil und so wie etwas auf einen Briefumschlag drauf zu schreiben. Der zweite Teil ist, das Zeug auch in den Briefumschlag hinein zu legen oder in deinem Fall, die Daten auch tatsächlich nach UTF-8 zu kodieren (falls sie das noch nicht sind).

Ich habe mir das mal angesehen und versucht per mysql_set_charset('utf8', $conn); die Verbindung zur Datenbank auf utf8 zu setzen. Ergebnis war die Fehlermeldung:
Ausführen der Abfrage nicht möglich: Illegal mix of collations (latin1_german2_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'like'

Ich hatte gerade im Test kein Problem, mit einer UTF-8-kodierten Anfrage (inklusive Umlaut) Daten aus einem latin1_german2_ci-Feld über LIKE abzufragen. Was hast du für Zeichen in deinem LIKE-String gehabt, nur ASCII oder auch Umlaute und dergleichen? Wobei ich eigentlich eine andere Ursache für die Fehlermeldung annehme. Ich weiß nur nicht, welche Situationen zu dieser Meldung führen.

was dann wohl zeigt welche Codierung die Datenbank hat. (Mir fehlen im Moment die Zugangsdaten zu phpmyadmin aber bei dieser Codierung bin ich ziemlich sicher dass einfach die Standardcodierung genommen wurde)

Standard/default wäre latin1_swedish_ci. Die Datenbank-Kodierung ist auch nicht maßgeblich sondern die der einzelnen Felder.

Ich kenne jetzt keine Codierung die ich jetzt da für den Header nehmen könnte. Am Liebsten wäre es mir natürlich wenn die Livesuche mit jeder Art von Codierung umgehen könnte. Wäre es zB möglich einen String zu nehmen und per php-Funktion die Codierung zu bestimmen?

Nein, das geht nicht. Wenn du nicht weißt, was am Ende rauskommen soll, kannst du einen verschlüsselten (was anderes ist kodiert ja nicht) Text nicht dekodieren und dann prüfen, ob das nun das Original oder was anderes ist. Es gibt eventuell Indizien, die auf eine bestimmte Kodierung schließen lassen. Beispielsweise wenn nur gültige UTF-8-Sequenzen vorkommen, kann es sich mit einer gewissen Wahrscheinlichkeit um UTF-8 handeln. Es kann aber auch sein, dass einer "in ISO-8859-1 spricht" und zeigt, wie es aussieht, wenn UTF-8-Sequenzen als ISO gelesen werden.

Ich habe jetzt mal den header-tag weggelassen und das Ergebnis sieht genauso aus wie wenn ich utf8 verwendet hätte. Also text ok aber buchstabe nicht.

Machen wir es mal exakter und nachvollziehbarer. Das was du aus dem DBMS holst, schick mal durch urlencode() und zeig das Ergebnis. (Die Funktion ist zwar nicht zum Anzeigen von Hexwerten vorgesehen, zeigt aber einfacher lesbare Ergebnisse als bin2hex().) Mach das mal für beide Fälle. Abhängig vom Ergebnis kann man dann gezielter weiterüberlegen und mit einer Lösungsfindung fortfahren.

Schließlich wäre es ziemlich nervig wenn man bei einer neuen Implementierung das Ganze wegen anderer Codierung wieder per Hand umstellen müsste.

Deswegen ja die Empfehlung nur eine einzige Kodierung für ein Projekt zu verwenden und das vorzugsweise UTF-8. Wenn du mehrere Kodierungen verwendest, wirst du garantiert immer irgendwo ein Problem bekommen.

Lo!

[SebastianJu]

Ich habe mir das mal angesehen und versucht per mysql_set_charset('utf8', $conn); die Verbindung zur Datenbank auf utf8 zu setzen. Ergebnis war die Fehlermeldung:
Ausführen der Abfrage nicht möglich: Illegal mix of collations (latin1_german2_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'like'

Ich hatte gerade im Test kein Problem, mit einer UTF-8-kodierten Anfrage (inklusive Umlaut) Daten aus einem latin1_german2_ci-Feld über LIKE abzufragen. Was hast du für Zeichen in deinem LIKE-String gehabt, nur ASCII oder auch Umlaute und dergleichen? Wobei ich eigentlich eine andere Ursache für die Fehlermeldung annehme. Ich weiß nur nicht, welche Situationen zu dieser Meldung führen.

In dem Suchfeld hatte ich ö eingegeben und habe dann halt alle einträge mit ö bekommen. Also like "ö%". Aber das erwähnte Linkproblem im Tabellencontent habe ich auch bei L wit Lautsprecher. Da ist auch ein Link zu Elektrogeräte. Der Link ist auch kaputt. Wobei das beim normalen Tabellenaufbau ohne ajax nicht passiert.

was dann wohl zeigt welche Codierung die Datenbank hat. (Mir fehlen im Moment die Zugangsdaten zu phpmyadmin aber bei dieser Codierung bin ich ziemlich sicher dass einfach die Standardcodierung genommen wurde)

Standard/default wäre latin1_swedish_ci. Die Datenbank-Kodierung ist auch nicht maßgeblich sondern die der einzelnen Felder.

Stimmt natürlich. Aber mit der Fehlermeldung denke ich dass die Daten selbst schon als german codiert sind.

Ich kenne jetzt keine Codierung die ich jetzt da für den Header nehmen könnte. Am Liebsten wäre es mir natürlich wenn die Livesuche mit jeder Art von Codierung umgehen könnte. Wäre es zB möglich einen String zu nehmen und per php-Funktion die Codierung zu bestimmen?

Nein, das geht nicht. Wenn du nicht weißt, was am Ende rauskommen soll, kannst du einen verschlüsselten (was anderes ist kodiert ja nicht) Text nicht dekodieren und dann prüfen, ob das nun das Original oder was anderes ist. Es gibt eventuell Indizien, die auf eine bestimmte Kodierung schließen lassen. Beispielsweise wenn nur gültige UTF-8-Sequenzen vorkommen, kann es sich mit einer gewissen Wahrscheinlichkeit um UTF-8 handeln. Es kann aber auch sein, dass einer "in ISO-8859-1 spricht" und zeigt, wie es aussieht, wenn UTF-8-Sequenzen als ISO gelesen werden.

Es wäre vermutlich so einfach wenn es am Anfang jedes Strings ein oder mehrere Codierungszeichen gäbe die einfach den Zeichensatz angeben. Dann bräuchte man sich mit so etwas auch nicht rumschlagen weil alles automatisch erkannt werden könnte.

Ich habe jetzt mal den header-tag weggelassen und das Ergebnis sieht genauso aus wie wenn ich utf8 verwendet hätte. Also text ok aber buchstabe nicht.

Machen wir es mal exakter und nachvollziehbarer. Das was du aus dem DBMS holst, schick mal durch urlencode() und zeig das Ergebnis. (Die Funktion ist zwar nicht zum Anzeigen von Hexwerten vorgesehen, zeigt aber einfacher lesbare Ergebnisse als bin2hex().) Mach das mal für beide Fälle. Abhängig vom Ergebnis kann man dann gezielter weiterüberlegen und mit einer Lösungsfindung fortfahren.

Hab ich gemacht. Das Ergebnis ist:

ABC_Titel%3A+Abbeizer+ABC_Text1%3A+-+station%E4re+Annahmestelle%3A%0D%0A--%3E+Firma+ETG+%0D%0A-+mobile+Problemstoffsammlung%3A+%0D%0A--%3E+Abfuhrtermine%0D%0A+ABC_Text2%3A+Abbeizmittel+geh%F6ren+zur+Gruppe+der+Gef%E4hrlichen+Abf%E4lle+und+d%FCrfen+nicht+im+Hausm%FCll+entsorgt+werden.%0D%0A%0D%0AWeitere+Informationen+siehe+--%3E+Problemabf%E4lle+ABC_Titel%3A+Abflussreiniger+ABC_Text1%3A+-+station%E4re+Annahmestelle%3A%0D%0A--%3E+Firma+ETG++%0D%0A-+mobile+Problemstoffsammlung%3A+%0D%0A--%3E+Abfuhrtermine%0D%0A+ABC_Text2%3A+Haushaltschemikalien+geh%F6ren+zur+Gruppe+der+Gef%E4hrlichen+Abf%E4lle+und+d%FCrfen+nicht+im+Hausm%FCll+entsorgt+werden.%0D%0AWeitere+Informationen+siehe+--%3E+Problemabf%E4lle+ABC_Titel%3A+Allibert+ABC_Text1%3A+--%3E+Hausm%FCllabfuhr%0D%0A--%3E+Sperrm%FCllabfuhr%0D%0A--%3E+Wertstoffzentrum%0D%0A++%0D%0A+ABC_Text2%3A+Badezimmerschr%E4nke+bestehen+haupts%E4chlich+aus+Kunststoff+und+werden+als+Rest-%2FSperrm%FCll+entsorgt.%0D%0ADie+Anlieferung+von+brennbarem+Restm%FCll+im+Wertstoffzentrum+und+im+M%FCllheizkraftwerk+ist+geb%FChrenpflichtig.+ABC_Titel%3A+Altakten+ABC_Text1%3A+--%3E+Firma+Fetzer%0D%0A-+Entsorgungsfirmen%2C+die+%0D%0A++Aktenvernichtung+anbieten.+ABC_Text2%3A+-+Datenschutzpapier+muss+von+++%0D%0A++++++++Spezialfirmen+behandelt+werden.%0D%0A-+Im+M%FCllheizkraftwerk+werden+Akten+%0D%0A++++++++nicht+angenommen.%0D%0A-+Gesetzliche+Grundlage%3A++++++++++Bundesdatenschutzgesetz+%0D%0A+++++und+DIN+32757.%0D%0A-+Geschnetzeltes+Papier+aus+Haushalten%0D%0A++++++kann%2C+separat+verpackt%2C+in+den++++++++++++Wertstoffh%F6fen+und+im+Wertstoffzentrum++++++abgegeben+werden.+ABC_Titel%3A+Altfett+ABC_Text1%3A+--%3E+Wertstoffh%F6fe%0D%0A--%3E+Wertstoffzentrum+ABC_Text2%3A+Fette+bitte+lose+oder+in+Kunststoffgebinden%2C+auf+keinen+Fall+in+Glasbeh%E4ltern+abgeben%21%0D%0A+

Der Code in php dazu ist: ~~~php if(isset($_GET['ajaxquery'])){
$query = "SELECT ABC_Titel, ABC_Text1, ABC_Text2 from $dbtable order by ABC_Titel limit 5";
if (! $rs2 = mysql_query($query)) {
  die("Ausf&uuml;hren der Abfrage nicht m&ouml;glich: ".mysql_error());
}
while ($ar2 = mysql_fetch_assoc($rs2)) {
  echo urlencode('ABC_Titel: '.$ar2['ABC_Titel'].' ABC_Text1: '.$ar2['ABC_Text1'].' ABC_Text2: '.$ar2['ABC_Text2'].' ');
}
exit;

  

> > Schließlich wäre es ziemlich nervig wenn man bei einer neuen Implementierung das Ganze wegen anderer Codierung wieder per Hand umstellen müsste.  
>   
> Deswegen ja die Empfehlung nur eine einzige Kodierung für ein Projekt zu verwenden und das vorzugsweise UTF-8. Wenn du mehrere Kodierungen verwendest, wirst du garantiert immer irgendwo ein Problem bekommen.  
  
Ja nur was tut man wenn man nicht weiß wo es mal eingesetzt wird. Das was ich mache ist zB eine Typo3-Extension. Ob die noch mal woanders eingesetzt wird weiß ich nicht aber grundsätzlich muss es da doch eine Lösung geben. Ansonsten müssten ja beim jeweiligen User der sich die Extension installiert alle Codecs stimmen. Oder zumindest müsste der User einstellen können in welchem Format die Daten in der Datenbank liegen...

[SebastianJu]

Hier wird gemeint dass man nur utf8 mit ajax nutzen sollte. Fehlerursache?

Forumarchiv

[Der Martin]

Hallo,

ABC_Titel%3A+Abbeizer+
ABC_Text1%3A+-+station%E4re+Annahmestelle%3A%0D%0A--%3E+Firma+ETG+%0D%0A-+mobile+Problemstoffsammlung%3A+%0D%0A--%3E+Abfuhrtermine%0D%0A+
ABC_Text2%3A+Abbeizmittel+geh%F6ren+zur+Gruppe+der+Gef%E4hrlichen+Abf%E4lle+und+d%FCrfen+nicht+im+Hausm%FCll+entsorgt+werden.%0D%0A%0D%0AWeitere+Informationen+siehe+--%3E+Problemabf%E4lle+
ABC_Titel%3A+Abflussreiniger+
ABC_Text1%3A+-+station%E4re+Annahmestelle%3A%0D%0A--%3E+Firma+ETG++%0D%0A-+mobile+Problemstoffsammlung%3A+%0D%0A--%3E+Abfuhrtermine%0D%0A+
ABC_Text2%3A+Haushaltschemikalien+geh%F6ren+zur+Gruppe+der+Gef%E4hrlichen+Abf%E4lle+und+d%FCrfen+nicht+im+Hausm%FCll+entsorgt+werden.%0D%0AWeitere+Informationen+siehe+--%3E+Problemabf%E4lle+
ABC_Titel%3A+Allibert+
ABC_Text1%3A+--%3E+Hausm%FCllabfuhr%0D%0A--%3E+Sperrm%FCllabfuhr%0D%0A--%3E+Wertstoffzentrum%0D%0A++%0D%0A+
ABC_Text2%3A+Badezimmerschr%E4nke+bestehen+haupts%E4chlich+aus+Kunststoff+und+werden+als+Rest-%2FSperrm%FCll+entsorgt.%0D%0ADie+Anlieferung+von+brennbarem+Restm%FCll+im+Wertstoffzentrum+und+im+M%FCllheizkraftwerk+ist+geb%FChrenpflichtig.+
ABC_Titel%3A+Altakten+
ABC_Text1%3A+--%3E+Firma+Fetzer%0D%0A-+Entsorgungsfirmen%2C+die+%0D%0A++Aktenvernichtung+anbieten.+
ABC_Text2%3A+-+Datenschutzpapier+muss+von+++%0D%0A++++++++Spezialfirmen+behandelt+werden.%0D%0A-+Im+M%FCllheizkraftwerk+werden+Akten+%0D%0A++++++++nicht+angenommen.%0D%0A-+Gesetzliche+Grundlage%3A++++++++++Bundesdatenschutzgesetz+%0D%0A+++++und+DIN+32757.%0D%0A-+Geschnetzeltes+Papier+aus+Haushalten%0D%0A++++++kann%2C+separat+verpackt%2C+in+den++++++++++++Wertstoffh%F6fen+und+im+Wertstoffzentrum++++++abgegeben+werden.+
ABC_Titel%3A+Altfett+
ABC_Text1%3A+--%3E+Wertstoffh%F6fe%0D%0A--%3E+Wertstoffzentrum+
ABC_Text2%3A+Fette+bitte+lose+oder+in+Kunststoffgebinden%2C+auf+keinen+Fall+in+Glasbeh%E4ltern+abgeben%21%0D%0A+

in dieser Textwurst sind alle Umlaute ISO-8859-x-codiert. Also nix mit UTF-8.
Und jetzt?

So long,
 Martin

[dedlfix]

Hi!

In dem Suchfeld hatte ich ö eingegeben und habe dann halt alle einträge mit ö bekommen. Also like "ö%". Aber das erwähnte Linkproblem im Tabellencontent habe ich auch bei L wit Lautsprecher. Da ist auch ein Link zu Elektrogeräte. Der Link ist auch kaputt. Wobei das beim normalen Tabellenaufbau ohne ajax nicht passiert.

Wenn der Client was anders macht als erwartet, ist das zu betrachten, was beim Client ankommt, um festzustellen, was da im Code falsch ist. Dann erst kann man auf Ursachensuche gehen, nach dem Programmteil, der den Code dafür zusammengebaut hat. Wenn du vermutest, dass die Zeichenkodierung den Browser zu Textverstümmlung veranlasst, lass das was du dem Browser sendest mal durch urlencode() laufen. Oder schalte in der Quellcode-Ansicht die Zeichenkodierung auf ISO-8859-1 oder Windows-1252, dann siehst für jedes Byte ein Zeichen. Bei ungültigen UTF-8-Sequenzen verschluckt sich ein Browser gern mal und dann fehlen ein oder zwei Zeichen von den folgenden.

Standard/default wäre latin1_swedish_ci. Die Datenbank-Kodierung ist auch nicht maßgeblich sondern die der einzelnen Felder.
Stimmt natürlich. Aber mit der Fehlermeldung denke ich dass die Daten selbst schon als german codiert sind.

german2 ist nicht die Kodierung sondern hat mit dem Vergleichen von Zeichen zu tun. Die Kodierung steckt im ersten Teil, also latin1, was bei MySQL Windows-1252 entspricht, einer Abart von ISO-8859-1.

Es wäre vermutlich so einfach wenn es am Anfang jedes Strings ein oder mehrere Codierungszeichen gäbe die einfach den Zeichensatz angeben. Dann bräuchte man sich mit so etwas auch nicht rumschlagen weil alles automatisch erkannt werden könnte.

Ja, aber das hätte man ungefähr zum Zeitpunkt der Computererfindung berücksichtigen müssen. Alles Jammern darüber ist nun zu spät. Die Zukunft lautet Unicode und seine Kodierungen. Wenn man konsequent alle anderen Zeichensätze und ihre Kodierungen aussterben ließe, wäre das Problem auch gelöst. Das wird aber nicht passieren - zumindest nicht auf absehbare Zeit - also werden wir uns insgesamt noch eine Weile mit den Unzulänglichkeiten und Fallstricken rumschlagen dürfen. Und wenn/weil du nicht wenigstens für dein Projekt umsteigen kannst, solltest du dir die Grundlagen der Zeichenkodierung ansehen, die Merkmale von ISO-8859-1 und UTF-8 verstehen, damit du sie und ihre Erscheinungsformen erkennen kannst.

[gekürzt:] station%E4re geh%F6ren Gef%E4hrlichen Abf%E4lle d%FCrfen Hausm%FCll

Du siehst da also, dass deine Umlaute von je einem Byte repräsentiert werden. Und wenn du dir die ISO-8859-1-Tabelle ansiehst, siehst du, dass deine Umlaute ISO-8859-1 entsprechen (= latin1).

Wenn du das nun als UTF-8 deklariert ausgeben willst, musst du das umkodieren: utf8_encode(). Oder du lieferst es als ISO-8859-1 deklariert aus. Wenn du nun in dem auszuliefernden Text auch noch Zeichen in UTF-8-Kodierung hast, wäre also ein utf8_encode() der Datenbankinhalte sinnvoll.

Ja nur was tut man wenn man nicht weiß wo es mal eingesetzt wird. Das was ich mache ist zB eine Typo3-Extension. Ob die noch mal woanders eingesetzt wird weiß ich nicht aber grundsätzlich muss es da doch eine Lösung geben. Ansonsten müssten ja beim jeweiligen User der sich die Extension installiert alle Codecs stimmen. Oder zumindest müsste der User einstellen können in welchem Format die Daten in der Datenbank liegen...

Ich kenne Typo3 nicht. Wenn du dafür was schreiben willst, solltest du dich an dessen Philosophie und Gegebenheiten richten. Ich denke aber nicht, dass du der erste bist, der Zeichenkodierungsprobleme mit Typo3 hat, weswegen du zumindest generische Auskünfte über Typo3s Verhalten diesbezüglich finden dürftest.

Lo!

[SebastianJu]

Danke für die Hilfe... Ich glaube ich habe es jetzt alles richtig...

Die Unterschiede zwischen den einzelnen Buchstaben und dem Tabellentext musste ich darin finden dass die Tabelle in Einzelteilen ausgeliefert wird und ohne dass ich es bemerkt habe ist nur der Contentteil mit utf8_encode ausgeliefert worden. Nachdem das auch für die Überschriften drin war verhielten die sich wieder gleich.

Ich musste für alle Ajaxausgaben utf8_encode angeben. Alle normalen Ausgaben müssen ohne bleiben.

Das nächste waren die kaputten Links. Diese wurden per Regex zu Links umgebaut. Es wurden also Keywords gesucht im Content und daraus Links gemacht. Der pattern funktionierte dabei für die normale Seite aber nicht mehr für Ajax. Damit das auch klappt musste ich den pattern erweitern um die deutschen Umlaute von: $pattern = '/--> (\w+)/'; zu $pattern = '/--> ([\wäÄöÖüÜß]+)/';

Damit klappt es nun mit beiden Versionen korrekt... :)

Danke nochmal für die Hilfe... :)