Html tags in htmlentities ignorieren?

Hi leute gibt es eine einfachere methode NUR texte mit htmlentities zu prüfen und nicht die html tags? bis jetzt habe ich das immer so gemacht:

$vars = array('Ü', 'Ä', 'Ö','ü'....);
    $values = array('©', 'Ü', 'ü','Ä',...);
    return str_replace($vars, $values,$tpl);

und musste so ziemlich viele zeichen manuell eingeben und dann je nach charset die auch verändern. htmlentities kann das ja schon problem ist aber dabei dass es auch html tags umwandelt. habe mir überlegt dass in einem text alle < > / durch platzhalter ersetze dann den text mit htmlentities umwandle und platzhalter wieder mit < > / fülle. oder gibt es da eine bessere methode?

MFG

Lass doch htmlentities() drüber laufen und stell anschließend mit htmlspecialchars_decode() die html-Tags wieder her.

vielmehr solltest du dich mit der frage beschäftigen warum du die umlaute überhaupt in die entities wandeln möchtest

Original von Redrick

vielmehr solltest du dich mit der frage beschäftigen warum du die umlaute überhaupt in die entities wandeln möchtest

damit mein code servereinstellung unabhängig ist. weil als beispiel ich kann bei mir local ohne probleme umlaute darstellen, lade ich die page auf mein webspace stehen dann dort komische zeichen oder vierecke mit fragezeichen drin. wenn die umlaute aber ü als quellcode stehen ist das kein problem.

@klaus danke werde es mal probieren

Google:

http://www.google.de/search?hl=de&q=Header+Content-Type+Encoding&meta=&aq=f&oq=

Original von TheUndeadable

Google:

http://www.google.de/search?hl=de&q=Header+Content-Type+Encoding&meta=&aq=f&oq=

:D ich wusste ja was ich verwenden soll nur halt kannte ich die funktion htmlspecialchars_decode nicht daran lags. aber mit dieser funktion ist nun alles super und lauft wie ich es will

MFG

Das war auch nur als Notlösung gedacht. Von vornerein die richtige Einstellung zu verwenden ist deutlich sinnvoller.

Original von Klaus

Von vornerein die richtige Einstellung zu verwenden ist deutlich sinnvoller.

verstehe ich nicht. meinste am anfang den richtigen charset setzen?

utf-8 for the win

undeadable hatte die schon die richtung hingewiesen, für den anfänger ist der link jedoch mehr schlecht als recht.

davon unabhängig: ich behaupte mal dein problem mit dem darstellungsunterschied beruht in erster linie an der fehlenden charset einstellung sowie der damit zusammenhängenden encoding-einstellung bei der speicherung der html/php-dateien.

als erstes solltest du den enstprechenden Meta-tag verwenden

desweiteren solltest du alle deine php/html dateien in UTF-8 ablegen. Sehr wichtig dabei: einige Programme wie zb. dreamweaver haben die pption einen sog. BOM (Byte Order Mark) mitzuspeichern. Das solltest du bei PHP-dateien besser nicht machen.

du wirst dich wundern, wie schnell dein entitieproblem danach der vergangenheit angehört

Wobei PHP und UTF-8 noch ein Thema für sich ist...

Mit PHP 6 wird alles besser!

Solange die PHP-Dateien selber keine Strings mit Umlauten enthalten - Frage: Warum sollten sie??? - braucht die PHP-Datei selber nicht in UTF8 gespeichert werden. Schadet sicher nicht, es dennoch zu tun, wenn man weiß (siehe letzten Post von TheUndeadable) was man tut.

Nun, allgemein sollte man sich den BOM-Marker auf Unixsystemen sparen - er ist schlicht überflüssig und führt oft zu Problemen.

Das von uns verwendete SBCL (Steel Bank Common Lisp) verweigert sogar den Dienst wenn eine Datei mit BOM-Marker eingelesen wird ;)
EDIT:

Nachdem ich davon ausgehe, das BlackScorp Windows als Dev-OS nutzt empfehle ich notepad++ als Editor

Nie wieder ein Problem mit lästigen BOM-Markern oder ANSI - aber konsequenterweise sollte alles an einem Programm in einer einzigen Codierung geschrieben sein.
Spätestens bei der Internationalisierung kackt ANSI oder ISO Kodierung ab...

das problem ist  dass die texte nicht in einer php datei stehen sondern sobald die aus der datenbank ausgelesen werden, kriegen die so komische zeichen egal ob ich am anfang meta tag auf utf8 setze oder nicht. ich müsste dafür dann eigentlich die datenbank auf utf-8 setzte oder?

PHP hat bis 5.2 (oder 5.3, ehrlich gesagt kA) ein Problem mit dem BOM-Byte. Selbstverständlich soll es nicht rein, aber es gibt stupide Editoren, denen das egal ist. Vor allem bei größeren Teams kann es passieren, dass der falsche die Datei anlegt.. und dann knallt's.

BlackScrop: Weißt du, was du tust? :) Ein String (de facto reden wir davon) ist in einem bestimmten Charset erstellt worden (nehmen wir es Wort bei Wort, es ist logisch). Du musst nur dafür sorgen, dass die Charsets matchen.. also, Beispiele

* Datenbank hat ISO-XY-Inhalte, PHP ist ANSI und Ein/Ausgabe ist UTF8. Alle Daten, die in die DB gehen müssen decoded werden, Ausgaben encoded werden (aus der Perspektive von UTF8).

* Datenbank hat UTF8, PHP ist ANSI, Ein-Ausgabe ist ISO-11. Alle Daten, die in DB gehen müssen encoded werden, die Ausgaben decoded.

* Idealerweise Fall 3: Ein-/Ausgabe UTF8, Datenbank UTF8, PHP (eigentlich schnurzpiepegal): Wenn man von einer integeren Datenbank ausgeht, schreibt man gesicherte UTF-8-Daten aus und liest nur noch aus; alternativ gibt man die Daten aus der Datenbank auch noch gesichert aus. Gesichert, d.h. man prüft explizit, ob der String in UTF-8 angelegt wurde (wenn nicht, encoden). 

also müsste ich dann befor ich ein string in eine db abspeichere, den string mit utf8_encode() überarbeiten. und dann wieder beim lesen aus der datenbank vor der ausgabe in php mit utf8_decode() überarbeiten? richtig?

Wenn all deine Html-Webseiten den Meta-Tag bzw den Header enthalten, brauchst du gar nichts zu tun:

1. Der Browser sendet die Form-Inhalte im UTF-8-Format

2. PHP leitet diese an die Datenbank weiter

3. Die Db speichert die Daten im UTF-8-Format

4. Liest du die Daten wieder aus, so erhält sie PHP wieder im UTF-8-Format

5. Die Website selbst zeigt die Texte korrekt im UTF-8-Format an [Das klassische Html-Encoding zum Schutz vor XSS natürlich einbinden]

PHP selbst bekommt vom UTF-8 kaum was mit (wenn man Kleinigkeit vernachlässigt, dass nahezu sämtliche String-Routinen bei Textverarbeitungen versagen werden).

Das Problem sind Altlasten in der Datenbank, die noch im ISO 8859-1 bzw ISO 8859-15-Format gespeichert sind. Diese musst du konvertieren.