Meine Herren!
Die Seite war nur ein Beispiel, der Inhalt ändert sich ja über die Stunden...Hier ist jetzt noch der oben zitierte Text mit den Fragezeichen.
Du wechselst ständig zwischen den beiden Beispielen, zum aller letzen mal: Die Beispiele zeigen unterschiedliche Verhalten, die unterschiedlich behandelt werden müssen.
Plötzlich sind wir wieder beim ersten Beispiel, aber immerhin den Text gibt es auf der Seite.
Was ich nicht verstehe ist, wieso eine Seite, die in utf8 deklariert ist, Nicht-Utf_8 enthält
Diese Seite »IST« utf8-kodiert. Sie enthält einige Zeichen-Referenzen, die man sich hätte sparen können. Obendrauf fehlt das abschließende Semikolon für die Zeichenreferenz „. Die meisten HTML5-Parser sind so tolerant und verzeihen diesen Fehler.
und was man dann als "Auslesender" am geschicktesten macht, um gegen solche Zeichen "Ausreißer" gefeit zu sein.
Es gibt das Problem mit der fehlerhaften Zeichen-Referenz. Dagegen kannst du höchstens einen genauso toleranten HTML5-Parser einsetzen, wie die der aktuellen Browser. Ob es den für PHP gibt, weiß ich nicht. Aber ich denke dieser Fehler fällt nicht all zu schwer ins Gewicht. Es ist ein Fehler von SR-online, nicht von dir, der sich hoffentlich nicht sehr häufig wiederholen wird. Ich würde ihn ignorieren.
Einen ANDERER, viel schwerwiegenderer Fehler ist, dass du immer noch zu glauben scheinst, die Quelle sei NICHT UTF8-kodierst, »IST« sie aber. Das »IST« UTF8. Die Seite wird korrekt UTF8-kodiert ausgeliefert. Ich hoffe das war deutlich. DU machst ein utf8_DEcode. »DE«code. Und lieferst es dann wieder MIT UTF8 aus. Der Fehler liegt bei dir.
In dem zweite Beispiel ist das utf8_decode von dir richtig angewandt, weil die Eingaben-Daten dort offensichtlich falsch sind.
PS: Bitte fühle dich nicht angeschrien, die Großschreibung soll nur die wichtigen Punkte hervorheben, weil du da bis jetzt offensichtlich zu schluderich drüber gelesen hast.
“All right, then, I'll go to hell.” – Huck Finn