Korrektur meines vorherigen Postings

[dedlfix]

Tach!

Wenn ich anschließend den Inhalt von $node2->nodeValue mit var_dump ausgebe, kommt schon Umlaut-Müll heraus.

Beim Ausgeben findet wieder eine Interpretation statt, denn das ausgebende System muss ja aus den Daten entnehmen, welche Zeichen es auf die Ausgabe zu schreiben hat. Deswegen ist es bei Kodierungsproblemen ratsam, auch diese Fehlerquelle auszuschließen. Das kann man tun, indem man sich nicht das Ergebnis der (Fehl)interpretation sondern erstmal die Daten selbst anschaut. Nimm echo urlencode() und lass das var_dump() in dem Fall mal weg. Das nimmst du gleich nach dem file_get_contents().

Die DOMDocument-Geschichte will mit UTF-8 arbeiten. Dessen Ergebnis ist auch UTF-8. Anschauen was da rauskommt, wieder mit echo urlencode(). Wenn du Problemb%C3%A4r siehst, dann ist das auf den ersten Blick UTF-8 (wegen der zwei Bytes C3 und A4 für den Umlaut). Ein Blick in eine Zeichenkodierungstabelle offenbart, dass das ein ä ist. Bei Problemb%E4r kann es kein UTF-8 sein. Abkürzenderweise kann man hierzulande als Faustregel bei 2 Byte davon ausgehen, dass es UTF-8 ist, bei nur einem ist es höchstwahrscheinlich ISO-8859-1. I Zweifelsfall dochmal eine Zeichenkodierungstabelle bemühen.

Klar. Weil deine Header-Daten sagen "ich bin UTF-8" und die Daten unter http://www.sr....html offensichtlich nicht UTF-8 sind.

Doch, sind sie. Aber ohne geeignetes Debugging wird man wohl nicht feststellen, wo der Hund begraben ist.

Das Eingabeformat findest du, wie dedlfix sagte, im http-Header (dazu musst du die Inhalte allerdings anders anfordern, file_get_contents ist da ungenügend, da dass nur die Antwort, nicht aber den Antwort-Header liefert) falls du es automatisch auslesen lassen willst (was sicher die nachhaltig gesehen bessere Variante ist), [...]

Allein ist es ungenügend, ja. Aber die Header eines file_get_content('http(s)://...')-Aufrufs stehen in $http_response_header zur Verfügung.

dedlfix.