In einer meiner Shopanwendungen werden zur =DCbertragung der Mengen in
einer Liste (unglücklicherweise) die Artikelnummern als Teil des
Feldnamens verwendet:

<input name=3D'__artikel_A1735-11' value=3D'1'>

Die Anwendung geht dann das POST durch, sucht alle Keys mit "__artikel_" =

und übernimmt die Mengen.

Leider haben wir nun Artikel mit Leerzeichen im Artikelnamen, der
generierte Htmlteil sieht dann so aus:

<input name=3D'__artikel_mit zwei Leerzeichen' value=3D'3'>

Und im $_POST steht dann - erstaunlicherweise -
__artikel_mit_zwei_Leerzeichen =3D> 3

Es werden also die Leerzeichen im Feldname als Unterstreichungszeichen
übergeben. Upps. Ich hätte es wohl nicht so machen sollen, aber das i=
st
Geschichte.

Wundern tut mich nur: ist das Verhalten wo dokumentiert? Kann man sich
darauf verlassen? In allen PHP Konstellationen?

Gespannt.

Werner.

werner bauer schrieb:

> In einer meiner Shopanwendungen werden zur =DCbertragung der Mengen in =

> einer Liste (unglücklicherweise) die Artikelnummern als Teil des
> Feldnamens verwendet:

=C4ndere das.

> <input name=3D'__artikel_A1735-11' value=3D'1'>

<input name=3D'__artikel' value=3D'A1735-11'>
oder
<input name=3D'__artikel[A1735-11]' value=3D'1'>
(falls value die Menge darstellen soll).

> Wundern tut mich nur: ist das Verhalten wo dokumentiert? Kann man sich =

> darauf verlassen? In allen PHP Konstellationen?

Ich habe das noch nie vorher gesehen.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

werner bauer schrieb:

> In einer meiner Shopanwendungen werden zur Übertragung der Mengen in
> einer Liste (unglücklicherweise) die Artikelnummern als Teil des
> Feldnamens verwendet:

Keine gute Idee.

> Leider haben wir nun Artikel mit Leerzeichen im Artikelnamen, der
> generierte Htmlteil sieht dann so aus:
>
> <input name='__artikel_mit zwei Leerzeichen' value='3'>

Das ist zwar laut SelfHTML durchaus zulässig, hat in PHP aber Folgen:

> Und im $_POST steht dann - erstaunlicherweise -
> __artikel_mit_zwei_Leerzeichen => 3

PHP versucht, aus dem Feldnamen einen gültigen PHP-Variablennamen zu
generieren (wohl ein Tribut an register-globals = On) und ersetzt alle
ungültigen Zeichen durch Unterstriche.
>
> Wundern tut mich nur: ist das Verhalten wo dokumentiert? Kann man sich
> darauf verlassen? In allen PHP Konstellationen?

Jein. Dokumentiert ist nur die Ersetzung von Punkten, zumindest in
<http://de.php.net/manual/en/language.variables.external.php>. Weiter
habe ich nichts gefunden.

Gruß. Claus

Am 07.11.2007, 11:57 Uhr, schrieb werner bauer <werner__bauer [at] hotmail.com>:

> Es werden also die Leerzeichen im Feldname als Unterstreichungszeichen
> übergeben. Upps. Ich hätte es wohl nicht so machen sollen, aber das ist
> Geschichte.

Lass vor der Ausgabe htmlentities() oder htmlspecialchars() drüberlaufen.
(Alternativ geht auch urlencode).
Wenn der Nutzer Daten verändern kann, kann es allerdings auch zu Fehlern
kommen, spiel dir erst mal alle Möglichkeiten im Kopf durch.

Gruß
Chris

Chris Kraft schrieb:
> Am 07.11.2007, 11:57 Uhr, schrieb werner bauer <werner__bauer [at] hotmail.c=
om>:
>
>> Es werden also die Leerzeichen im Feldname als Unterstreichungszeichen=

>> übergeben. Upps. Ich hätte es wohl nicht so machen sollen, aber da=
s
>> ist Geschichte.
>
> Lass vor der Ausgabe htmlentities() oder htmlspecialchars()

Auch da wuerde aus einem Leerzeichen erstmal ein Leerzeichen bleiben.
Bringt also nix oder?

> drüberlaufen. (Alternativ geht auch urlencode).
> Wenn der Nutzer Daten verändern kann, kann es allerdings auch zu Fehl=
ern
> kommen, spiel dir erst mal alle Möglichkeiten im Kopf durch.

Niels hat es doch schon auf den Punkt gebracht.... und wenn man sch mal
durchliest welche Zeichen in PHP fuer einen gueltigen $VAR Namen in
Frage kommen ist damit zurechnen das es noch andere Zeichen treffen koenn=
te.

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Claus Reibenstein schrieb:

> > Wundern tut mich nur: ist das Verhalten wo dokumentiert? Kann man sich
> > darauf verlassen? In allen PHP Konstellationen?
>
> Jein. Dokumentiert ist nur die Ersetzung von Punkten, zumindest in
> <http://de.php.net/manual/en/language.variables.external.php>. Weiter
> habe ich nichts gefunden.

Wenn auch nicht an einer Stelle wo man als erstes schaut:
http://de.php.net/manual/en/faq.html.php#faq.html.form-image

Diesen Zusatz sollte man evtl. in der von dir genannte Manual-Seite mit
aufnehmen.

Gruß
Carsten

Am 07.11.2007, 17:17 Uhr, schrieb Joerg Behrens <behrens [at] takenet.de>:

>> Lass vor der Ausgabe htmlentities() oder htmlspecialchars()
>
> Auch da wuerde aus einem Leerzeichen erstmal ein Leerzeichen bleiben.
> Bringt also nix oder?
Autsch, hast recht. Das bringt dann nix. Aber mit urlencode oder
rawurlencode sollte es gehen.

>> drüberlaufen. (Alternativ geht auch urlencode).
>> Wenn der Nutzer Daten verändern kann, kann es allerdings auch zu
>> Fehlern kommen, spiel dir erst mal alle Möglichkeiten im Kopf durch.
>
> Niels hat es doch schon auf den Punkt gebracht.... und wenn man sch mal
> durchliest welche Zeichen in PHP fuer einen gueltigen $VAR Namen in
> Frage kommen ist damit zurechnen das es noch andere Zeichen treffen
> koennte.

Damit meinte ich eigentlich Fehler, die entstehen, wenn der Benutzer etwas
an den Werten ändern kann. Wenn ich vor der Ausgabe urlencode nutze und
die POST-Daten mit urldecode zurückverwandle kann es schon zu dem ein oder
anderen Fehler kommen, was man halt bedenken sollte (insofern würde ich
auch eher rawurlencode verwenden, %2B gibt normalerweise keiner ein).
[1][Ich weiß, das ganze ist nur ein würgaround. Aber manchesmal geht es
nicht anders]

Gruß
Chris

[1]
Benutzereingabe "Hallo + Welt".
urldecode -> "Hallo Welt"

Claus Reibenstein schrieb:
> werner bauer schrieb:

>> Leider haben wir nun Artikel mit Leerzeichen im Artikelnamen, der
>> generierte Htmlteil sieht dann so aus:

>> <input name='__artikel_mit zwei Leerzeichen' value='3'>

> Das ist zwar laut SelfHTML durchaus zulässig, hat in PHP aber Folgen:

Wen interressiert was laut SelfHTML zulässig ist? Relevant ist hier:

<http://www.w3.org/TR/html4/interact/forms.html#adef-name-INPUT>
<http://www.w3.org/TR/html4/types.html#type-cdata>

Thomas Hamacher schrieb:

> Claus Reibenstein schrieb:
>
>> werner bauer schrieb:
>>
>>> <input name='__artikel_mit zwei Leerzeichen' value='3'>
>>
>> Das ist zwar laut SelfHTML durchaus zulässig, hat in PHP aber Folgen:
>
> Wen interressiert was laut SelfHTML zulässig ist? Relevant ist hier:
>
> <http://www.w3.org/TR/html4/interact/forms.html#adef-name-INPUT>
> <http://www.w3.org/TR/html4/types.html#type-cdata>

Also hat SelfHTML Recht. War es das, was Du uns sagen wolltest?

Gruß. Claus

Claus Reibenstein schrieb:
> Thomas Hamacher schrieb:
>> Claus Reibenstein schrieb:
>>> werner bauer schrieb:

>>>> <input name='__artikel_mit zwei Leerzeichen' value='3'>
>>> Das ist zwar laut SelfHTML durchaus zulässig, hat in PHP aber Folgen:
>> Wen interressiert was laut SelfHTML zulässig ist? Relevant ist hier:

>> <http://www.w3.org/TR/html4/interact/forms.html#adef-name-INPUT>
>> <http://www.w3.org/TR/html4/types.html#type-cdata>

> Also hat SelfHTML Recht. War es das, was Du uns sagen wolltest?

Muss ich meine Frage präzisieren? SelfHTML interessiert nicht, wenn es
darum geht was in HTML zulässig ist und was nicht.

Thomas Hamacher schrieb:

> Claus Reibenstein schrieb:
>
>> Thomas Hamacher schrieb:
>>
>>> Wen interressiert was laut SelfHTML zulässig ist? Relevant ist hier:

Mich.

>>> <http://www.w3.org/TR/html4/interact/forms.html#adef-name-INPUT>
>>> <http://www.w3.org/TR/html4/types.html#type-cdata>
>>
>> Also hat SelfHTML Recht. War es das, was Du uns sagen wolltest?
>
> Muss ich meine Frage präzisieren?

Muss ich _meine_ Frage präzisieren?

Deine polemische Frage interessiert mich nicht. Es ist die _Aussage_,
auf die sich mein Posting bezieht.

> SelfHTML interessiert nicht, wenn es
> darum geht was in HTML zulässig ist und was nicht.

Dich vielleicht nicht, mich schon. Zumindest in erster Instanz.

SelfHTML ist eines der besten Nachschlagewerke, wenn es um HTML geht.
Die Sorgfältigkeit, mit der der Autor hier zu Werke geht, sucht
Ihresgleichen. Auch der oben diskutierte Sachverhalt ist in SelfHTML
absolut korrekt dargestellt.

Vor diesem Hintergrund verstehe ich Deine Aussage nicht, die ja nichts
anderes macht, als SelfHTML auch in diesem Punkt zu bestätigen.

Verstehst Du _jetzt_ meine Frage?

Gruß. Claus

Claus Reibenstein wrote:

>> SelfHTML interessiert nicht, wenn es
>> darum geht was in HTML zulässig ist und was nicht.
>
> Dich vielleicht nicht, mich schon. Zumindest in erster Instanz.

Warum das? Das Einzige was wichtig ist hat Thomas bereits gepostet. Mag
sein das Dir selfhtml gefällt. Das dort nicht alles so dokumentiert ist
wie bei W3C wurde schon oft in d.c.i.w.a.m. kurz angerissen. Also bleibt
als logische Konsequenz nur das Original.

Hier (technische Gruppe) sollte zu aller erst die Richtigkeit der
Aussagen gewichtet werden und nicht wers schöner aufbereitet hat.

Keine Frage, SelfHtml ist auch eine Instanz, nur halt nicht immer die
richtige.

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Claus Reibenstein schrieb:
> Thomas Hamacher schrieb:

>> SelfHTML interessiert nicht, wenn es
>> darum geht was in HTML zulässig ist und was nicht.

> SelfHTML ist eines der besten Nachschlagewerke, wenn es um HTML geht.

SelfHTML ist, wie du schon richtig schreibst, ein Nachschlagewerk und
keine Spezifikation. Einen Browserhersteller interessiert nicht im
geringsten, was laut SelfHTML "zulässig" ist.

Wenn du wissen willst, was in HTML zulässig ist, dann musst du in die
Spezifikation schauen und nicht in irgendwelche Nachschlagewerke, die
Fehler enthalten können, auch wenn sie noch so toll sind.

> Auch der oben diskutierte Sachverhalt ist in SelfHTML
> absolut korrekt dargestellt.

Reiner Zufall. Auch SelfHTML enthält Fehler.

> Vor diesem Hintergrund verstehe ich Deine Aussage nicht, die ja nichts
> anderes macht, als SelfHTML auch in diesem Punkt zu bestätigen.

Dann hast du mich missverstanden. Meine Aussage sollte lediglich klar
machen, dass SelfHTML *nicht* die HTML-Spezifikation ist und es von
daher völlig irrelevant ist, was laut SelfHTML in HTML /zulässig/ ist
und was nicht.

Thomas Hamacher schrieb:

> Claus Reibenstein schrieb:
>
>> SelfHTML ist eines der besten Nachschlagewerke, wenn es um HTML geht.
>
> SelfHTML ist, wie du schon richtig schreibst, ein Nachschlagewerk und
> keine Spezifikation.

Ich habe nie etwas Anderes behauptet.

> Einen Browserhersteller interessiert nicht im
> geringsten, was laut SelfHTML "zulässig" ist.

Ich bin aber kein Browserhersteller :-)

> Wenn du wissen willst, was in HTML zulässig ist, dann musst du in die
> Spezifikation schauen und nicht in irgendwelche Nachschlagewerke, die
> Fehler enthalten können, auch wenn sie noch so toll sind.

In den meisten Fällen reicht mir SelfHTML vollkommen. So auch in diesem.

>> Auch der oben diskutierte Sachverhalt ist in SelfHTML
>> absolut korrekt dargestellt.
>
> Reiner Zufall. Auch SelfHTML enthält Fehler.

Kein Zufall, sondern das Ergebnis sorgfältiger Recherche-Arbeit des
Autors. Dass in SelfHTML trotzdem Fehler enthalten sein können und
sicher auch sind, ist mir schon klar.

>> Vor diesem Hintergrund verstehe ich Deine Aussage nicht, die ja nichts
>> anderes macht, als SelfHTML auch in diesem Punkt zu bestätigen.
>
> Dann hast du mich missverstanden. Meine Aussage sollte lediglich klar
> machen, dass SelfHTML *nicht* die HTML-Spezifikation ist

Auch das ist mir klar.

Gruß. Claus

Claus Reibenstein schrieb:
> Thomas Hamacher schrieb:
>> Claus Reibenstein schrieb:

>>> SelfHTML ist eines der besten Nachschlagewerke, wenn es um HTML geht.
>> SelfHTML ist, wie du schon richtig schreibst, ein Nachschlagewerk und
>> keine Spezifikation.

> Ich habe nie etwas Anderes behauptet.

Wenn du schreibst, dass XYZ laut SelfHTML "zulässig" ist, dann bedeutet
das nichts anderes, als das du ein Nachschlagewerk hernimmst und daraus
(für dich) allgemeingültige Regeln ableitest. Für dich scheint das also
eine Spezifikation zu sein.

>> Einen Browserhersteller interessiert nicht im
>> geringsten, was laut SelfHTML "zulässig" ist.
>
> Ich bin aber kein Browserhersteller :-)

Das nicht, aber ich gehe mal davon aus, dass du Software entwickelst,
die in den Produkten eben dieser Browserhersteller laufen soll. Also
bringt es dir nichts in SelfHTML nachzuschlagen, ob irgendwas in HTML
zulässig ist. Es sein denn, du benutzt für deine Zwecke eine (eigene)
HTML-Implementation, die sich eben nach SelfHTML und nicht nach der
Spezifikation richtet.

>> Wenn du wissen willst, was in HTML zulässig ist, dann musst du in die
>> Spezifikation schauen und nicht in irgendwelche Nachschlagewerke, die
>> Fehler enthalten können, auch wenn sie noch so toll sind.

> In den meisten Fällen reicht mir SelfHTML vollkommen. So auch in diesem.

Das ist deine persönliche, unbegründete Meinung. Bei der Fragestellung,
ob XYZ zulässig ist oder nicht bringt das niemanden weiter.

>>> Vor diesem Hintergrund verstehe ich Deine Aussage nicht, die ja nichts
>>> anderes macht, als SelfHTML auch in diesem Punkt zu bestätigen.
>> Dann hast du mich missverstanden. Meine Aussage sollte lediglich klar
>> machen, dass SelfHTML *nicht* die HTML-Spezifikation ist

> Auch das ist mir klar.

Dann verstehe ich nicht, warum du schreibst, dass Leerzeichen in
Attributswerten laut SelfHTML /zulässig/ sind. Das hat überhaupt kein
Gewicht. Du hättest auch schreiben können, dass Leerzeichen in
Attributswerten laut dem Backbuch deiner Oma zulässig sind.

Aber ich glaube wir drehen uns im Kreis. Von daher EOD.

Thomas Hamacher schrieb:
> Claus Reibenstein schrieb:
>> Thomas Hamacher schrieb:

>>> Einen Browserhersteller interessiert nicht im
>>> geringsten, was laut SelfHTML "zulässig" ist.
>>
>> Ich bin aber kein Browserhersteller :-)
>
> Das nicht, aber ich gehe mal davon aus, dass du Software entwickelst,
> die in den Produkten eben dieser Browserhersteller laufen soll. Also
> bringt es dir nichts in SelfHTML nachzuschlagen, ob irgendwas in HTML
> zulässig ist. Es sein denn, du benutzt für deine Zwecke eine (eigen=
e)
> HTML-Implementation, die sich eben nach SelfHTML und nicht nach der
> Spezifikation richtet.

Doch, gerade dann. Im Gegensatz zur Spezifikation ist in SelfHTML auf
dokumentiert, welche Browser was unterstützen - schließlich hält si=
ch
kaum ein Browserhersteller an die Spezifikation. Das macht SelfHTML für=

mich zur Quelle Nr.1.

>> In den meisten Fällen reicht mir SelfHTML vollkommen. So auch in die=
sem.
>
> Das ist deine persönliche, unbegründete Meinung. Bei der Fragestell=
ung,
> ob XYZ zulässig ist oder nicht bringt das niemanden weiter.

Es interessiert nicht, ob etwas *zulässig* ist, sondern ob etwas
*funktioniert*.

> Dann verstehe ich nicht, warum du schreibst, dass Leerzeichen in
> Attributswerten laut SelfHTML /zulässig/ sind. Das hat überhaupt ke=
in
> Gewicht. Du hättest auch schreiben können, dass Leerzeichen in
> Attributswerten laut dem Backbuch deiner Oma zulässig sind.

Der Auslöser war wohl das Wort "zulässig". Ersetze "zulässig sein" =
durch
"funktionieren" und schon sind alle Unklarheiten beseitigt.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek schrieb:
> Thomas Hamacher schrieb:
>> Claus Reibenstein schrieb:
>>> Thomas Hamacher schrieb:

>>>> Einen Browserhersteller interessiert nicht im
>>>> geringsten, was laut SelfHTML "zulässig" ist.
>>> Ich bin aber kein Browserhersteller :-)
>> Das nicht, aber ich gehe mal davon aus, dass du Software entwickelst,
>> die in den Produkten eben dieser Browserhersteller laufen soll. Also
>> bringt es dir nichts in SelfHTML nachzuschlagen, ob irgendwas in HTML
>> zulässig ist. Es sein denn, du benutzt für deine Zwecke eine (eigene)
>> HTML-Implementation, die sich eben nach SelfHTML und nicht nach der
>> Spezifikation richtet.

> Doch, gerade dann. Im Gegensatz zur Spezifikation ist in SelfHTML auf
> dokumentiert, welche Browser was unterstützen - schließlich hält sich
> kaum ein Browserhersteller an die Spezifikation. Das macht SelfHTML für
> mich zur Quelle Nr.1.

Natürlich hält sich kein Hersteller zu 100% an die Spezifikation, aber
gerade in der hier diskutierten Fragestellung würde ich nicht darauf
vertrauen, dass es ja in Browser XYZ funktioniert, sondern mich an die
Spezifikation halten. Was bleibt einem anderes übrig?

Ich stimme dir und auch Claus natürlich zu, dass SelfHTML eine sehr
gute, vielleicht die beste HTML-Referenz ist. Und in diesem Fall stimmen
ja die Informationen in SelfHTML mit denen in der Spezifikation überein,
von daher passt's ja. In anderen Fällen stand in SelfHTML Stuss.

>>> In den meisten Fällen reicht mir SelfHTML vollkommen. So auch in diesem.
>> Das ist deine persönliche, unbegründete Meinung. Bei der Fragestellung,
>> ob XYZ zulässig ist oder nicht bringt das niemanden weiter.

> Es interessiert nicht, ob etwas *zulässig* ist, sondern ob etwas
> *funktioniert*.

Die Diskussion erinnert mich an dieser Stelle ein wenig an eine
Diskussion in d.c.l.javascript. Dort ging/geht es darum, ob man darauf
vertrauen kann, dass ein DOM-Element von einem Script erreichbar ist,
welches im Dokumentenbaum nach dem Element notiert wurde.

<p id="x">...</p>
<script ...>
document.getElementById('x')
</script>

Es funktioniert zwar de facto in allen Browsern, ist aber nirgends
spezifiziert. Verlasse ich mich jetzt darauf oder verzichte ich auf
diese Konstellation?

>> Dann verstehe ich nicht, warum du schreibst, dass Leerzeichen in
>> Attributswerten laut SelfHTML /zulässig/ sind. Das hat überhaupt kein
>> Gewicht. Du hättest auch schreiben können, dass Leerzeichen in
>> Attributswerten laut dem Backbuch deiner Oma zulässig sind.

> Der Auslöser war wohl das Wort "zulässig". Ersetze "zulässig sein" durch
> "funktionieren" und schon sind alle Unklarheiten beseitigt.

Ja. Denke schon.