忙しい人のための結論

UnityのスクリプトファイルをBOM付きUTF-8でなければ、スクリプト内で日本語を扱えない。

エディタで生成した場合はBOM付きになっているけれど、例えば外部のエディタを使った作ったり、自動生成したファイルだとただの UTF-8 になっていてハマる可能性がある。

解決策はスクリプトファイルを常にUTF-8(BOM付き)に保つ方法 - 強火で進めが参考になる。

Assets/Editor/AssetPostprocessUTF8Encode.cs を作ってこれを配置する。

これでスクリプトが Unity に取り込まれる時に勝手に BOM付きUTF-8 にしてくれる。

べんり。

駄文

仕事ではクライアント側を Unity、サーバー側を Rails でスマートフォン向けのゲームの開発を行っている。この2者の通信部分は前回のプロジェクトで異常に苦労して発狂して死んだ。

今回は同じ轍を踏まないように通信部分は自動生成にして人間が触らないようにした。ついでにレスポンスのモックも自動生成しておいて、通信できない環境でも実機でテストできるようにしてある。

これは非常にべんりで久しぶりに胸をはって自画自賛できる出来だと思っている。だいたいは作った瞬間は自画自賛しているけど、自分でもあんまり使わないしあとで結構困ったりするのだけれど、いまのところはうまくいっているし、最近プロジェクトに参加した同僚にも使ってもらって一回ペアプロしただけで次のペアプロではふつうに使ってもらえてた。

まあ自画自賛はここまでにして今回の本題。

さっきちょっと触れたモックレスポンスの部分だけれど、ここに日本語のデータが入っているときに問題がおきた。どうしても日本語が化けるのである。そして発狂しそうなことに同じコードを別のファイルに貼り付けて動かすと化けないのだ。

とりあえず一旦ファイルを消して、エディタから新規で作成してコードだけをコピペしてやると動く。ここで diff をみたらファイルの先頭に見慣れない <U+FEFF> が。前からたまに見かけていたのでただのゴミが入っているのかと思ってたが、変更点はここしかなかったので検索してみる。

すると BOM についての記事が見つかった。よくBOMがどうとかとう話は聞いていたが、どんなものかを把握していなかったので、なるほどこれが！という変な感動があった。エンジニアとしては最悪な感じだけど、最初から知っている人はいないので、最近はあまり気にしないことにしている。自己肯定しないと死ぬことが去年の教訓。

BOMという知識を得たので Unity BOM とかで検索するとずばりの記事が出てきたので、解決策を試したらうまくいった。

自動生成時にBOM付きにする方法も考えたけど、自動生成するときに一旦全てのファイルを消す方式を取っていたので、1つエディタ拡張を追加するだけで対応できるこちらの方が手軽だったので採用した。

スッキリしたので push して帰る。

ここまで書いておいて U+FEFF が入るのは UTF-16 じゃないのかということに気付いた。文字コード詳しくないのちょっと厳しい気がしてきた。