variable in mysql_query??
0 0 0 0 Testscript erläutern
0 
dedlfix
0 0 0 0 Benannte Zeichen
0 0 dedlfix
variable in mysql_query??
hallo zusammen,
ich würde gerne in einer queri die aufsteigerichtung durch eine variable ändern, die einem hyperlink angefängt wird. wenn ich die variable direkt im php-code angebe, klappts, wenn ich sie, wie im beispiel unten, an <?=$PHP_SELF?>?sort=DESC anhänge, bleibt die reihenfolge jedoch gleich. was mach ich denn da falsch?
hier der code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<?php
mysql_connect("localhost","root","");
mysql_select_db("cdcol");
$result=mysql_query ("SELECT id,titel,interpret,jahr FROM cds ORDER BY interpret $sort ;");
while($row = mysql_fetch_object($result))
{
echo $row->titel;
}
?>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<p><a href="<?=$PHP_SELF?>?sort=DESC">test</a></p>
</body>
</html>
-
Hello,
hallo zusammen,
ich würde gerne in einer queri die aufsteigerichtung durch eine variable ändern, die einem hyperlink angefängt wird. wenn ich die variable direkt im php-code angebe, klappts, wenn ich sie, wie im beispiel unten, an <?=$PHP_SELF?>?sort=DESC anhänge, bleibt die reihenfolge jedoch gleich. was mach ich denn da falsch?
hier der code:
<?php
error_reporting(E_ALL);$out = ''; ## AHTML-Ausgabevariable für den Body
$conn = mysql_connect("localhost","root",""); ## Gefährlich!!! kein passwort,
## und Zugriff mit Root
if ($conn) ## ur wenn es geklappt hat
{
if(mysql_select_db("cdcol",$conn)) ## Nur wenn DB vorhanden ist
{
$sort = '';
if (isset($_GET['sort']) and $_GET['sort'] == 'DESC')) ## Wurde param gesetzt?
{
$sort = "order by interpret desc"; ## Dann lautet dasa Query so
}
elseif (
{
$sort = "order by interpret asc"; ## oder so
}
else
{
$sort = "order by id": ## sonst default
}$sql = "SELECT id,titel,interpret,jahr FROM cds $sort ;"
$result = mysql_query ($sql, $conn);
if ($result)
{
while($row = mysql_fetch_object($result))
{
$out .= "<p>" . htmlspchialchars($row->titel) . "</p>\n";
}
}
else
{
$out = "<p>Fehler bei der Abfrage</p>\n";
}$link1 = $_SERVER['PHP_SELF'].'?sort=DESC';
$link2 = $_SERVER['PHP_SELF'].'?sort=ASC';}
else
{
$out = "<p>Kann die Datenbank nicht öffnen</p>\n";
}
}
else
{
$out = "<p>Kann den datenbankserver nicht erreichen</p>\n";
}####################################################################
HTML-Output
####################################################################
?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Anzeige</title>
</head><body>
<p><a href="<?php echo $link1; ?>">absteigend anzeigen</a></p>
<p><a href="<?php echo $link2; ?>">absteigend anzeigen</a></p><?php echo $out; ?>
</body>
</html>Ich habe mal versucht, Dein Script etwas aufzuräumen.
Ich hoffe, dass kein Tippfehler drin ist und es so funktioniert.Niemals Parameter des Client direkt an die datenbank durchreichen
Immer übersetzen (Translation Table) oder zumindest prüfen und escapen
siehe --> mysql_real_escape_string()Und immer schön Eingabe, Verarbeitung und Ausgabe trennen, dann bleiben Deine Scripte übersichtlich.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hallo,
was mach ich denn da falsch?
Dein PHP-Script holt die übergebene Variable nicht ab.
Wie man das macht steht u.a. hierelseif (
{
$sort = "order by interpret asc"; ## oder so
}
else
{
$sort = "order by id": ## sonst default
}elseif was? Kann das so stimmen?
Niemals Parameter des Client direkt an die datenbank durchreichen
Immer übersetzen (Translation Table) oder zumindest prüfen und escapen
siehe --> mysql_real_escape_string()Sehr richtig. Das kann man nicht oft genug sagen, wie ich selber schmerzlich erfahren musste.
Gruß, Don P
-
Hello,
Dein PHP-Script holt die übergebene Variable nicht ab.
Wie man das macht steht u.a. hierelseif (isset($_GET['sort']) and $_GET['sort'] == 'ASC'))
{
$sort = "order by interpret asc"; ## oder so
}
else
{
$sort = "order by id": ## sonst default
}elseif was? Kann das so stimmen?
Nee, natürlich nicht. Da habe ich wieder drei Sachen auf einmal gemacht...
sind auch noch ein paar Tippfehler dirn.Jetzt müsste das schon mal stimmen
while($row = mysql_fetch_object($result))
{
$out .= "<p>" . htmlspechialchars($row->titel) . "</p>\n";
}Da fehlte noch ein "p" im Funktionsnamen.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
ja, super, jetzt klappts auch mit den speCialchars;-)
macht echt spaß, sich weiterzuentwickeln mit so einem guten lehrer wie dich:-)
h
-
Hello,
ja, super, jetzt klappts auch mit den speCialchars;-)
macht echt spaß, sich weiterzuentwickeln mit so einem guten lehrer wie dich:-)
*hach* jetzt kann ich doch wieder die ganze Nacht nicht schlafen... ;-)
Wir hatten die letzten Tage hier einen "Onlinelehrgang" angefangen.
Leider sind mir dann nacheinander zwei PCs gestorben und nix ging weiter.
Der Thread ist noch nicht lange im Archiv und sowie ich wieder Zeit habe (und die beiden anderen noch Lust haben) geht es weiter. Das ist so eine Art Experiment auf Gegenseitigkeit.http://forum.de.selfhtml.org/archiv/2007/10/t160669/#m1045013
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
-
-
echo $begrüßung;
was mach ich denn da falsch?
Dein PHP-Script holt die übergebene Variable nicht ab.Ein Webserver bekommt bei einem Request keine Variablen übergeben sondern Parameter. PHP stellt diese Parameter in den Arrays $_GET und $_POST zur Verfügung. Dort sind es dann bereits Variablen, die einfach nur noch verwendet werden müssen. Da muss nichts abgeholt werden, es ist bereits da. Das oft gesehe $param=$_GET['param']; ist nicht nur überflüssig sondern verharmlost auch noch diese Werte. Bei einem $_GET['param'] sieht man eindeutig: "Benutzereingabe, kann auch bösartiges enthalten", bei einem schlichten $param sieht man das nicht mehr sofort.
echo "$verabschiedung $name";
-
-
whow, danke, so ausführlich hätte ich das ja garnicht erwartet- ich werde es mal durchackern und dabei lernen...
habe ich das prinzipiell richtig verstanden, dass eine übergabe eines wertes an eine variable über einen link und ?=irgendwas nur geht, wenn register globals on ist?
jetzt hätte ich noch eine bitte: könntest du dein script nochmal auf etwaige schreibfehler etc. durchsehen, damit ich beim testen und lernen mir nicht stundenlang den kopf über einen flüchtigkeitsfehler zerbrechen muß, bzw. das forum hier nerve, obwohl das script im prinzip richtig ist?
danke vielmals, du hast mir sehr geholfen!
h
-
Hello,
habe ich das prinzipiell richtig verstanden, dass eine übergabe eines wertes an eine variable über einen link und ?=irgendwas nur geht, wenn register globals on ist?
Wenn Du in der URL Parameter der Form
?param=wert
übergibst, dann kommen die bei heute typischer Konfiguration von PHP im "superglobalen Array" $_GET an als
$_GET['param'] ==> wert
PHP hat sie für Dich schon passend url-decoded
und leider meistens mit sogenannten "Magic Quotes" behandelt.
http://de.php.net/manual/en/security.magicquotes.phpVon den ""superglobalen Arrays" gibt es noch mehr.
http://de.php.net/variables.predefinedDie magic Quoters würde ich ausschalten. Sonst muss man sie i.d.R. wieder entfernen, um mit den Daten im Script arbeiten zu können.
Die Elemente der Superglobalen Arrays kann ganz normal im gesamten Script als Variablen verwenden. Sie sind in allen Scopes (Gültigkeitsbereichen) verfügbar. Einziger Wermutstropfen ist, dass man sie in Strings ,it Doppelhäkchen nicht einfach so zur Ersetzung einsetzen kann
echo "Der GET-Parameter mit dem Namen 'name' lautet {$_GET['name']}.";
man muss immer noch eine Extralage geschweifte Klammern spendieren, oder den String zusammensetzen
echo "Der GET-Parameter mit dem Namen 'name' lautet " . $_GET['name'] . ".";
was meisten ohnehin notwendig ist, weil man die Werte ja auch noch kontexrtbezogen (also für HTML) vorbehandeln muss.
echo "Der GET-Parameter mit dem Namen 'name' lautet " .
htmlspecialchars($_GET['name'],ENT_QUOTES) . ".";Die Einstellung "Register Globals = ON" solltest Du lieber ganz schnell vergessen. Das ist ein Relikt aus der Anfangszeit von PHP, als man es noch chic fand, die Daten aus allen Quellen (GET, POST, COOKIE, ...) möglichst sofort und handlich im Script zur Verfügung zu haben. Leider verliert man dabei den Herkunftsbezug, denn alle request-Methoden haben ihre Werte jeweils auf derselben Variable abgeliefert.
$name kam aus dem Formular mit <input type="text" name="name" ...>,
das mit Post abgeschickt wurde$name kam aus dem Cookie
$name kam aus der URi mit ?name=paul
und alle haben sich gegenseitig überschrieben.
Das gemeine war aber, dass auf diese Weise auch Scriptvariablen eingeschleust werden konnten. Hatte man also vergessen, die Variablen zu initialisieren, was ja bei PHP nicht unbedingt erforderlich ist, dann war die Sicherheitslücke meisten aufgerissen
Also, arbeite fröhlich mit
register_globals = off;
magic_quotes_gpc = off;Dann wird es schon klappen.
jetzt hätte ich noch eine bitte: könntest du dein script nochmal auf etwaige schreibfehler etc. durchsehen, damit ich beim testen und lernen mir nicht stundenlang den kopf über einen flüchtigkeitsfehler zerbrechen muß, bzw. das forum hier nerve, obwohl das script im prinzip richtig ist?
Das machen wir hier gemeinsam.
Ich habe Dir ja das Errorreporting am Anfang eingeschaltet, sodass Du eigentlich jede Notice bekommen solltest. Wenn also ein fehler auftritt, dann melde dich und poste die Fehlermeldung.Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
echo $begrüßung;
Die Elemente der Superglobalen Arrays kann ganz normal im gesamten Script als Variablen verwenden. Sie sind in allen Scopes (Gültigkeitsbereichen) verfügbar. Einziger Wermutstropfen ist, dass man sie in Strings ,it Doppelhäkchen nicht einfach so zur Ersetzung einsetzen kann
echo "Der GET-Parameter mit dem Namen 'name' lautet {$_GET['name']}.";
man muss immer noch eine Extralage geschweifte Klammern spendieren,
Wie ich heute zufällig dem PHP-Handbuch entnahm, ist das nicht so. Innerhalb eines ""-Strings darf man ungestraft $foo[bar] verwenden. Mir scheint, dass diese Passage noch nicht sehr alt ist.
Siehe http://de.php.net/manual/en/language.types.array.php#language.types.array.foo-bar.whyecho "$verabschiedung $name";
-
Hello,
echo "Der GET-Parameter mit dem Namen 'name' lautet {$_GET['name']}.";
man muss immer noch eine Extralage geschweifte Klammern spendieren,
Wie ich heute zufällig dem PHP-Handbuch entnahm, ist das nicht so. Innerhalb eines ""-Strings darf man ungestraft $foo[bar] verwenden. Mir scheint, dass diese Passage noch nicht sehr alt ist.
Siehe http://de.php.net/manual/en/language.types.array.php#language.types.array.foo-bar.whyDas muss man aber genau zuende lesen...
echo "Der GET-Parameter mit dem Namen 'name' lautet $_GET[name].";
das soll angeblich funktionieren. Also OHNE die Häkchen für den Element-Bezeicher des Arrays.
Das ist mir zu schmuddelig. Was ist, wenn ich da tatsächlich mal eine Konstante als Elementbezeichner benutzen will?Die "gepunktete Stringmontage" ist mir dann doch noch die liebste. Sonst verwirrt man sich nur selber und es weiß nachher keiner mehr, was gemeint war.
Zitat:
<?php
// These examples are specific to using arrays inside of strings.
// When outside of a string, always quote your array string keys
// and do not use {braces} when outside of strings either.// Let's show all errors
error_reporting(E_ALL);$fruits = array('strawberry' => 'red', 'banana' => 'yellow');
// Works but note that this works differently outside string-quotes
echo "A banana is $fruits[banana].";// Works
echo "A banana is {$fruits['banana']}.";// Works but PHP looks for a constant named banana first
// as described below.
echo "A banana is {$fruits[banana]}.";// Won't work, use braces. This results in a parse error. #### !!!!
echo "A banana is $fruits['banana'].";// Works
echo "A banana is " . $fruits['banana'] . "."; #### am besten so!// Works
echo "This square is $square->width meters broad.";// Won't work. For a solution, see the complex syntax.
echo "This square is $square->width00 centimeters broad.";
?>
---------------------------------------------------------------------Warum ich sage 'am besten so'?
Weil diese Schreibweise immer funktioniert, auch wenn man $fruits['banana'] noch in eine Funktion verpacken muss.Ich mag keine Programmiersprachen, die für alles sieben verschiedene Schreibweisen zulassen, die meistens auch die gleiche Wirkung haben, besonders montags...
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
echo $begrüßung;
Das muss man aber genau zuende lesen...
echo "Der GET-Parameter mit dem Namen 'name' lautet $_GET[name].";
das soll angeblich funktionieren. Also OHNE die Häkchen für den Element-Bezeicher des Arrays.
Das ist mir zu schmuddelig. Was ist, wenn ich da tatsächlich mal eine Konstante als Elementbezeichner benutzen will?Dann musst du explizit die {}-Klammern verwenden.
define('foo', 'baz'); $array = array('foo' => 'bar', 'baz' => 'qux'); echo "... $array[foo] ... {$array[foo]} ... ", $array[foo];Was wird wohl die Ausgabe sein?
Die "gepunktete Stringmontage" ist mir dann doch noch die liebste.
Wenn du eine Ausgabe mit echo erzeugen möchtest, dann wäre die "gekommate String-Nicht-Montage" die sinnvollere Variante.
echo arg1, arg2, arg3;
statt
echo arg1 . arg2 . arg3;Variante 1 gibt einfach die Werte aus, ohne vorher erst noch temporär einen String zusammenzubauen.
echo "$verabschiedung $name";
-
Hello,
Wenn du eine Ausgabe mit echo erzeugen möchtest, dann wäre die "gekommate String-Nicht-Montage" die sinnvollere Variante.
echo arg1, arg2, arg3;
statt
echo arg1 . arg2 . arg3;Das hatten wir neulich gerade alles durchgekaut hier im "Online-Seminar"...
Die "gekommate" ist Vielen gar nicht bekannt; dabei ist sie sher praktisch.Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
-
-
-
Das machen wir hier gemeinsam.
ok, ich habs im prinzip verstanden und auch zum laufen gebracht, es waren einige klammern falsch etc., aber jetzt gehts. ich poste es für interessierte hier nochmal. eine frage hab ich aber noch dazu: ich bekam zuerst folgende fehlermeldung:Fatal error: Call to undefined function htmlspechialchars()
daraufhin hab ich die specialchars-funktion (zeile 37) einfach entfernt, und jetzt gehts. ist das ein problem??
h
-
Hello,
ok, ich habs im prinzip verstanden und auch zum laufen gebracht, es waren einige klammern falsch etc., aber jetzt gehts. ich poste es für interessierte hier nochmal. eine frage hab ich aber noch dazu: ich bekam zuerst folgende fehlermeldung:Fatal error: Call to undefined function htmlspechialchars()
Die Funktion ist auch immer noch falsch geschrieben
http://de.php.net/manual/en/function.htmlspecialchars.phphtml spezial zeichen -- verdenglischen --> html special characters
Programmiererslang drüberlaufen lassen --> htmlspecialchars()
Wenn Du Scripte schreibst in PHP und mit Datenbank usw. dann solltest Du eigentlich immer die Manuals im Zugriff haben. Die stehen ja alle im Netz und bieten eine menge Tipps und Hinweise.
Bei PHP kommt noch erschwerend hinzu, dass die sich nie einig werden können, in welcher Reihenfolge Funktionsargumente aufgeführt werden können. Bei einer Funktion steht mal das zu behandeldnde Objekt vorne, bei der anderen der Suchstring oder die "Needle". ich scheu da grundsätzlich nochmal nach.
Bei MySQL ist es nicht so wirr.
daraufhin hab ich die specialchars-funktion (zeile 37) einfach entfernt, und jetzt gehts. ist das ein problem??
Ja, eigentlich schon. Wenn Deine Suchergebnisse nämlich nun Häkchen, Zeilenumbrüche, spitze Klammern oder ähnliche bei HTML reservierte Zeichen enthalten, dann bringst Du mit einer unbehandelten Ausgabe Deinen Browser durcheinander. Du wunderst Dich dann später, wenn die Datenmenge gestiegen ist, dass es manchmal diese hässlichen Darstellungsfehler gibt und manchmal eben nicht.
Also am besten immer alles gleich für den richtigen Kontext vorbereiten, auch wenn bei 90% der Daten keine Probleme auftreten.
Für die Codierung mit utf-8 reicht htmlspechialchars(...,ENT_QUOTES)
Für die Codierung mit ISO 8859-1 sollte man schon htmlentities(...,ENT_QUOTES) benutzen.Du solltest also schon wissen, in welcher Codierung Du Dein Projekt anlegst, damit Du nachher nicht alles umbauen musst, oder aber, du baust Dir eine eigene Funktion "htmlkontext(...)" zusammen, die dann auf von Dir festgelegte Konstanten zurückgreift und damit automatsich die richtige Funktion wählt.
Das halte ich Zeiten von Umstellungen immer für am besten.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Moin!
Also am besten immer alles gleich für den richtigen Kontext vorbereiten, auch wenn bei 90% der Daten keine Probleme auftreten.
Für die Codierung mit utf-8 reicht htmlspechialchars(...,ENT_QUOTES)
Für die Codierung mit ISO 8859-1 sollte man schon htmlentities(...,ENT_QUOTES) benutzen.Nein, das ist nicht notwendig. In keiner Konstellation.
Da der Datenaustausch zwischen Server und Browser sowie zwischen Browser und Server in der gleichen Codierung abläuft, sofern man nicht manuell eingreift, stehen die Strings in PHP in der passenden Codierung zur Verfügung. htmlentities() codiert Zeichen, die nicht codiert werden müssen - und benötigt obendrein für korrektes Arbeiten die Angabe, welche Zeichencodierung verwendet werden soll.
htmlspecialchars() hingegen arbeitet unabhängig von der Zeichencodierung korrekt, da die fraglichen Zeichen sowohl in UTF-8 als auch in ISO-8859-1 (oder jeder anderen ISO-Kodierung).
Der Parameter ENT_QUOTES ist im Regelfall auch überflüssig.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hello,
Für die Codierung mit ISO 8859-1 sollte man schon htmlentities(...,ENT_QUOTES) benutzen.
Nein, das ist nicht notwendig. In keiner Konstellation.
Da der Datenaustausch zwischen Server und Browser sowie zwischen Browser und Server in der gleichen Codierung abläuft, sofern man nicht manuell eingreift, stehen die Strings in PHP in der passenden Codierung zur Verfügung. htmlentities() codiert Zeichen, die nicht codiert werden müssen - und benötigt obendrein für korrektes Arbeiten die Angabe, welche Zeichencodierung verwendet werden soll.
Ich kann Dir nicht folgen.
Wenn ich eine Seite in der Codierung ISO 8859-1 an den Browser ausliefere, wieso brauche ich dann keine Zeichen als HTML-Entitities (benannt oder als numerische Notation) zu senden?
http://de.selfhtml.org/html/referenz/zeichen.htm#benannte_iso8859_1Und wieso benötigt htmlentities() dann noch die Angabe der Zeichenkodierung? ISO-8859-1 ist default!
http://de.php.net/manual/en/function.htmlentities.phpWieso hat man die benannten/numerierten Zeichen dann überhaupt eingeführt?
Und wieso muss ich das einfache Häkchen nicht ersetzen?
Wenn im html-Code z.B. steht
<input type='text' name='eingabe' value='<?php echo $eingabe; ?>' >
was würde dann dabei herauskommen, wenn in $eingabe ein Häkchen vorkommt?
Oder meintest Du etwas ganz anderes?
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Moin!
Für die Codierung mit ISO 8859-1 sollte man schon htmlentities(...,ENT_QUOTES) benutzen.
Nein, das ist nicht notwendig. In keiner Konstellation.
Da der Datenaustausch zwischen Server und Browser sowie zwischen Browser und Server in der gleichen Codierung abläuft, sofern man nicht manuell eingreift, stehen die Strings in PHP in der passenden Codierung zur Verfügung. htmlentities() codiert Zeichen, die nicht codiert werden müssen - und benötigt obendrein für korrektes Arbeiten die Angabe, welche Zeichencodierung verwendet werden soll.
Ich kann Dir nicht folgen.
Wenn du Daten, die dir der Browser geschickt hat, wieder an diesen zurückschickst, kannst du nur Zeichen empfangen haben, die in der jeweiligen Codierung darstellbar waren.
Bei ISO-8859-1 kriegst du garantiert nur Zeichen zurück, die in ISO-8859-1 direkt darstellbar waren. Und auch wenn du externe Quellen einbindest, die in ISO-8859-1 codiert sind (Datenbanken, Textdateien, Streams von Webservices etc.), erhälst du ausschließlich Zeichen, die direkt in ISO-8859-1 darstellbar sind, also keinerlei Umwandlung in Entities erfordert. Denn würden Zeichen zu übermitteln sein, die in ISO-8859-1 nicht darstellbar wären, dann wären diese schon in irgendeiner Form passend codiert (das muß nicht als Entity sein, kann aber), so dass eine weitergehende Codierung in Entities einfach nur mit htmlentities() sowieso nicht funktionieren würde.
Wenn ich eine Seite in der Codierung ISO 8859-1 an den Browser ausliefere, wieso brauche ich dann keine Zeichen als HTML-Entitities (benannt oder als numerische Notation) zu senden?
Es mag ja sein, dass du Zeichen senden möchtest, die in ISO-8859-1 nicht darstellbar sind. Aber die kriegst du keinesfalls vom Browser als Inhalt von Formularfeldern zurück, und auch nicht aus anderen ISO-8859-1-codierten Quellen in einer htmlentities-fähigen Form.
Und wieso benötigt htmlentities() dann noch die Angabe der Zeichenkodierung? ISO-8859-1 ist default!
Richtig, aber es ist ja unnötig, es anzuwenden, Begründung siehe oben. Solltest du hingegen UTF-8-Quellen anzapfen, in denen ja Zeichen vorkommen können, die nicht in ISO-8859-1 passen, mußt du das selbstverständlich mitteilen - ansonsten kriegst du ä als Entitykombination für irgendeinen der deutschen Umlaute (ä, ö, ü - irgendeiner wird's sein), und nicht &xuml;.
Wieso hat man die benannten/numerierten Zeichen dann überhaupt eingeführt?
Weil in einigen Codierungen nicht die Gesamtpalette der in HTML möglichen Zeichen direkt codiert werden können.
Und wieso muss ich das einfache Häkchen nicht ersetzen?
Wenn im html-Code z.B. steht
<input type='text' name='eingabe' value='<?php echo $eingabe; ?>' >
was würde dann dabei herauskommen, wenn in $eingabe ein Häkchen vorkommt?
Das kannst du ja aber problemlos beeinflussen:
<input type="text" name="eingabe" value="<?php echo htmlspecialchars($eingabe); ?>">
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hello,
Ok, das mit dem Zeichnsatz von ISO-8859-1 ist mir inzwischen auch wieder klar geworden.
Der ist bei ASCII nicht zuende sondern nutzt den erweiterten Bereich bis Ordnungszahl 255 doch.Da war bei mir irgendwas vorbeigerauscht.
Dass htmlspecialchars() notwendig ist, ist auch klar. Sonst geht sie Seite krachen wegen der HTML-eigenen Zeichen.
Richtig, aber es ist ja unnötig, es anzuwenden, Begründung siehe oben. Solltest du hingegen UTF-8-Quellen anzapfen, in denen ja Zeichen vorkommen können, die nicht in ISO-8859-1 passen, mußt du das selbstverständlich mitteilen - ansonsten kriegst du ä als Entitykombination für irgendeinen der deutschen Umlaute (ä, ö, ü - irgendeiner wird's sein), und nicht &xuml;.
Und da liegt jetzt noch der Knackepunkt.
Internet hört an der Sprachgrenze nicht auf.
Wenn ich jetzt in ISO-8859-1 ausliefern würde z.B. nach Grönland, kann ich dann davon ausgehen, dass der Browser des Grönländers meinen Zeichensatz versteht und in die richtigen Glyphen verwandelt?
Jetzt sag bitte nicht einfach, dafür gibt es utf-8. Das ist mir klar.
Aber was ist mit ISO-8859-1 Seiten, die in Grönland aufschlagen, und der dort hat nur seinen ISO-8859-10, zumal er ja wahrscheinlich auch nicht die passende Tastatur für "meinen" ISO-8859-1 hat.Der schreibt jetzt was in meine Datenbank und ich habe nachher wahrscheinlich nur Quatsch drinstehen, oder? Sein Browser wird ja nicht sagen, er sendet nicht, nur weil er den Zeichnsatz nicht hat. Der sendet einfach... Oder?
Ist wahrscheinlich aber zu einfach gedacht, weil so ein paar Zeichnsätze angesichts der Millionen von Bytes heutiger Programme locker in den Browser passen. Wer ist denn da für das Rendering eigentlich zuständig? Der Browser selber? Zumindest für seine Standardschriftarten?
<input type='text' name='eingabe' value='<?php echo $eingabe; ?>' >
was würde dann dabei herauskommen, wenn in $eingabe ein Häkchen vorkommt?
Das kannst du ja aber problemlos beeinflussen:
<input type="text" name="eingabe" value="<?php echo htmlspecialchars($eingabe); ?>">
DAS ist doch dann mal ein Plädoier für die Nutzuung von ausschließlich " für den HTML-Code.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Moin!
Internet hört an der Sprachgrenze nicht auf.
Wenn ich jetzt in ISO-8859-1 ausliefern würde z.B. nach Grönland, kann ich dann davon ausgehen, dass der Browser des Grönländers meinen Zeichensatz versteht und in die richtigen Glyphen verwandelt?
Auch in Grönland ist bekannt, welche Unicode-Codepoints sich in ISO-8859-1 hinter den einzelnen Bytewerten verstecken.
Und da HTML Unicode als Zeichensatz benutzt, der Browser also den gesamten Unicode-Zeichenvorrat verarbeiten können muß, gibt es von dieser Seite her absolut keinerlei Probleme. Denn auch die Entities oder numerischen Zeichenreferenzen sind ja Bestandteil des Unicode-Zeichensatzes, müssen also vom Browser irgendwie verarbeitet werden können.
Jetzt sag bitte nicht einfach, dafür gibt es utf-8. Das ist mir klar.
Aber was ist mit ISO-8859-1 Seiten, die in Grönland aufschlagen, und der dort hat nur seinen ISO-8859-10, zumal er ja wahrscheinlich auch nicht die passende Tastatur für "meinen" ISO-8859-1 hat.Die Tastatur ist irrelevant, Tippen ist zum Empfang einer Webseite nicht notwendig.
Relevant ist, dass der Computer eine Schriftart installiert haben muß, in der für die übermittelten Zeichen ein Buchstabenbild definiert ist - ansonsten sieht man nämlich nichts.
Glücklicherweise ist das bei den westeuropäischen Codierungen absolut kein Problem, die beherrscht (seltsamerweise) jeder Rechner dieser Welt. Englisch ist halt die Hauptsprache in diesem Gebiet, und die diversen existierenden Anwendungen bergen eben eine unwiderstehliche normative Kraft des Faktischen. Sprich: Selbst ein chinesischer Computer kann es sich nicht leisten, keine Zeichendarstellung für englische Schriftzeichen zu beherrschen. Alleine schon deswegen, weil ja auch die Chinesen die URLs lange Zeit in diesen Zeichen eingetippt haben - und HTML nutzt ja auch englische Begrifflichkeiten.
Der schreibt jetzt was in meine Datenbank und ich habe nachher wahrscheinlich nur Quatsch drinstehen, oder? Sein Browser wird ja nicht sagen, er sendet nicht, nur weil er den Zeichnsatz nicht hat. Der sendet einfach... Oder?
Richtig. Wenn zu befürchten ist, dass dein Besucher dir ins Formular Zeichen reinschreibt, die in deiner Codierung der Seite nicht darstellbar sind, hast du ein Problem. Das Resultat ist - in verschiedenen Ausprägungen - die Zerstörung der Zeichen.
Wahlweise kriegst du:
1. Fragezeichen statt der nicht-darstellbaren Zeichen.
2. Das Zeichen in einer anderen Codierung, als du erwartest (das Eurozeichen wird, wenn es nicht in ISO-8859-1 paßt, ggf. wie in Windows-1252 codiert).
3. Numerische Zeichenreferenzen, die man aber nicht mehr von manuell eingegebenen Referenzen unterscheiden kann.Deshalb nimmt man UTF-8 (oder gerne auch jede andere beliebige Codierung, die sowohl den gesamten Unicode-Zeichenvorrat darstellen kann als auch von allen beteiligten Systemen fehlerfrei verstanden wird), damit passiert das garantiert nicht.
Ist wahrscheinlich aber zu einfach gedacht, weil so ein paar Zeichnsätze angesichts der Millionen von Bytes heutiger Programme locker in den Browser passen. Wer ist denn da für das Rendering eigentlich zuständig? Der Browser selber? Zumindest für seine Standardschriftarten?
Ich weiß mindestens von Opera, dass man dort für jede Codepage in Unicode einen passenden Standard-Font einstellen kann. Und man sollte auch nicht allzuviel Gedanken daran verschwenden, wie denn andere Sprachen wie etwa Chinesisch mit "Schriftarten" umgehen - nur weil die auf der deutschen Variante eingesetzte "Times New Roman" kein Chinesisch kann und der chinesische Font keine serifen hat. Serifen sind eine rein westliche Erfindung an den Buchstaben. Die chinesischen Schriftzeichen dürften im besten Fall nur unleserlich werden, im schlimmsten Fall ihre Bedeutung ändern, wenn da "Serifenstrichelchen" hinzugedichtet werden. Typographie ist nun mal extrem kulturkreisabhängig. Also sei man froh, überhaupt eine Schriftart zu haben, um den Text lesen zu können.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hello,
Also sei man froh, überhaupt eine Schriftart zu haben, um den Text lesen zu können.
Jau, großen Dank an Deine Adresse!
Sonst hätte ich Dein Posting vielleicht gar nicht lesen können.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
-
-
-
echo $begrüßung;
Und wieso muss ich das einfache Häkchen nicht ersetzen?
Du musst sie nicht in jedem Fall ersetzen. In Fließtext können problemlos " und ' direkt notiert werden. Nur in den Attributen der HTML-Elemente ist eine Ersetzung erforderlich, damit " oder ' nicht als abschließende Begrenzungszeichen angesehen werden, falls das betreffende Zeichen als Begrenzung verwendet wird. Nochmal anders formuliert: Innerhalb eines mit "" eingerahmten Attributwertes muss nur das " umgeschrieben werden, nicht aber ein '. Umgekehrt genauso. http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.2
Natürlich schadet es nicht, wenn man generell alle <>&"' behandelt, aber, wie gesagt, es ist nicht immer zwingend notwendig.
echo "$verabschiedung $name";
-
-
-
-
-
-
-