|
|
Posted by Jukka K. Korpela on 05/19/06 08:33
Yohan N. Leder <ynleder@nspark.org> scripsit:
> Hoping it will match the alt.html group, because already tried in
> comp.lang.perl.misc but it seems to be more related to browser and
> multipart/form-data posting.
Why didn't you summarize which answers you got there?
Is there any reason to think that your problem is the least connected with
how the form is _generated_ (e.g., Perl code)? That is, did you even try
what happens if you simply use a static HTML document containing the form
that the script generates? You would then could have posted the URL of that
document, so that we would have a simpler manifestation of your problem.
> Well, what do you think about the pb explained
y do u use silly abbrs? It saves a few seconds of your time and wastes other
people's time when they try to decipher your private codes. pb = problem
ain't no std abbr.
> in this test script called form2dump.pl :
Your script name is irrelevant. What would matter is an absolute URL that
would let us see the problem in action.
Describing your _problem_ in program code comments (in sloppy style) is not
a good approach. You are not helping us to help you.
> # Script written to solve the bug explained below :
Huh? How is the script supposed to solve "the bug"? And why the singular,
when you clearly have two problems?
> # PB : ? sign in any form field corrupt beginning of
> multipart/form-data
Which "? sign". Your Usenet message does not declare its character encoding,
thereby implying ASCII, so you cannot insert the euro sign there, as you
probably tried (guessing from the Subject line).
The real problem is that there is no specification of what happens when the
user types in a character that cannot be represented in the character
encoding used for the form, which is the same as the encoding of the page
(note that browsers ignore accept-charset attributes). When the encoding is
iso-8859-1 and the user types in the euro sign, the browser might (for
example) ignore it or - strangely, but perhaps usefully in some cases -
represent it as an entity reference € or some other way. Anyway, it is
an error condition with no prescribed error processing.
The lesson is that using iso-8859-15 instead, in addition to being a wrong
move in general as Alan explained, would not help against all _other_
characters that people may enter, even if it "worked" in some circumstances.
You cannot prevent people from entering arbitrary data through your form;
you can just process it the best you can.
If you expect "any characters", then the logical move is to use utf-8.
Naturally, your form handler then needs to be able to process utf-8 encoded
data. In practice, you need a suitable library module for the job.
> # in STDIN (1st lines with boundary & 1st
> field declar truncated) # CAUSE : checkbox without any value
> (uncheckd) cause this pb # - without <input type='checkbox'
> name='chk'>, it works # - with <input type='checkbox' name='chk'>
> checked, it works # NB : strange because an unchecked box shouldn't
> be sent ! # IDEA : I've tried to provide an hidden field with same
> name as # checkbox which would submit an 'off' value when
> checkbox is # unchecked, but both values are sent when checkbox
> is checked # SOL : ?
Apparently my newsreader got wild when quoting your program code commens.
I'm not going to fix it.
You're telling that "it works" both ways, whether the checkbox is checked or
not. You are not telling why it is a problem that it works. Neither are you
telling what you really mean by "it works" and how we can decide whether "it
works" or not.
However, from past experience with similar-sounding problems, I suppose you
have just not understood how checkboxes work in HTML form data processing.
When a checkbox is checked upon submission, a name=value pair is generated;
if it is not, no such pair is generated. This is how things were designed to
work; live with it. This means in practice that your form handler needs to
check for the _presence_ of a name=value pair with the name of the checkbox,
and treat its absence as indicating that the checkbox was not checked.
Navigation:
[Reply to this message]
|