日本語を出す方法がわかった
ていうか出ない理由がわかった。
鍵はstrlenである。
こいつがutf-8の文字列に対してバイト数じゃなくてカラム数を返していた。
例えば「漢」なら3が返ってくる必要があるのだけど2が返ってくる。
うまく行くときと行かないときがあるので不思議だったがついに原因解明した。
どうやったらvcのstrlenがUTF-8のマルチバイト文字に対して2を返すようになるのかということであるが、
これはソースコードをBOM付きｗのUTF-8で記述すればいい。
本来UTF-8にBOMなんか要らないのであるが、vcのコンパイラが腐っていて
BOM無しのUTF-8で記述したコードには以下のような警告が出る。
warning C4819: ファイルは、現在のコード ページ (932) で表示できない文字を含んでいます。データの損失を防ぐために、ファイルを Unicode 形式で保存してください。
警告だけなら無視すればいい(/wd4819とか)のだが特定のマルチバイト文字があるとコンパイルに失敗する。
日本語の文字列リテラルやコメントを書いているとわりと遭遇する。
で、これに対処する方法としてBOM付きUTF-8でコードを記述するという手があるのだが
そうすると正しくUTF-8として認識されて
strlenが親切にもバイト数じゃなくてカラム数を返してくれるという案配だ。
なんてこったｗ
そもそもコードをUTF-8で書いているのは他の環境と同じソースを使うためなのだが、
BOM付きUTF-8はgccではコンパイルできないというおまけつきである。
英語モードでcl.exeを動作させられればよさそうなのだけどいまのところ方法は知らない。
SJISモード？だとUTF-8で書いたコードは文字化けやエラーが出るので使い難い。
さしあたってはコードをASCIIのみで書いて、
UTF-8リテラルを外部から読み取るようにすることにした。
不便だ。
しかし、BOM付きUTF-8を使うの自体がおかしいような気もする。
UCS2あたりと誤認されているのか？
いずれにしろプリプロセッサが動く前に不思議変換が動作しているような気がするが・・・
ちなみにvimでは
set fenc=utf8 set bomb
とすればBOM付きutf-8の出来上がり。
ツールによっては見えない文字がエラーを引き起こす状態になるのでやめたほうがいい。
