Documents aren't being sent with UTF-8 encoding.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a document with a string field that contains unicode characters. 
2. Save the document
3. Look at the document using futon, or re-read it

What is the expected output? What do you see instead?
Expect that documents will be saved properly; instead, documents lose the 
extended characters.  
Also, because of a bug in CouchDB, it may cause the server to be unresponsive 
after accessing a 
map/reduce view.

What version of the product are you using? On what operating system?
0.10.0.2, OSX 10.6

Please provide any additional information below.
Creating the StringEntity using the new StringEntity( body, CHARSET ) fixes the 
encoding.

Original issue reported on code.google.com by cory.hac...@gmail.com on 28 Oct 2009 at 8:03

[GoogleCodeExporter]

For some more background on the issue... 
http://issues.apache.org/jira/browse/HTTPCLIENT-536  At one point, 
StringEntity used the default platform encoding if one wasn't set ( it just 
uses String.getBytes() ), so this may 
behave differently depending upon the platform.

Original comment by cory.hac...@gmail.com on 28 Oct 2009 at 8:39

[GoogleCodeExporter]

Svenson already contained encoding tests and I just added another one to 
jcouchdb.. (
http://jcouchdb.googlecode.com/svn/trunk/test/org/jcouchdb/db/EncodingTestCase.j
ava ) 

works just fine..

Note that jcouchdb uses UTF-8 encoding. If your java source encoding is not 
UTF-8,
that might lead to problems like you describe. Either change your java source
encoding or use \uXXXX escaping like the test case.

There seems to be a problem with unicode in temp views, but I suspect the 
problem is
on the couchdb site, because jcouchdb sets the appropriate headers and all.

Original comment by ff...@gmx.de on 28 Oct 2009 at 10:06

• Changed state: Invalid

[GoogleCodeExporter]

What platform are you running your tests on?

Original comment by cory.hac...@gmail.com on 28 Oct 2009 at 11:10

[GoogleCodeExporter]

I am able to successfully run your unit test also.  Don't know why I can't get 
things through to CouchDB properly 
in my project except that I'm running from groovy / grails.  I have a test case 
similar to yours and the only way I 
can get it to save is to use the other StringEntity constructor.  I'll keep 
looking into this to see what I can find.

Original comment by cory.hac...@gmail.com on 29 Oct 2009 at 12:53

[GoogleCodeExporter]

I am running on Ubuntu Jaunty (unless I can install Karmic Koala.. YAY! couchdb
sweetness on teh ubuntu desktop)..

I also changed all calls to the two string constructor, because I had a problem 
with
literal umlauts (I'm German, so umlauts are my default test case) etc in source 
code,
too, with having set the encoding to UTF-8 (teh natural default for ubuntu). I 
still
don't understand that.. after all "\u00e4" should be exactly the same as "ä".

Original comment by ff...@gmx.de on 29 Oct 2009 at 8:13

[GoogleCodeExporter]

as a side note: the initial motivation to use only /uXXXX encoded unicode in the
tests was due to strange encoding problems on OS-X, making it not being able to 
run
the tests in spite of having the proper encoding specified.

Original comment by ff...@gmx.de on 29 Oct 2009 at 8:41

[GoogleCodeExporter]

Strange.  Thanks for making this change.  Any idea when you're going to do 
another release?  I would like to 
include these fixes officially included the next release of my grails plugin.

Original comment by cory.hac...@gmail.com on 29 Oct 2009 at 2:58

[GoogleCodeExporter]

Just to confirm this fix, I grabbed the latest changes and ran your test cases 
and everything worked except for 
MediaTypeUtilTestCase which is unrelated.  I also built a new jar and tried all 
of my test cases and they also 
worked.

Original comment by cory.hac...@gmail.com on 29 Oct 2009 at 3:15

[GoogleCodeExporter]

I can release a new version this weekend. 

Original comment by ff...@gmx.de on 30 Oct 2009 at 8:51