✔ Ausgabe von Variablen OHNE html parsing.

P

penalizer

Mitglied
Hallo liebes Forum,

ich habe leider derzeit ein Problem welches mir bisher noch nicht untergekommen ist...
Ich arbeite gerade an einer "suchen und ersetzen" Funktionalität für HTML Quelltext welcher sich in einer MYSQL-Datenbank befindet.

Der Ablauf ist wie folgt: Eingabe des Such-Strings, Anzeigen der Treffer, Auswahl der Treffer, Ändern der Auswahl.

Aus diesem Grund muss der Suchstring über mehrere Instanzen transportiert werden.

Wenn ich jetzt nach einem Umlaut suche, welcher im HTML-Format in der DB hinterlegt ist, wird dieser Umlaut in der nächsten Instanz in einem hidden Input "zwischengelagert".

In der 3.ten Instanz wird aus dem "Ö" selbstständig ein "Ö".

Nach mehreren Testversuchen habe ich herausgefunden, dass wenn man einen Umlaut per Tastatur in bspw. einem Input einträgt, der HTML Code nicht geparst wird, wenn er allerdings bereits im value als Quellcode hinterlegt wurde (bspw. per echo ausgegeben wurde), wird das "Ö" geparst obwohl es zuvor ebenfalls als "Ö" eingetragen war.

Hier ein Beispiel:

PHP: 
<form action="" method="post" >
<textarea name="test"></textarea>
<textarea name="test2">&Ouml;</textarea><br />

<textarea name="test3" readonly="readonly"><?php echo $_POST["test"]; ?></textarea>
<textarea name="test4" readonly="readonly"><?php echo $_POST["test2"]; ?></textarea>
<input type="submit" />
</form>

Gibt man nun in der Textbox "test" den selben Value "&Ouml;" von "test2" per Tastatur ein und schickt das Formular ab, erscheint anschließend in der Quelltextansicht des Browsers Eurer Wahl der Text in "test3" als "&Ouml;" während er in "test4" als "Ö" ausgegeben wird.

Wenn ich nun ein Umlaut über mehrere Instanzen übergeben möchte, geht dieses Umlaut verloren...

Was kann ich tun? Hat jemand ne Idee?
Vielen Dank im voraus.
 
Zuletzt bearbeitet:
PHP: 
$var = "&Ouml;";
//Das schreibt Ö in $var und nicht  &Ouml;
$var = html_entity_decode($var);
var_dump($var);

//Das schreibt &Ouml; in $var und nicht  Ö
$var = htmlentities($var);
var_dump($var);
Die Unterschiede in diesem Testscript sieht man, wenn man die generierte Source im Browser betrachtet, nicht die generierte Seite....
 
penalizer hat gesagt.:
erscheint anschließend in der Quelltextansicht des Browsers Eurer Wahl der Text in "test3" als "&Ouml;" während er in "test4" als "Ö" ausgegeben wird.
Zum Vergrößern anklicken....

Hallo Yaslaw,
vielen DAnk für deine Antwort.
Wie oben zu sehen ist, gehe ich schon von der Quelltextansicht aus.
Auch deine genannten Funktionen sind mir bekannt. Allerdings nützen diese nichts wenn man sowohl nach "Ö" also auch nach "&Ouml;" suchen möchte.

Ich kann leider nicht immer von einem Case ausgehen sondern muss beide berücksichtigen. Aus diesem Grunde benötige ich den "realen" String und das über mehrere POST instanzen.
 
Sorry, ich sehe dein Problem nicht.

Wechsle immer alle Strings mit htmlentities()und auch die Suchbegriffe mit htmlentities() parsen und schon hast du durchgehend die html-Texte.

Also immer mit &Ouml; arbeiten.
 
Das wäre ein Workaround und nicht die Lösung des Problems.
Gehen wir jetzt einfach mal davon aus wie es ist und nicht wie es sein sollte.
 
Falsch herum gedacht.
Das wäre kein Workaround, sondern eine saubere Lösung. Was du willst ist das Bestehende auf biegen und brechen beizubehalten - mit einem Workaround.

Nun, da ich aber deine Sachlage irgendwie immer noch nicht verstanden habe, hoffe ich dass jemand anderes einen besseren Durchblick hat und dir da weiterhelfen kann.
 
Falsch, ich möchte lediglich auf die "Ist" und nicht die "Könnte" Situation reagieren und nicht eine 35 MB große Datenbank auf validen HTML parsen. Dafür bräuchte ich keinen Thread eröffnen.

Die Sachlage ist im übrigen gut nachzuvollziehen wenn man den Quelltext von oben in ein Dokument Kopiert, in das erste Textfeld per Tastatur "&Ouml;" einträgt, den Absenden Button drückt, sich anschließend den Quelltext anschaut und test3 mit test4 vergleicht. ;)
 
Ich nochmal.
Für alle die ebenfalls vor diesem merkwürdigen Problem stehen :)
Erklärung(sversuch).
Die Quelltextausgabe des Browsers ist bei der Verwendung des geänderten Values nur bedingt zu gebrauchen. Während der Quelltext noch das SpecialChar im Value anzeigt, wird es in der optischen Ausgabe schon als unicode umgerechnet. Somit wird beim absenden des values "&Ouml;" ein "Ö" während die Eigabe per Hand nicht aus dem Quelltext "vorgerendert" wird.

Möchte man dies umgehen, kann man bspw. mit Javascript die einhaltung des Special Chars "erzwingen" indem man den value am ende des Quelltextes neu bestückt:

PHP: 
<form action="" method="post" >
<textarea name="test"></textarea>
<textarea name="test2">&Ouml;l</textarea><br />
<textarea name="test3" id="test3" readonly="readonly"></textarea>

<input type="submit" />
</form>
<script language="javascript">
document.getElementById('test3').value="<?php echo $_POST["test"]; ?>";
//alert(document.getElementById('test3').value);
</script>

Vielen Dank und bis dann.
 
Alles was du bisher geschrieben hast, klingt sehr abenteuerlich. Vor allem die Schlussfolgerung, das etwas vom Renderer umgerechnet wird.

1. HTMLEntities (oder auch HTMLSpecialChars, wie du willst), wurden eingeführt, weil ASCII aufgrund der Beschränkung von 7 Bit unfähig ist, verschiedene Sprach-Spezifika wie die deutschen Umlaute darzustellen. Mit Hilfe des Workarrounds &xxxx; kann nun trotz 7-Bit-Beschränkung alle möglichen zusätzlichen Zeichen dargestellt werden, sofern der Browser die Entity versteht und einen Font findet, der die Entity beinhaltet.

2. Mit Hilfe der ISO-Codepages (ISO-8859-xx) wurde die 7-Bit- auf eine 8-Bit-Beschränkung angehoben, wodurch einer Zeichensatz-Tabelle nun zusätzliche 128 Zeichen hinzugefügt werden konnten. Das bedeutet aber, das man dennoch mehrere ISO-Codepages benötigt, um bspw. alle Europäischen Sprachen darstellen zu können. Bislang gibt es nach meinem letzten Kenntnisstand 16 ISO-Codepages, um das abzudecken.

3. UTF-8 macht aus den 8-Bit 16-Bit, und hebt damit quasi die Beschränkung komplett auf, mehrere Codepages unterstützen zu müssen. Für einen Entwickler sollte es das Ziel sein, diesen Standard zu unterstützen, da er auf lange Sicht die einfachste Methode ist, mehrere Sprach-Spezifika, die aus dem ASCII-Bereich hinausfallen, zu implementieren. Dadurch fallen auch so Krämpfe wie die Übergangslösung HTML-Entities hinten runter, dies wird nicht mehr benötigt. Voraussetzung ist eine Unicode-Unterstützung im Browser, im Betriebssystem und natürlich Fonts, die das unterstützen.

4. Der Browser entscheidet anhand von 2 Kriterien, welchen Zeichensatz er darstellen soll:
- Die Webseite teilt ihm mit, in welcher Codepage der Browser rendern soll.
- Die Webseite teilt nicht mit, der Browser nimmt seine Standard-Einstellung. Firefox verwendet als Standard glaub ich ISO-8859-1 (Westeuropäisch), IE nimmt IMHO eine Windows-Codepage CP1252. Das kann natürlich abhängig von der Sprache des Betriebssystems sein - also in welcher Codepage das OS normalerweise arbeitet.

5. Der Browser rechnet HTML-Entitäten nicht in Unicode um, er sucht ihn seiner Tabelle (welche standardisiert sein sollte) nach dem Index des Zeichens in der eingestellen Standard-Codepage oder der vom Webserver mitgeteilten.


Unterstellung: Du willst also langfristig von dieser Krücke weg, HTML-Entitäten zu unterstützen hin zu Unicode. Falls dem wirklich so ist, solltest du dir die Funktionen

- utf8_encode
- utf8_decode
- html_entity_decode
- header (für Content-Type und Charset)
- HTML-Meta-Tags für die Angabe von Ausgabe-Typ (Content-Type) und Zeichensatz (Charset)

ansehen. Auf lange Sicht wirds dein Programmierer-Leben nur vereinfachen.
 
Hallo Saftmeister,

vielen Dank für deine ausführliche Beschreibung der Zeichensätze welche ich mir aufmerksam durchgelesen habe.

So abenteuerlich mein Problem auch klingen mag und so wenig ich im Stande bin mich richtig auszudrücken :) ist, wie gesagt dieses Problem sehr einfach zu rekonstruieren indem man meine o.g. Anleitung einfach mal nachspielt.

Wie man diese Problematik löst haben wir jetzt bereits auf mehreren Wegen beschrieben. Yaslaw hat auch darauf hingewiesen wie es grundsätzlich sein sollte. Da es in der Praxis aber nunmal nicht immer optimal läuft, habe ich auch meinen Lösungsansatz gepostet.

Was jetzt tatsächlich noch fehlt ist eine Rekonstruktion des Problems von einen Fachmann der auch die richtigen Worte findet ;)

Aber anscheinend kann dieses Problem keiner rekonstruieren, was zum einen daran liegen könnte, dass das o.g. Script nicht rekonstruiert wurde.

Bitte versteht mich nicht falsch. Aber du hast ziemlich viel Energie darauf verwendet einen coolen Text zu schreiben, welcher sich aber nicht auf das eigentliche Grundproblem bezieht. (Trotzdem war er aber sehr informativ).

Es ist natürlich niemand gezwungen sich damit zu befassen und für mich ist es primär auch nicht mehr wichtig, da ich die Lösungen ja habe. Wer sich aber dennoch mal dem o.g. Problem zuwenden möchte um das Phänomen zu rekonstruieren kann dies der Vollständigkeitshalber natürlich gerne tun ;)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück