Erste echte UTF-8-Zeichen in Java-JNI

Gibt es eine einfache Möglichkeit zur Konvertierung einer Java-string zu einem echten UTF-8-byte-array im JNI code?

Leider GetStringUTFChars() fast tut, was erforderlich ist, aber nicht ganz, es gibt eine "modifizierte" UTF-8-byte-Sequenz. Der Hauptunterschied ist, dass eine modifizierte UTF-8 enthält keine null-Zeichen (so dass Sie behandeln können, ist eine ANSI-C-null-terminated string), sondern ein anderer Unterschied scheint zu sein, wie Unicode-Sonderzeichen wie emoji behandelt werden.

Ein Zeichen wie U+1F604 "LÄCHELNDES GESICHT MIT OFFENEM MUND UND LÄCHELNDEN AUGEN" gespeichert ist, als ein Surrogat-paar (zwei UTF-16-Zeichen U+D83D U+DE04) und hat einen 4-byte-UTF-8 äquivalent F0 9F 98 84, und das ist die byte-Sequenz, die ich bekomme, wenn ich konvertieren Sie die Zeichenfolge in UTF-8 in Java:

    char[] c = Character.toChars(0x1F604);
    String s = new String(c);
    System.out.println(s);
    for (int i=0; i<c.length; ++i)
        System.out.println("c["+i+"] = 0x"+Integer.toHexString(c[i]));
    byte[] b = s.getBytes("UTF-8");
    for (int i=0; i<b.length; ++i)
        System.out.println("b["+i+"] = 0x"+Integer.toHexString(b[i] & 0xFF));

Der obige code druckt die folgenden:

?
c[0] = 0xd83d
c[1] = 0xde04
b[0] = 0xf0
b[1] = 0x9f
b[2] = 0x98
b[3] = 0x84

Allerdings, wenn ich pass 's' in eine native JNI-Methode, und rufen GetStringUTFChars() bekomme ich 6 bytes. Jeder der die ersatzzeichenpaare wird umgebaut zu einem 3-byte-Sequenz unabhängig:

JNIEXPORT void JNICALL Java_EmojiTest_nativeTest(JNIEnv *env, jclass cls, jstring _s)
{
    const char* sBytes = env->GetStringUTFChars(_s, NULL);
    for (int i=0; sBytes[i]!=0; ++i)
        fprintf(stderr, "%d: %02x\n", i, sBytes[i]);
    env->ReleaseStringUTFChars(_s, sBytes);
    return result;
}

0: ed
1: a0
2: bd
3: ed
4: b8
5: 84

Den Wikipedia UTF-8 Artikel deutet darauf hin, dass GetStringUTFChars() eigentlich zurück CESU-8 anstatt UTF-8. Das wiederum bewirkt, dass meine native Mac-code zum Absturz bringen, weil es keine gültige UTF-8-Sequenz:

CFStringRef str = CFStringCreateWithCString(NULL, path, kCFStringEncodingUTF8);
CFURLRef url = CFURLCreateWithFileSystemPath(NULL, str, kCFURLPOSIXPathStyle, false);

Ich nehme an, ich könnte alle meine JNI-Methoden nehmen ein byte[] statt String und tun die UTF-8 Konvertierung in Java, aber das scheint ein bisschen hässlich, gibt es eine bessere Lösung?

InformationsquelleAutor Rolf | 2015-08-25

29

Dies ist klar und deutlich erklärt, in der Java-Dokumentation:

JNI-Funktionen
GetStringUTFChars
```
const char * GetStringUTFChars(JNIEnv *env, jstring string, jboolean *isCopy);
```
Gibt einen Zeiger auf ein array von bytes, die die Zeichenfolge im modifizierten UTF-8-Codierung. Dieses array ist gültig bis es ist veröffentlicht von ReleaseStringUTFChars().
Modifiziertes UTF-8

Die JNI verwendet eine modifizierte UTF-8-Zeichenfolgen darstellen, die verschiedenen string-Typen. Modifizierte UTF-8-Zeichenfolgen sind die gleichen wie diejenigen, die von der Java-VM. Modifizierte UTF-8-strings codiert, so dass Zeichenfolgen, die nur nicht-null-ASCII-Zeichen dargestellt werden kann, nur mit einem byte pro Zeichen, aber alle Unicode-Zeichen dargestellt werden können.

Alle Zeichen im Bereich von \u0001 zu \u007F sind vertreten durch ein einzelnes byte, wie folgt:

Die sieben bits von Daten in den byte geben den Wert des Zeichens dargestellt.

Dem null-Zeichen ('\u0000') und Zeichen in den Bereich '\u0080' zu '\u07FF' dargestellt durch ein paar von bytes x und y:

Der bytes für das Zeichen mit dem Wert ((x & 0x1f) << 6) + (y & 0x3f).

Zeichen im Bereich '\u0800' zu '\uFFFF' werden vertreten durch die 3 Byte für x -, y -, und z:

Dem Zeichen mit dem Wert ((x & 0xf) << 12) + ((y & 0x3f) << 6) + (z & 0x3f) wird vertreten durch den bytes.

Zeichen mit der code-Punkte über U+FFFF (so genannte Ergänzende Zeichen) vertreten sind GESONDERT zu Kodieren die beiden surrogate code units Ihrer UTF-16-Darstellung. Jeder der surrogate code units ist vertreten durch drei bytes. Dies bedeutet, Ergänzende Zeichen werden dargestellt, die von sechs bytes, u, v, w, x, y, und z:

Dem Zeichen mit dem Wert 0x10000+((v&0x0f)<<16)+((w&0x3f)<<10)+(y&0x0f)<<6)+(z&0x3f) wird vertreten durch die sechs bytes.

Der bytes des multibyte-Zeichen werden in der Klasse gespeichert Datei im big-endian (high-byte first) zu bestellen.

Es gibt zwei Unterschiede zwischen diesem format und dem standard UTF-8-format. Den ersten, den null-Zeichen (char)0 verschlüsselt, wobei die zwei-byte-format statt der ein-byte-format. Dies bedeutet, dass die modifizierte UTF-8-strings nie mit eingebetteten null-Werte. Zweite, nur den ein-byte, zwei byte, und die drei-byte-Formate der standard UTF-8 verwendet werden. Die Java-VM nicht erkennt das vier-byte-format-standard UTF-8; es verwendet seine eigene zwei-mal-drei-byte-format statt.

Für weitere Informationen über die standard-UTF-8-format, siehe Abschnitt 3.9 Unicode-Codierungen Der Unicode-Standard, Version 4.0.

Da U+1F604 ist eine Ergänzende Charakter-und Java unterstützt keine UTF-8-4-byte-encoding-format, U+1F604 ist vertreten im modifizierten UTF-8 als Kodierung UTF-16-ersatzpaar U+D83D U+DE04 mit 3 Byte pro Surrogat, also 6 bytes insgesamt.

Also, um deine Frage zu beantworten...

Gibt es eine einfache Möglichkeit zur Konvertierung einer Java-string zu einem echten UTF-8-byte-array im JNI code?

Können Sie entweder:
1. Verwenden GetStringChars() um die ursprüngliche UTF-16-codierte Zeichen, und dann erstellen Sie Ihre eigenen UTF-8-byte-array ab. Die Konvertierung von UTF-16 zu UTF-8 ist ein sehr einfach-Algorithmus zu implementieren, indem Sie von hand ein, oder verwenden Sie eine bereits bestehende implementation von Ihrer Plattform oder 3rd-party-Bibliotheken.
2. Haben Ihre JNI-code-Aufruf wieder in Java aufrufen, die - String.getBytes(String charsetName) Methode zur Kodierung der jstring Objekt in eine UTF-8-byte-array, z.B.:
```
JNIEXPORT void JNICALL Java_EmojiTest_nativeTest(JNIEnv *env, jclass cls, jstring _s)
{
    const jclass stringClass = env->GetObjectClass(_s);
    const jmethodID getBytes = env->GetMethodID(stringClass, "getBytes", "(Ljava/lang/String;)[B");

    const jstring charsetName = env->NewStringUTF("UTF-8");
    const jbyteArray stringJbytes = (jbyteArray) env->CallObjectMethod(_s, getBytes, charsetName);
    env->DeleteLocalRef(charsetName);

    const jsize length = env->GetArrayLength(stringJbytes);
    const jbyte* pBytes = env->GetByteArrayElements(stringJbytes, NULL); 

    for (int i = 0; i < length; ++i)
        fprintf(stderr, "%d: %02x\n", i, pBytes[i]);

    env->ReleaseByteArrayElements(stringJbytes, pBytes, JNI_ABORT); 
    env->DeleteLocalRef(stringJbytes);
}
```
Den Wikipedia-UTF-8-Artikel deutet darauf hin, dass GetStringUTFChars() eigentlich zurück CESU-8 anstatt UTF-8

Java ' s Modified UTF-8 ist nicht genau das gleiche wie CESU-8:

CESU-8 ist ähnlich zu Java ' s Modified UTF-8 ist aber nicht die spezielle Kodierung der Zeichen NUL (U+0000).
- Irgendwelche Hinweise, wie das zu erreichen ist das Umgekehrt? Konvertierung von nativen char* ("Hello ?"), um Java-string?
- vorausgesetzt, die char* Punkte zu wahren UTF-8-Daten und nicht "geändert" UTF-8 Daten, 1) manuell Dekodieren von UTF-8 nach UTF-16 und dann übergeben, die JNI NewString() Funktion, oder 2) mit JNI zu kopieren char Daten auf einem Java - byte[] array und übergeben, die String Konstruktor, eine byte[] - und charset-name als Eingabe die Angabe "UTF-8" als Zeichensatz.
- Wenn die char* Punkte auf "modifiziert" UTF-8-Daten, dann können Sie einfach die JNI NewStringUTF() Funktion durch sich selbst.
- Danke. Er arbeitete mit option 1 für mich.
InformationsquelleAutor Remy Lebeau

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.