Warum hat echo kein Wert?

[Bernd]

Hallo,

wenn ich folgendes im phpMyAdmin ausführe erhalte ich einen Eintrag

$stmt1 = $mysqli->prepare("SELECT firma FROM kalender_erweitertedaten WHERE ked_kalenderID=?");
$stmt1->bind_param("s", $code);
$stmt1->execute();
$stmt1->bind_result($firma);
$stmt1->fetch();
$stmt1->close();

Zeige Datensätze 0 - 0 ( 1 insgesamt, Die Abfrage dauerte 0.0005 Sekunden)

Wenn ich mir auf der Webseite

<input type="text" name="firma" id="firma" value="<?php echo htmlspecialchars($firma);?>">

dieses ausgeben lassen möchte erhalt ich keinen Wert. Was passiert da?

[dedlfix]

Tach!

Was passiert da?

Debugging ist der erste Schritt, wie schon so oft gesagt. Steht der gewünschte Wert in $firma direkt nach der Abfrage? Was zeigt var_dump($firma) sowohl dort als auch an der fraglichen Stelle? Verfolge den Weg der Variablen durch das Programm, ebenfalls mit var_dump(). Wo geht er verloren?

dedlfix.

[Linuchs]

phpMyAdmin dürfte unabhängig sein von deiner Webseite. Woher soll die Webseite wissen, was du anderswo treibst?

Wie ist denn das SQL Kommando in deiner Webseite?

[TS]

Hello,

Hallo,

wenn ich folgendes im phpMyAdmin ausführe erhalte ich einen Eintrag

$stmt1 = $mysqli->prepare("SELECT firma FROM kalender_erweitertedaten WHERE ked_kalenderID=?");
$stmt1->bind_param("s", $code);
$stmt1->execute();
$stmt1->bind_result($firma);
$stmt1->fetch();
$stmt1->close();

Zeige Datensätze 0 - 0 ( 1 insgesamt, Die Abfrage dauerte 0.0005 Sekunden)

Wenn ich mir auf der Webseite

<input type="text" name="firma" id="firma" value="<?php echo htmlspecialchars($firma);?>">

dieses ausgeben lassen möchte erhalt ich keinen Wert. Was passiert da?

Sofern die Datenbankabfrage überhaupt etwas liefert, könnte das am htmlspecialchars() liegen. Das findet keine gültige Kodierungsangabe.

Entweder Du benutzt das zweite und dritte Funktionsargument von htmlspecialchars() dafür, oder Du setzt die Kodierung skriptglobal mit der Funktion ini_set() mit default_charset
.

Alternative:

Ich benutze die Funktion mb_internal_encoding() im Kopf meines Skeleton-Files für PHP-Skripte. Der wird immer included. Da kann ich es nicht vergessen. Damit funktioniert es.

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Sofern die Datenbankabfrage überhaupt etwas liefert, könnte das am htmlspecialchars() liegen. Das findet keine gültige Kodierungsangabe.

Das halte ich für sehr unwahrscheinlich, solange man den Wert für default_charset nicht willentlich kaputtmacht. Und selbst wenn, kann ich mir grad nur vorstellen, dass lediglich die Übersetzungstabelle nicht gefunden wird, und der Inhalt einfach unverändert durchläuft. Hast du da irgendwelche konkreten gegenteiligen Erfahrungen gemacht?

Jedenfalls käme man dem Fall auch mit Debugging und Kontrollausgabe auf die Spur. Es müsste ja vorher Inhalt zu sehen sein, der bei der Ausgabe verlorenginge.

Entweder Du benutzt das zweite Funktionsargument von htmlspecialchars() dafür, oder Du setzt die Kodierung skriptglobal mit der Funktion (...)

Das zweite ist $flags, das dritte wäre $encoding.

dedlfix.

[TS]

Hello,

Tach!

Sofern die Datenbankabfrage überhaupt etwas liefert, könnte das am htmlspecialchars() liegen. Das findet keine gültige Kodierungsangabe.

Das halte ich für sehr unwahrscheinlich, solange man den Wert für default_charset nicht willentlich kaputtmacht. Und selbst wenn, kann ich mir grad nur vorstellen, dass lediglich die Übersetzungstabelle nicht gefunden wird, und der Inhalt einfach unverändert durchläuft. Hast du da irgendwelche konkreten gegenteiligen Erfahrungen gemacht?

Ja. Das lief hier auch schon öfter durch das Forum, nachdem ich die Ursache festgestellt hatte. Und auch z. B. hier nachlesbar

Jedenfalls käme man dem Fall auch mit Debugging und Kontrollausgabe auf die Spur. Es müsste ja vorher Inhalt zu sehen sein, der bei der Ausgabe verlorenginge.

Entweder Du benutzt das zweite Funktionsargument von htmlspecialchars() dafür, oder Du setzt die Kodierung skriptglobal mit der Funktion (...)

Das zweite ist $flags, das dritte wäre $encoding.

Ich war noch nicht fertig. Mit dem Tablet kann ich zwischen derart fetten Tabs (Forum und PHP-Manual) leider nicht sicher hin- und herschalten. Da lädt der Tab dann leider neu und der neue Text für das Posting ist weg. Also muss ich immer erst zwischenspeichern.

Glück Auf
Tom vom Berg

[Matthias Apsel]

Hallo TS,

Da lädt der Tab dann leider neu und der neue Text für das Posting ist weg. Also muss ich immer erst zwischenspeichern.

Entwürfe sollten im LocalStorage gespeichert werden. Gibts das bei deinem Tablet nicht?

Bis demnächst
Matthias

[TS]

Hello,

Hallo TS,

Da lädt der Tab dann leider neu und der neue Text für das Posting ist weg. Also muss ich immer erst zwischenspeichern.

Entwürfe sollten im LocalStorage gespeichert werden. Gibts das bei deinem Tablet nicht?

Keine Ahnung, was der Samsung-Browser zur Verfügung stellt. Ich hatte bisher noch keinen Nerv, die Macke näher zu ergründen und/oder es auch mit Chrome bzw. Fiefox auszuprobieren.

Und irgendwie widerspricht es sowieso meinen Wünschen, mehrere Browser-Apps auf dem Tablet zu haben. Nur eine nicht installierte App ist eine sichere App.

Glück Auf
Tom vom Berg

[Tabellenkalk]

Hallo,

Nur eine nicht installierte App ist eine sichere App.

Ich hab auch erstmal alle Apps deinstalliert

Gruß
Kalk

[TS]

Hello,

Hallo,

Nur eine nicht installierte App ist eine sichere App.

Ich hab auch erstmal alle Apps deinstalliert

Manche dicken Bretter muss man nicht erst bohren ;-p

Das Holz-Smartphone ist sicher gut gegen die Spider-App, oder?

Glück Auf
Tom vom Berg

[Tabellenkalk]

Hallo,

Das Holz-Smartphone ist sicher gut gegen die Spider-App, oder?

100%ige Sicherheit gibt es nie

Gruß
Kalk

[Auge]

Hallo

Sofern die Datenbankabfrage überhaupt etwas liefert, könnte das am htmlspecialchars() liegen. Das findet keine gültige Kodierungsangabe.

Das halte ich für sehr unwahrscheinlich, solange man den Wert für default_charset nicht willentlich kaputtmacht. Und selbst wenn, kann ich mir grad nur vorstellen, dass lediglich die Übersetzungstabelle nicht gefunden wird, und der Inhalt einfach unverändert durchläuft. Hast du da irgendwelche konkreten gegenteiligen Erfahrungen gemacht?

Ja. Das lief hier auch schon öfter durch das Forum, nachdem ich die Ursache festgestellt hatte. Und auch z. B. hier nachlesbar

Auf das im verlinkten Dokument beschriebene Problem bin ich mit einem ursprünglich für PHP 4 geschriebenen Skript auch schon gestoßen. Allerdings gab es da in keiner Situation keine Ausgabe, sondern immer mindestens eine Meldung von PHP. Ob die Meldung eine Warnung oder ein Fehler war, weiß ich nicht mehr. Das ist schon weit über ein Jahr her. Nach Angabe der zu verwendenden Kodierung war dann auch Ruhe im Karton.

Tschö, Auge

[TS]

Hello Auge,

Sofern die Datenbankabfrage überhaupt etwas liefert, könnte das am htmlspecialchars() liegen. Das findet keine gültige Kodierungsangabe.

Das halte ich für sehr unwahrscheinlich, solange man den Wert für default_charset nicht willentlich kaputtmacht. Und selbst wenn, kann ich mir grad nur vorstellen, dass lediglich die Übersetzungstabelle nicht gefunden wird, und der Inhalt einfach unverändert durchläuft. Hast du da irgendwelche konkreten gegenteiligen Erfahrungen gemacht?

Ja. Das lief hier auch schon öfter durch das Forum, nachdem ich die Ursache festgestellt hatte. Und auch z. B. hier nachlesbar

Auf das im verlinkten Dokument beschriebene Problem bin ich mit einem ursprünglich für PHP 4 geschriebenen Skript auch schon gestoßen. Allerdings gab es da in keiner Situation keine Ausgabe, sondern immer mindestens eine Meldung von PHP. Ob die Meldung eine Warnung oder ein Fehler war, weiß ich nicht mehr. Das ist schon weit über ein Jahr her. Nach Angabe der zu verwendenden Kodierung war dann auch Ruhe im Karton.

Ich habe das Phänomen 2016/2017 gehabt, und zunächst wusste keiner Rat. Ich meine, dass es in der Standardausgabe (Browser) keine Meldung gab. Der Bildschirm blieb einfach blank.

Irgendwie haben wir dann eine Fehlermeldung im (Err_)Log provoziert. Die kam aber auch erst nach spezieller Einstellung. Ich habe jetzt gerade vergessen, wie die lautete, aber sie bezog sich auf "pre-compile", also eine neue äußere Hülle um den PHP-Verarbeitungsprozess. Vielleicht fällt Did ja ein, welche das sein könnte?

Die Einstellung display_startup_errors bezieht sich doch nur auf die zusätzliche Ausgabe in der Standardausgabe (Browser), und nicht auf die Logs, oder?

Glück Auf
Tom vom Berg

[Auge]

Hallo

Ich habe das Phänomen 2016/2017 gehabt, und zunächst wusste keiner Rat. Ich meine, dass es in der Standardausgabe (Browser) keine Meldung gab. Der Bildschirm blieb einfach blank.

Irgendwie haben wir dann eine Fehlermeldung im (Err_)Log provoziert. Die kam aber auch erst nach spezieller Einstellung. Ich habe jetzt gerade vergessen, wie die lautete, aber sie bezog sich auf "pre-compile", also eine neue äußere Hülle um den PHP-Verarbeitungsprozess. Vielleicht fällt Did ja ein, welche das sein könnte?

Mir wurden, wenn ich mich richtig erinnere, Texte mit falschen Codepunkten, die in UTF-8 nicht gültig waren, abgeschnitten. Eine PHP-eigene, explizite Fehlermeldung gab es aber doch nicht. Grundsätzlich gab es aber eine (kaputte) Ausgabe.

Die Einstellung display_startup_errors bezieht sich doch nur auf die zusätzliche Ausgabe in der Standardausgabe (Browser), und nicht auf die Logs, oder?

Soweit ich das Manual verstehe, geht es nicht um Standardausgabe versus Log-(Datei) sondern um Laufzeitfehler von PHP versus Fehler beim Start der PHP-Interpreters. Mit Startup-fehlern mkusste ich mich bisher aber noch nicht beschäftigen. Daher kann ich dazu nicht detailliertes sagen.

Tschö, Auge

[dedlfix]

Tach!

Sofern die Datenbankabfrage überhaupt etwas liefert, könnte das am htmlspecialchars() liegen. Das findet keine gültige Kodierungsangabe.

Hab ich versucht nachzustellen.

ini_set('default_charset', 'foo');
echo htmlspecialchars('<föo>');

ergibt diese Warnung:

Warning: htmlspecialchars(): charset `foo' not supported, assuming utf-8

nebst der problemlosen Ausgabe - wenn ich UTF-8 als Kodierung der Datei habe. Wenn sie ISO-8859-1 ist und sich Nicht-ASCII-Zeichen darin befinden, dann unterbleibt die Ausgabe geräuschlos. Das ist wohl der Fall, den du meinst, also eine ungültige UTF-8-Sequenz.

Entweder Du benutzt das zweite und dritte Funktionsargument von htmlspecialchars() dafür, oder Du setzt die Kodierung skriptglobal mit der Funktion ini_set() mit default_charset.

Ich würde da gar nichts weiter angeben und stattdessen dafür sorgen, dass UTF-8 generell korrekt verwendet wird, dann gibts da auch kein Problem. Und zwar generell nicht, nicht nur an dieser Stelle nicht. Es hilft ja nicht viel, nur dort etwas zu korrigieren, das an vielen anderen Stelle weiterhin kaputt ist.

dedlfix.