所以，我在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哪種是正確的處理方法？
1 回答
慕后森
TA貢獻1802條經驗 獲得超5個贊
目前我在Windows上解決了這個問題，我在檢索字符代碼點之前插入了這個函數。它基本上重新映射了所有與ISO-8859-1不同的字符。你可以在這個表格中看到它們，它們都是那些帶有淺灰色邊框的人。
internal fun Char.remapCodepointIfProblematic(): Int {
val i = toInt()
return when (Platform.get()) {
/* https://en.wikipedia.org/wiki/Windows-1252#Character_set
* manually remap the difference from ISO-8859-1 */
Platform.WINDOWS -> when (i) {
// 8_128
0x20AC -> 128 // €
0x201A -> 130 // ?
0x0192 -> 131 // ?
0x201E -> 132 // ?
0x2026 -> 133 // …
0x2020 -> 134 // ?
0x2021 -> 135 // ?
0x02C6 -> 136 // ?
0x2030 -> 137 // ‰
0x0160 -> 138 // ?
0x2039 -> 139 // ?
0x0152 -> 140 // ?
0x017D -> 142 // ?
// 9_144
0x2018 -> 145 // ‘
0x2019 -> 146 // ’
0x201C -> 147 // “
0x201D -> 148 // ”
0x2022 -> 149 // ?
0x2013 -> 150 // –
0x2014 -> 151 // —
0x02DC -> 152 // ?
0x2122 -> 153 // ?
0x0161 -> 154 // ?
0x203A -> 155 // ?
0x0153 -> 156 // ?
0x017E -> 158 // ?
0x0178 -> 159 // ?
else -> i
}
else -> i // TODO
}
}
添加回答
舉報
0/150
提交
取消