ちょっと考える
とりあえずboost::filesystemにUTF-8を突っ込んで、ファイル操作を行う段階で処理系デフォルト文字コードに変換しなおす、という方向で問題ないようだが、operation.hppに定義されているファイル操作関数を使えないのはイタイので、m_path_append()でUTF-8エンコード、native_file_string(), leaf()メンバ関数あたりでUTF-8デコードするように書き換えたい。そうなるとUTF-8のエンコード/デコードルーチンをどこで調達するかという話しになるんだけど…。
とりあえず普通に考えるとワイド文字(==UCS-4 or UCS-2 or Unicodeという認識でいいのかしら?)を噛ませるのが妥当だと思うんだけど、C++でマルチバイト<-->ワイド文字変換を行う場合、現在以下の選択肢がある。
- setlocale() + mbstowcs()/wcstombs() (C標準)
- std::codecvt (C++標準)
- WinAPI(Windowsのみ)
- iconv(主にPOSIX?)
- ICU
で、C標準のアプローチだとスレッドセーフティではない。が、マルチロケールでグリグリ変換するとかじゃない限りあまり問題にはならない、かな?でもグローバルなロケールを弄ることなく変換を行えるC++標準で行きたい…。んだけど、少なくともVC++6.0ではstd::codecvtの実装がおかしい(標準に準拠してない)みたいなのでマクロで切り分けないといけない。
WindowsではMultiByteToWideChar()/WideCharToMultiByte()でロケールを意識することなく、変換を行うことができる。そしてPOSIXでは文字コード変換ならiconvを使え!ってくらい浸透してる(みたい)。ということはWindowsではWinAPIを、POSIXではiconvを使うように切り分ければいいのかな?
最後に、ICUが何も考えずにいけると思うんだけど、そもそもライブラリを書き換えるのに他のライブラリを使うってのもナー…。ライセンスとか確認して大丈夫そうならこれが最短。
というか文字コードの変換に関しては、あまりにも環境によって違いが出てくるのでもうやめようかと思った。調べれば調べるほどやる気がそがれていくよorz