Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.0 Beta 2
-
None
-
None
-
Operating System: All
Platform: All
-
20813
Description
Each individual part in the 'multipart/form-data' encoded requests may have its
own content type definition. Within the content type definition the HTTP agent
may provide a character encoding to be used when processing the content of the
part in question. Currently FileUpload does not adequately support custom
character encoding of individual parts in the 'multipart/form-data' encoded
requests.
– RFC1867: Quote ------------
7. Registration of multipart/form-data
The media-type multipart/form-data follows the rules of all multipart
MIME data streams as outlined in RFC 1521
– RFC1867: End of quote -----
For more details refer to http://www.ietf.org/rfc/rfc1867.txt
– RFC1521: Quote ------------
7.1 The Text Content-Type
The text Content-Type is intended for sending material which is
principally textual in form. It is the default Content-Type. A
"charset" parameter may be used to indicate the character set of the
body text for some text subtypes, notably including the primary
subtype, "text/plain", which indicates plain (unformatted) text. The
default Content-Type for Internet mail is "text/plain; charset=us-
ascii".
– RFC1521: End of quote -----
For more details refer to http://www.ietf.org/rfc/rfc1521.txt
Of course, the agent does not have to set 'charset' parameter, but if it does,
the parameter must be taken into account.
Right now, method DefaultFileItem#getString() produces erroneous result (at
least in my humble opinion)