Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Isn't the C API creator willing to take step back and reimplement with <strong>UTF-8</strong>? :) Your work would essentialy disappear, needing only <code>GetStringUTFChars</code>/<code>NewStringUTF</code>. </p> <p><code>jchar</code> is typedefed to <code>unsigned short</code> and is equivalent to JVM <code>char</code> which is <strong>UTF-16</strong>. So on Windows where <code>wchar_t</code> is 2 bytes <strong>UTF-16</strong> too, you can do away with the code you presented. Just copy the raw bytes around, allocate accordingly. Don't forget to free after you're finished with the C API call. Complement with <code>NewString</code> for conversion back to jstring.</p> <p>The only other <code>wchar_t</code> size i am aware of is 4 bytes (most prominently Linux) being <strong>UTF-32</strong>. And here comes the problem: <em>UTF-32 is not just UTF-16 somehow padded to 4 bytes.</em> Allocating double the amount of memory is just a beginning. There is a substantial conversion to do, <a href="http://gears.googlecode.com/svn/trunk/third_party/convert_utf/ConvertUTF.c" rel="nofollow">like this one which seems to be sufficiently free</a>. </p> <p>But if you are not after performance that much and are willing to give up the plain memory copying on Windows, i suggest going <code>jstring</code> to UTF-8 (which is what JNI provides natively with documented functionality) and then UTF-8 to UTF-16 or UTF-32 depending on <code>sizeof(wchar_t)</code>. There won't be any assumptions about what byte order and UTF encoding each platform gives. You seem to care about it, i see that you are checking <code>sizeof(jchar)</code> which is 2 for the most of the visible universe :)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload