Итак, у меня возникли некоторые проблемы со следующим char –
в порту imgui до kotlin
Проведя целый день в кодировках и кодировках, я пришел к единственной надежде: полагаться на кодовые точки Юникода.
Этот символ на JVM
"–"[0].toInt() // same as codePointAt()
возвращает кодовую точку u2013
На C я не уверен, но так как это то, что делается сделано :
const ImFontGlyph* ImFont::FindGlyph(ImWchar c) const
{
if (c >= IndexLookup.Size)
return FallbackGlyph;
const ImWchar i = IndexLookup.Data[c];
if (i == (ImWchar)-1)
return FallbackGlyph;
return &Glyphs.Data[i];
}
Где
typedef unsigned short ImWchar
и
ImVector<ImWchar> IndexLookup; // Sparse. Index glyphs by Unicode code-point.
Итак, делая это
char* a = "–";
int b = a[0];
возвращает кодовую точку u0096
Насколько я читал, похоже, что 127
(0x7F
) мы находимся на территории "Расширенной Ascii", что плохо, потому что, похоже, существуют разные версии / интерпретации этого.
Например, эта таблица кодирования не соответствует моей кодовой точке, но Cp1252 кодировка соответствует, поэтому я склонен думать, что это то, что на самом деле используется на C.
В таблице внизу только что упомянутой ссылки вы можете увидеть, что 150
(десятичное число из правого столбца с указанным номером) действительно соответствует 2013
(шестнадцатеричное, я нахожу это немного несвязно, но все равно).
Чтобы решить эту проблему, я попытался преобразовать свои String
на Kotlin в ту же кодировку (игнорируя на данный момент, конечно, это зависит от платформы), поэтому для каждого c: Char
"$c".toByteArray(Charset.forName("Cp1252"))[0].toUnsignedInt
Это работает, но нарушает рендеринг для иностранных шрифтов, таких как китайский, японский и т. Д.
Итак, мой вопрос: почему разница между u2013
на JVM и u0096
на C?
Какой правильный способ справиться с этим?