commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: FileUpload problem !!
Date Tue, 18 Jan 2005 01:11:53 GMT
On Mon, 17 Jan 2005 15:31:04 -0500, Wade Chandler
<wchandler@redesetgrow.com> wrote:
> Martin Cooper wrote:
> > On Mon, 17 Jan 2005 13:22:50 -0500, Wade Chandler
> > <wchandler@redesetgrow.com> wrote:
> >
> > <snip/>
> >
> >>What I'm saying is if you read getCharacterEncoding and it returns some
> >>multi-byte encoding calling setCharacterEncoding isn't going to change
> >>the encoding of the request body, and is going to break the file-upload
> >>components ability to parse the request body correctly as it will not be
> >>using the correct character encoding for the internal InputStreamReaders
> >>I'm sure it is using.  I've ran into this issue with readers and form
> >>content before.  Any file-upload developer have any input?
> >
> >
> > Yes, you're correct. Blindly calling setCharacterEncoding() is a bad
> > idea. You at least need to check that getRequestEncoding() returns
> > null first, and you need to be very sure that the request really does
> > use the encoding you set. (On the other hand, most browsers today do
> > not send content encoding information.)
> >
> > Note that Eric's code also invokes the getString() method with no
> > parameters, whereas, as I noted before, he needs to invoke the variant
> > that takes the encoding as a parameter. Fixing that alone will likely
> > get things working.
> >
> > --
> > Martin Cooper
> >
> >
> >
> >>Wade
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
> >
> 
> Looking at the code for FileUpload and how it gets it's headers one
> could also do
> diskFileUpload.setCharacterEncoding(request.getCharacterEncoding()) and
> then shouldn't have to worry about passing the encoding to getString
> because the strings should have been parsed out using substring calls on
> main header string that already had it's encoding set.

I assume you're referring to setHeaderEncoding(). This is different.
This is the encoding for header values themselves, not the encoding
used for the data in the parts. So you still need to invoke the
version of getString() that takes the encoding.

In some (rare) cases, the client may supply the encoding as a header
to each of the parts, in which case the zero-arg version of
getString() will work. Note, however, that most, if not all, browsers
don't do that. If you're using a client such as Commons HttpClient,
though, you can set things up to add encoding headers.

--
Martin Cooper


> Wade
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message