- ベストアンサー
UNICODE対応にするメリットは?
VisualStudio2005 VC++を用いたアプリケーション開発に、今まではマルチバイト文字を使ってきたのですが、時代の流れとしてはUNICODEに移行すべきなのかな、と漠然と思っています。 ここで疑問なのですが、ずばりUNICODEに移行するメリットは何でしょう? 今のままマルチバイトを使っていても困ることは無いような気がしますし、日本語版・英語版の両方をリリースする場合もリソースの言語切り替えで対応できていますので、UNICODEにどのような利点があるのか、いまひとつピンときません。
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
マルチバイト文字がなくなってしまうからです。 ただ、2008で、完全に使えなくなってしまう、という話は聞きませんし、特に難しい問題ではないので、いそいでユニコードに移行する必要もないのではないでしょうか。 また、2005+VISTA+ユニコードの組み合わせだと、いろいろバグが出ます。 マイクロソフトは、どうもこのまま「とぼけて」2008に移行してしまうハラのようです。 なんだか2バイトでも世界中の文字をカバーできないそうで、4バイト文字なんてのも出てきているようです。 ユニコードが定着した頃に、次の規格が出てきそうな、いかがわしさもあります。
その他の回答 (2)
- Tacosan
- ベストアンサー率23% (3656/15482)
ど~なんでしょ. 「システムが (内部的に) UNICODE を使う (ようになる) から, それにあわせておいた方が楽かもしれない」くらいしか想像できない. 以下おまけ: UNICODE はもともと 16bit だったんだけど, さすがに足りないことが明白となったので 21bit (u+000000~u+10FFFF) になりました. これ以上は増えないことになっているはずです. なお, u+0F0000 以降は外字用で, UNICODE で規定されるのは u+0EFFFF までだったような気がします. あと, UNICODE は「世界で使われる文字を収録する」規格であることに注意する必要があるかもしれません. 文字集合だから「文字を収録する」のは当然なんですが, これが「多言語対応」とは直結しない, ということが忘れられているように感じるときがあります. 有名なのは CJK(TVS) のユニフィケーションですが, よ~く見るとその他にも小ネタはいくつかあったりします.
お礼
回答ありがとうございます。 『「システムが (内部的に) UNICODE を使う (ようになる) から, それにあわせておいた方が楽かもしれない」くらいしか想像できない』 この点は、私の抱いているイメージとほぼ同じです。 「多言語対応」が楽になるのかな、とも思ったのですが、そうでもないような気もして。 今までの回答を拝見すると、やっぱり、いまひとつUNICODE対応のメリットが見えてこないですね。 # もしかしたら、まだ回答がいただけるかもしれないので、もうしばらくだけ締め切りは延ばさせていただきたいと思っています。
- MrBan
- ベストアンサー率53% (331/615)
「切り替えて…」ではなく「同時に混ぜて…」対応すると、 UNICODEの方が楽だから、じゃないですかね。 後は、NT以降、Windows内部はUNICODEになってますから、 MBCS/ASCII版のWin32APIは2000やXP上では変換の分だけ、 若干処理が遅いとか…(まぁ普通は気づかない範囲で、だと思いますが) 何でもUNICODEにすればいいものではないと思いますけどね。 # UNICODE(MSのいうものではなく)も4byteですね。 # VC2005のwchar_tはWindows同様2byteですがgccのwchar_tは4byteだったり。
お礼
Windows内部がUNICODEなので、アプリケーション側もUNICODEにすべきかと漠然と思っていましたが、何でもそうすればよいものでもない、ということですね。 まだまだWindows上の通常の日本語テキストはSJISが一般的のようですし、ファイルの入出力なども考慮すると、UNICODE対応に二の足を踏んでしまいます。 回答ありがとうございました。
お礼
回答ありがとうございます。 お礼に書くべき内容を「補足」の方へ書いてしまいましたが、情報ありがとうございました。
補足
実は、開発環境を XP+VS2005 から Vista+VS2005 に移行することを検討して、そのついでに、ユニコードにしようかな、と思っていたのですが、いろいろバグがあるのでしたら、改めて考えないとならなそうですね。 情報ありがとうございます。