所以,我在imgui到科特林的端口中的以下字符遇到了一些问题–
在花了一整天的时间研究字符集和编码之后,我终于找到了我唯一的希望:依靠unicode代码点。
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
就我所读到的,看起来我们处于“扩展的Ascii”领域,这很糟糕,因为它似乎有不同的版本/解释。1270x7F
例如,此编码表与我的代码点不匹配,但 Cp1252 编码匹配,因此我倾向于认为这是 C 上实际使用的编码。
在刚才提到的链接底部的表格中,您实际上可以看到(小数,从右列与给定数字开始的计数)确实对应于(十六进制,我发现它有点不连贯,但无论如何)。1502013
为了解决这个问题,我试图将我在Kotlin上的s转换为相同的编码(暂时忽略这当然是特定于平台的),所以对于每个Stringc: Char
"$c".toByteArray(Charset.forName("Cp1252"))[0].toUnsignedInt
这有效,但会中断外来字体(如中文、日文等)的渲染。
所以,我的问题是:为什么在JVM和C上有什么区别?u2013u0096
哪种是正确的处理方法?
慕后森
相关分类