Posted by Jukka K. Korpela on 05/19/06 20:42

Yohan N. Leder <ynleder@nspark.org> scripsit:

>> Why didn't you summarize which answers you got there?
>
> Better than a summary, which would be false, by design, here is the
> url
>> http://minilien.fr/a0juc6

Why would a summary be false? If _you_ did not understand the answers well
enough to summarize them for us, is each of us expected to read through
them.

> Sorry, but sometimes, you've not any time and have to try taking some
> shortcuts... However, "pb" is a well known abbreviation in French

You were already informed about the unsuitability of such jargon in the
discussion you refer to, and _yet_ you kept using it. A less mild-mannered
man than I am would lose patience here.

>> Your script name is irrelevant. What would matter is an absolute URL
>> that would let us see the problem in action.
>
> form2dump means "it's a form submission for which I'm observing what
> is received by the server".

No, it's just the name you gave.

>>> # 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?
>
> No, I've only one problem : "euro sign in any form field corrupt
> beginning of sent multipart/form-data (in detail : first lines
> containing boundary and declaration of the first field are truncated)"

You managed to give the impression of two distinct problems. Whether the
euro sign and the checkbox are related remains to be seen.

Next time, please start from a simple prose description of what you wanted
to achieve, exactly how it failed, and what's the URL that lets other see
it.

>> 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).
>
> Nevertheless, when I'm trying to submit a form with "accept-
> charset='utf-8'" in an HTML page which has a content-type indicating a
> character set as "charset=iso-8859-1", the fields data are well
> transmitted in an UTF-8 format.

This was new to me. Apparently IE 6 and IE 7 beta (at least) seem to honor
the accept-charset attribute to some extent, though not to the extent of
actually declaring the encoding in the form data set.

I don't think this changes the big picture, though. If you ask for
iso-8859-1 data transmission, as you explicitly do, you cannot really blame
anyone else when characters outside the iso-8859-1 repertoire cause some
trouble.

>> Anyway, it is an error condition with no prescribed error
>> processing.
>
> Considering the station on which I've done my own test, it's not what
> I've seen.

What you have seen is one particular error processing. It does not disprove
the statement that you have created an error condition.

> Also, I'm rewriting an explanation of the problem for which I'm
> searching for a solution : "euro sign in any form field corrupt
> beginning of sent multipart/form-data (in detail : first lines
> containing boundary and declaration of the first field are truncated".

Again, you are complaining about error processing in a situation where no
particular error processing is required by the specifications.

Besides, I was unable to observe the problem you describe. Your code for
dumping raw data doesn't produce particularly readable output (I don't see
line breaks).

> And to finish : of course, I could use UTF-8,

Well, that would be the solution, apparently. How you would implement it
depends on your authoring environment.

[Back to original message]