htmlentities = Notice: Use of undefined constant ENT_DISALLOWED

[mermshaus]

Ja, die Überlegung ergibt leider wenig Sinn, sync2014. Die Charset-Parameter beziehen sich nicht auf das Charset der auszuliefernden HTML-Seite, sondern auf das Charset/Encoding der zu konvertierenden Eingabe ($vstring bei dir).

Der Code, den ich gepostet habe, konvertiert gewissermaßen von UTF-8 nach 7-Bit-ASCII, was die kleinste gemeinsame Untermenge vieler Charsets ist.

Du solltest zumindest im PHP-Code immer in UTF-8 arbeiten und erst dann in das benötigte Ziel-Charset konvertieren, während du die HTML-Ausgabe generierst. Das wird schon schwierig genug. Dann auch noch deinen eigentlichen PHP-Code so zu schreiben, dass er mit Strings in verschiedenen Charsets arbeiten kann, wäre noch mal komplizierter (falls überhaupt irgendwie sinnvoll möglich) und ist zudem eben unnötig.

[sync2014]

Ja, klar mit dem Design. Wollte damit eher sagen das es nicht in meiner Macht steht was die als nächstes vorhaben. Soll ja nur den Spider machen.
Eigentlich hatte ich ja alles fertig und lief auch ohne Einwand. Im Localhost hatte ich nur eine Aktuellere PHP Version als die auf dem Server.

Alternative fällt mir da jetzt nur array und preg_replace ein.

[mermshaus]

Du brauchst eben eine Schnittstelle, die die internen Daten, die wie gesagt in UTF-8 vorliegen sollten, weil das mehr oder weniger der Standard ist, für die Ausgabe dann in eine Form umwandelt, die mit dem Ausgabe-Charset kompatibel ist.

Diese Schnittstelle muss zwei Sachen können:

1. Daten so aufbereiten, dass sie mit dem Charset kompatibel sind.
2. Daten so aufbereiten, dass sie mit dem Charset kompatibel sind und dass dazu noch für HTML syntaktisch relevante Zeichen entsprechend escapet werden.

Wenn du etwas ausgeben möchtest, das HTML enthalten darf, dann Variante 1. Ansonsten Variante 2.

Was du mit Arrays und Regular Expressions meinst, weiß ich gerade nicht.