文字コード(多言語化？)の取り扱いについて

正直な話今まで多言語化とか複数プラットフォームでの動作といったことは
あまり考えていなかったのですが（作った環境限定で動かしたりしてた）

今回その一歩としてまず文字コードの設定を気にしだしました
そこでまず理解できないのが 現在　UNICODE文字セットを使う　設定でソースを作り
TCHARmsg[100];
_stprintf_s(msg, L"Error (0x%x) (%d)\n", hr, __LINE__);
といったようなコードを書きました 当然その環境ではコンパイルして動くのですが
文字コードセットを　設定なし にしてリビルドするとそのコードでは
error C2665: 'sprintf_s' : 2 オーバーロードのどれも、すべての引数の型を変換できませんでした
といったエラーが出ます

TCHARやL としてコードを書いておくことで　_UNICODEデファインの有無により
自動的にwhar_tやcharへの変換が行われると思っていたのですが
基本的な表記法を間違っているのでしょうか？

それとも文字セットはそういったことではなくunicode文字セットにしたときは
多国語サポートを考慮して作っているので
それで書いたソースを文字セット　設定なし　でそのまま再構築できるという
考え方のほうが間違っているのでしょうか
(そんなのかえたらソース変更が当たり前 ってことなんでしょうか？）
　　　　変えられる可能性があるのはマルチバイト文字セットのみ？

環境は VS2010（VC2010)です

No.1 ベストアンサー 回答者： Tacosan 回答日時： 2013/08/28 03:07

L"ほげほげ" だと, UNICODE は完全に無視して wchar_t * になると思う. だから「文字コードセットを　設定なし にしてリビルドする」と第2引数が

const char * を期待しているのに wchar_t * になってる
からエラーになる... ということじゃないかな.

で _T(), と.

この回答への補足

時間空きましたが何パターンかコンパイルオプション変更しても
リコンパイルで動くようにはなりました

未だ多国語 まではいきついていないのが実情ですが
時間を見て調べていきたいと思います

補足日時：2013/10/04 00:10

この回答へのお礼

すいません
試行錯誤した上で _T より L のほうがいいのかと思い変更したのが悪さをしたようです
（何かで　_T でワーニング出て L で直った気がしますがそれも間違いかもしれません）

今回の件はご指摘のように_T に変更することでコンパイル通ることを確認したので
他の部分も同様に修正かけたいと思いますが別の問題が出てしまいました

TCHARmsg[100];
BSTR buf = ::SysAllocString(msg);

というコードがあり unicode ではコンパイルできますが 無指定だと
error C2664: 'SysAllocString' : 1 番目の引数を 'TCHAR [100]' から 'const OLECHAR *' に変換できません。(新しい機能 ; ヘルプを参照)

この場合は const OLECHAR * にキャストするしかないのでしょうか？
その他にもいくつか方が合わなくなってしまう部分があるようなのですが
そういった場合も最終的にはキャストなりで合わせこむしかないのでしょうか？

よろしければお教え願います
いずれにしても動作確認はする必要あるとは思ってます

回答ありがとうございました

お礼日時：2013/08/28 05:34

No.4 回答者： wormhole 回答日時： 2013/08/28 19:58

>では今回に対して言えばどういった対処を取るべきだといわれるのでしょうか？

#3の方がすでに書かれていますが、::SysAllocString()はOLECHARの文字列を要求してるのですからOLECHARの文字列に変換すればいいだけです。
これは::SysAllocString()の仕様を考えればおのずとわかる事だと思いますが。

>そこで固定文字列などを渡したい場合どういった方法とればいいのか
>など疑問が満載状態になってしまいます

使用する関数やAPIの仕様から判断してください。

>ベースコードSDKのサンプルなどから持ってきてそういった状態なのですが
>サンプルも文字セット気にしないで記載されているということなのでしょうか？

私にそのサンプルの事をたずねられても推測しかできませんが(私が書いたわけじゃないし)。
文字コード変換のサンプルでもない限り、そのサンプルが書かれた当時のそのプラットフォームで標準的に使われていた文字コードで書かれてるというだけじゃないですか。

この回答へのお礼

回答ありがとうございます
ちょっと他の調べものでこちらの作業がなかなかできないのですが
変換マクロがあることはわかりましたのでもう少し時間とれたら
ゆっくり確認したいと思うます

簡単にテストしたんですがまた何か勘違いしてるのか
マクロ使ってもさらに別のエラーが発生して
コンパイルができなくなっただけで解決はしていません

単純なキャストでは変換がきちんとされていないため
まともに動かないことの確認はできました

お礼日時：2013/09/03 11:24

No.3 回答者： maru_yoshi_ 回答日時： 2013/08/28 12:39

TCHARとOLECHARの変換は

http://msdn.microsoft.com/ja-jp/library/805c56f8 …
に以下の通り記載されています。つまりT2OLEとOLE2Tマクロを使用すればいいわけです。

以下　引用

OLE 変換マクロ
--------------------------------------------------------------------------------

OLE 変換マクロは OLESTR 文字を扱うことを目的とした関数の処理用にデザインされています。OLE のヘッダーをチェックすると、LPCOLESTR と OLECHAR への参照が数多くあるのがわかります。これらの型は、OLE インターフェイスで使用する文字の型をプラットフォームに依存しない方法で参照するために使用されます。OLECHAR は Win16 のプラットフォームでは char に変換され、Win32 では WCHAR に変換されます。

MFC コード中の #ifdef ディレクティブの数を最小に抑えるために、OLE 文字列を扱う変換でも同じようなマクロが用意されています。頻繁に使用されるマクロは、次のとおりです。

T2COLE (LPCTSTR) -> (LPCOLESTR)
T2OLE (LPCTSTR) -> (LPOLESTR)
OLE2CT (LPCOLESTR) -> (LPCTSTR)
OLE2T (LPCOLESTR) -> (LPCSTR)

この回答へのお礼

回答ありがとうございます
ちょっと他の調べものでこちらの作業がなかなかできないのですが
変換マクロがあることはわかりましたのでもう少し時間とれたら
ゆっくり確認したいと思うます

簡単にテストしたんですがまた何か勘違いしてるのか
マクロ使ってもさらに別のエラーが発生して
コンパイルができなくなっただけで解決はしていません

お礼日時：2013/09/03 11:22

No.2 回答者： wormhole 回答日時： 2013/08/28 07:16

>この場合は const OLECHAR * にキャストするしかないのでしょうか？

何でもかんでもキャストすればいいというものではありません。
TCHARの用に_UNICODEの有無により切り替わることがない型が使われているという事なのですから、ケースに応じた対処をするべきです。

この回答へのお礼

回答ありがとうございました

>何でもかんでもキャストすればいいというものではありません。
それは言われる通りだと思いますが

>ケースに応じた対処をするべきです。
では今回に対して言えばどういった対処を取るべきだといわれるのでしょうか？

キャストしなくていい const OLECHAR * 型のデータを渡せということなのであれば
そこで固定文字列などを渡したい場合どういった方法とればいいのか
など疑問が満載状態になってしまいます
　　今回たまたま　TCHAR　型の変数を渡してますが
　　渡したいデータとして標準関数からの戻り値(CStringデータ)だったり
　　固定の文字列だったり複数のパターンがあります
　　　　　　 (いずれも unicode コンパイルでは問題でていません)
　　ベースコードSDKのサンプルなどから持ってきてそういった状態なのですが
　　サンプルも文字セット気にしないで記載されているということなのでしょうか？

文字コード変更でこれほど悩むとは思わなかったんで混乱してきてます
他に優先してやらないといけないことがあるので文字コード変更の対応（テスト）
がなかなか進みません

お礼日時：2013/08/28 10:04