VB DatagridView HTMLDecode

Status
Dieses Thema wurde gelöst! Zur Lösung gehen…

forum-user

Mitglied
Hallo Gemeinde,
und bitte nicht gleich steinigen, bin in VB nicht so bewandert.
Ich habe ein kleines VB.NET Tool unter meine Finger bekommen, welches ich warten soll :-(

Die Daten ( aus einer MySQL Datenbank) werden per DataSet, ...BindingSource und Table Adapter in einem DataGridView dargestellt. Dies ist alles OK nur wenn in der Datenbank ein Datensatz mit HTML Encode vorhanden ist, wie kann ich diesen im DataGridView korrekt wieder anzeigen.
 

Anhänge

  • Unbenannt.JPG
    Unbenannt.JPG
    11,3 KB · Aufrufe: 0
Was ich mich frage ob das überhaupt so schon richtig ist das dort die html entities reinkommen ???
(ich würds zumindest mal bei euch im Haus intern abprüfen)

Ansosnten finde ich folgenden Ansatz nicht schlecht.
is there a mysql function to decode html entities?
(die Antwort mit der numerics Methode)
Sprich eine entsprechende MySql Methode erstellen und dann den Select Aufruf hin anpassen.

Selbst nicht getestet, aber die Lösung dies eventuell über MySQL abzuhändeln finde ich nicht schlecht.
 
Moin Spyke,
die Entities werden durch ein öffentliches WEB Interface in die Datenbank geschrieben. Ich hab gelesen das VB die Möglichkeit hat mit HTMLencode und... decode. Doch wie kann ich dies an dem DataSet und co anwenden.

Klar könnte ich auch eine eigene Abfrage erstellen und per DataReader (?!) HTMLDecode anwenden und ein eigenen GridView aufbauen, doch wüsste ich dann nicht, wie ich die jeweiligen Spalten/Zeilen bearbeiten könnte, wenn der Anwender drauf klickt.
 
Was ich mich frage ob das überhaupt so schon richtig ist das dort die html entities reinkommen ???
(ich würds zumindest mal bei euch im Haus intern abprüfen)
Dies genau! Der Datenbankinhalt ist schon an sich falsch abgespeichert. Ihr solltet die DB dahingehend bereinigen und das Webtool überarbeiten, dass es den rohen (und nicht HTML-kodierten) Text einspeichert.
 
Dies genau! Der Datenbankinhalt ist schon an sich falsch abgespeichert. Ihr solltet die DB dahingehend bereinigen und das Webtool überarbeiten, dass es den rohen (und nicht HTML-kodierten) Text einspeichert.

Ich hatte mal gelernt das man nicht alles was aus dem WEB kommt, unkontrolliert in die DB geschrieben werden soll. Drum fast immer ....
PHP:
$inhalt = htmlentities($inhalt, ENT_QUOTES, "UTF-8");

Nun soll aber dieses Vb Tool auf genau diese Datenbank zugreifen.
Ich bin gern bereit, neues zu lernen, drum kann man mit mir über andere Ansätze reden. :)
 
Ich hatte mal gelernt das man nicht alles was aus dem WEB kommt, unkontrolliert in die DB geschrieben werden soll. Drum fast immer ....
Hi,

an sich die richtige Einstellung, nur falsch umgesetzt.

Du merkst das Problem mit den HTML-Entities ja gerade selber. Mit der Aussage (nichts unkontrolliert in die DB) ist gemeint, dass die Daten gesichert sein müssen. Hierbei allerdings nicht für das Ausgabemedium, sondern für die Datenbank (mysqli_real_escape_string, PDO etc.).
Die Daten selbst sollten unverändert in der Datenbank liegen. Warum? Weil nicht immer sicher gestellt ist, wie die Daten ausgelesen und angezeigt werden sollen. Wenn du die Daten auf einer Webseite anzeigen willst, so musst du das HTML escapen. Willst du die Daten in eine andere Datenbank übertragen, so musst du diese SQL Escapen. Das gleiche gilt für XML und noch einige andere auch.
In deinem Fall musst du die Daten gar nicht escapen, da du mit VB nicht aus dem Kontext "ausbrechen" kannst. Er kann die Daten 1:1 anzeigen ohne Probleme.

Von daher: Die Daten niemals irgendwie escaped in der Datenbank ablegen, sondern lediglich das SQL zum Einfügen absichern (PDO). Sonst bekommst du früher oder später eben jenes Problem das du gerade hast.

Ich hoffe ich konnte mich richtig ausdrücken.

Grüsse,
BK
 
Ergänzenz zu dem von Bratkartoffel kann ich dir noch einen Beitrag von mir, den ich vor ein paar Wochen verfasst habe, empfehlen: Seite besser absichern

Um die DB zu bereinigen, solltest du das Maskieren von PHP via html_entity_decode wieder rückgängig machen:
PHP:
for ($row in $table) {
  $row['text_column'] = html_entity_decode($row['text_column'], ENT_QUOTES, 'UTF-8');
  // write $row back into DB
}
Wichtig: Das Skript sollte atomar laufen, es sollte kein anderes Skript oder anderes SQL-Query dazwischenfunken. Außerdem musst du fortan bei jeder Ausgabe der Textspalte in einem HTML-Kontext (!)htmlentities aufrufen.

(Theoretisch funktioniert auch jede andere Programmiersprache/HTML-Library für den Zweck des Rückgängigmachens. Mein Bauchgefühl sagt mir nur, dass es wohl empfehlenswert ist, dieselbe Library (also htmlentities & html_entity_decode) zu nutzen, welche man auch am Anfang genutzt hat.)
 
Hi,

...

Von daher: Die Daten niemals irgendwie escaped in der Datenbank ablegen, sondern lediglich das SQL zum Einfügen absichern (PDO). Sonst bekommst du früher oder später eben jenes Problem das du gerade hast.

Ich hoffe ich konnte mich richtig ausdrücken.

Grüsse,
BK
Hallo Bratkartoffel und Comfreee, erst einmal ein Gesundes Euch allen.

Für mich noch einmal kurz zum Verständnis, damit nichts falsch interpretiert wird von mir :)
im PHP Script lasse ich sämtliche Inputs per trim und htmlentities bereinigen und konvertieren.
Danach folgt via PDO ein prepared Statement...
PHP:
$InputVal = htmlentities( trim( $_POST['InputVal'] ) , ENT_QUOTES);

$stmt = $this->db->prepare('INSERT INTO MEINETABELLE
                          (name, ....)
                           VALUES(:name, ...)');
$stmt->execute(array(':name' => $InputVal,));

Somit bin ich im Bezug auf PHP/MySQL immer gut gefahren, bis ich mit VB zu tun hatte.
Klar für mich ist es, dass in der DB der Datensatz HTML enthält.

Nun bin ich mir jedoch nicht sicher, wenn ich htmlentities nicht anwende, dass prepared Statements zur Sicherheit ausreichen, bzw. wo habe ich meinen gedanklichen Klemmer.
 
Somit bin ich im Bezug auf PHP/MySQL immer gut gefahren, bis ich mit VB zu tun hatte.
Das hat nicht zwingend was mit VB zu tun. Was, wenn du jemals deine DB-Inhalte in JSON ausgeben wolltest? Oder in XML? In beiden Fällen müsstest du erst dekodieren.

Nun bin ich mir jedoch nicht sicher, wenn ich htmlentities nicht anwende, dass prepared Statements zur Sicherheit ausreichen, bzw. wo habe ich meinen gedanklichen Klemmer.
Warum sollte es nicht ausreichen? Prepared Statements sind per Zusicherung der API sicher - bei richtiger Anwendung. Wo du deinen Klemmer hast, musst du uns erzählen :)

Hast du meinen Beitrag gelesen?
 
Das hat nicht zwingend was mit VB zu tun. Was, wenn du jemals deine DB-Inhalte in JSON ausgeben wolltest? Oder in XML? In beiden Fällen müsstest du erst dekodieren.
Dies Thema ist und war mir bewusst. Dekodieren war schon immer automatisch in den ToDo Listen bei mir :unsure:

Prepared Statements sind per Zusicherung der API sicher - bei richtiger Anwendung
Ich dachte das es wie von mir hier schon dargestellt ausreicht. Da auch gerade mein Klemmer
 
Zuletzt bearbeitet:
Status
Dieses Thema wurde gelöst! Zur Lösung gehen…
Zurück