Open yumetodo opened 7 years ago
OneMojiBufはこちらのサウンドノベル風文字列描画基本を利用させて頂いてます。 http://dxlib.o.oo7.jp/dxprogram.html
文字化けなどが発生しているのは把握しています。 しかし、現状で有効な方策が思い当たらない状況ですね。
少し御時間頂いて、何か策がないか調べてみますね
いや、まあ解決策はあるんですが、だいぶ面倒なんですよね・・・。
一番わかり易いのは、内部的に全部UTF-32(正確には char32_t
型)で扱うようにすればいいんですが(どうせDxLibはcombining characterに対応していないので1codepoint=一文字であつかってしまってもいい)、
DxLibは内部的にUTF-16でAPIも wchar_t
型なので2重の変換が生じてしまいます。
つまりUTF-16で扱うのがかんたんということになるんですが、サロゲートペアの判定が必要なのでバグを作り込んでしまいそうで・・・。
いずれにせよ、
UNICODE
マクロを定義する(=文字セット:Unicode 文字セットを使用する)というBreaking Changeは必要かと思います。
ref
調べた中でよさそうだと思ったんですが、UTF-32だと二重の変換が発生するんですか……
うーん、となるとやはり
・読み込むファイルをすべてUTF-8もしくはUTF-8 with BOMにする ・UNICODE マクロを定義する(=文字セット:Unicode 文字セットを使用する)
を考える必要がありますか。
FAQ - Characters and Combining Marks http://unicode.org/faq/char_combmark.html#7
unicodeでの文字の扱いに関する説明ですね。読んでおきますね
4つの「文字」の定義についてですね・・・
ざっくりと読みましたが、unicodeにおける「文字」の定義ってこうなっているんですか……
のようなコードが見られるが、一文字が2要素だという保証は、文字コードをCP932と仮定してもどこにもない。そもそも1文字が固定長に収まることはありえない(Unicode対応するときはcombining characterも考慮する必要がある)
これはバグである。
ref