Какое правильное сопоставление JNA для UniChar в Mac OS X? - PullRequest
Новая
       4

Какое правильное сопоставление JNA для UniChar в Mac OS X?

3 голосов
/ 20 октября 2010

У меня есть такая структура C: 

struct HFSUniStr255 {
    UInt16 length;
    UniChar unicode[255];
};

Я сопоставил это ожидаемым образом: 

public class HFSUniStr255 extends Structure
{
    public UInt16 length; // UInt16 is just an IntegerType with length 2 for convenience.

    public /*UniChar*/ char[] unicode = new char[255];
    //public /*UniChar*/ byte[] unicode = new byte[255*2];
    //public /*UniChar*/ UInt16[] unicode = new UInt16[255];

    public HFSUniStr255()
    {
    }

    public HFSUniStr255(Pointer pointer)
    {
        super(pointer);
    }
}

Если я использую эту версию, я получаю каждый второй символстрока в моем char [] («aits D» для «Macintosh HD».) Я предполагаю, что это как-то связано с работой на 64-битной платформе и JNA, отображающей значение в 32-битный wchar_t, но затем прерывая16 старших бит на каждом wchar_t при их копировании обратно.

Если я использую версию byte [], я получаю данные, которые правильно декодируются с использованием кодировки UTF-16LE.

Если я используюверсия UInt16 [], я получаю правильную кодовую точку для каждого символа, но тогда неудобно преобразовывать их обратно в строку.

Есть ли способ, которым я могу определить свой тип как char [], и все жеон правильно конвертируется?

1 Ответ

0 голосов
/ 24 декабря 2010

Я так не думаю, потому что char - это декодированная последовательность байтов.

Именно поэтому ваша байтовая версия работает как брелок с руководством декодированием

Если вы хотите придерживаться символов, я предлагаю:

  • вы подключаете JNA с помощью декодера
  • или преобразуйте числовую форму ваших символов из UTF-16LE, которую вы получите, во внутреннюю кодировку JVM, которая является Unicode

К сожалению, я не знаю простой способ сделать любой из двух.

Мое мнение: придерживайтесь byte[] verion

Кстати, как вы создали свой UInt16 класс?

...