I've even specified the accept-charset to be UTF-8, to deal withthings like accentuated characters, but it seems there's an encodingproblem somewhere, as the characters I get are interpreted as isolatin (as far as I can see).

However, everything is configured for UTF-8 everywhere:- my html file is encoded in UTF-8- it specifies a meta attribute: <meta http-equiv="content-type"content="text/html; charset=utf-8" />- jetty does send the page encoded as UTF-8

But... the input fields I get are showing weird characters as soon asnon-ASCII characters are used in my input field.

Has anybody faced a problem like this when uploading files to theblobstore with accompanying text fields?

Thanks a lot for the pointer!Using a specific filter for that purpose seems like a good idea.

As you mentioned it, I've also added the <%@ page pageEncoding="UTF-8"contentType="text/html;charset=UTF-8"%> directive too, but it didn'tchange anything.

I've not tried the filter idea yet, as I had a workaround.But I've got the feeling I'm missing something somewhere.All the knobs I could think of seem to indicate UTF-8 (even what I seethrough the response Jetty sends), so this is really weird.

Perhaps it could be a problem with App Engine's /_ah/upload servletwhich does something weird with the fields before returning them to myown controller.

Interestingly... it illustrates yet another difference between the dev mode and deployed mode.

On the local development server, I have this encoding issue, that when I upload a form containing a file for the blobstore and a text field, the field is wrongly encoded, so I have to use a hack to decode as ISO-8951 and re-encode as UTF-8.

BUT when I deploy my application on Google App Engine, the problem isn't present there, and my hack wrongly decode/re-encode the text fields.

So locally, I need my hack, and remotely, I don't.

I'm going to have to do some local branching like if (localMode) { ... } else { ... }

This would be good if we could remove such differences between local and prod environments.

Is it possible for you to use WireShark or a logging proxy to capturethe actual HTTP session?

When parsing the multipart/form-data response from the browser we lookat the charset attribute on each individual mime part, and if it ismissing we assume ISO-8859-1. I suspect that's biting you here, butit's not clear to me where we should be getting the fallback charsetif the browser isn't setting it on each part.

As for seeing the relevant code, we have a mechanism in place to beginopen-sourcing parts of the SDK. We will be doing this gradually overseveral releases, but I will see if we can start with this code.