【Lua】組み込み系言語総合 その2【Squirrel】
at TECH
417:デフォルトの名無しさん
09/11/16 17:13:46
>>415
Windowsは内部的には全部 Unicode で NTFS もUnicode。
Win32 API的には、Uincode な API と MBCS な API が両方同時に存在していて任意に選んで使う。
原理的にはエンコードが UTF-8 な Locale を指定すれば MBCS なAPIでそのまま使えるはずだが、
あいにくそんなロケールは定義されてない。もっとも、UTF-8 から Unicode へは単純に変換できるので、
Unicode な API をラッピングして使えば良いだけなので自前プログラム上で問題になることは特にはない。
自分のプログラムで文字列を char ベースで扱ってるなら、MFC の CString のような char <-> wchar_t 変換
対応したクラスを作ってAPI に渡す時はそれを介するようにしておけば良い
一般的にこの手の組み込み言語の場合「Unicode対応 」ってのはワイドキャラ化のこと。変換は全部入出力部で
処理してしまって、内部は全部 char ではなく wchar_t で処理を行うようにする。英数字もひらがなかたかな
漢字も同じ「1文字」として扱えるので、もろもろ概念や処理が楽になる。そのかわりメモリを喰らう。
Windows だと、Unicode な APIがあるのでこれで作業するのが定番。
UNIX 系OSは、Unicode API は存在してないので、API に渡す必要がある部分(ファイル名など)は
逆にMBCS に変換する必要があってそれなりに面倒だったりするが、これが C言語系における正道
「SJIS対応」だとパーサの類をいじって、\ とかの特殊文字のエスケープ対応を行う対応になる。
また、文字列系のクラスに、専用の mblen とか mbsubstr とかSJISとして1文字単位で扱える
専用の処理を足さないと実用上困る。正規表現系をまじめに対応とかすると死ねる。
「UTF-8対応」や「EUC対応」はASCII 的に安全な文字コードなのでパーサ部は通常いじる必要がないが、
文字列処理用に専用の命令系を足さないと実用性が低いのは SJIS対応と同じ。
古いプログラムを wchar_t 化するのは大変だけど、Unicode は扱いたい、といった場合にUTF-8 対応が行われる。
次ページ続きを表示1を表示最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4275日前に更新/247 KB
担当:undef