旧フォーラム : 旧フォーラム > Dev Forum > dialog_interface::ask

投稿者	スレッド
MASA_ 投稿数: 308	投稿日時: 2011-10-09 18:10 Re: dialog_interface::ask_path() の文字エンコードに付いて
boost は、1.44.0です。 1.46までは、ダウンロードして使える状態にはなってますが、対象のプラグインでの設定は、1.44.0 になってます。但し、使っているのは、ask_pathと絡んで利用しているのは、保存時の既存ファイルチェックですので、読み込み時には関係ないと思います。現在、 SDK10からSDK12への移行 MACのLion化 .netの2010化等が中途半端状態なので、一段落したら、 boostも最新にして、この辺詳細にチェックしてみようと思ってます。
画像投稿機投稿数: 448 管理人	投稿日時: 2011-10-09 16:53 Re: dialog_interface::ask_path() の文字エンコードに付いて
引用： MASA_さんは書きました： Windows版の場合は、プラグインにboost::filesystem を利用(MACとWindowsでソースの統一のため)しているため、それによる問題があるかも知れません。 boost::filesystem は、どのバージョンを使用されていますか。プラグインSDKではboost 1.43.0が同梱されていますが boost 1.43.0 のfilesystem v2 は日本語などのマルチバイト文字に対応していないため、 Macと同じように使用するとWindowsで問題が発生します。マルチバイト文字に対応しているのは、filesystem v3 以降で filesystem v3 は boost 1.44.0 でオプションとして導入されて 1.46.0 でデフォルトになっています。
MASA_ 投稿数: 308	投稿日時: 2011-10-09 10:39 Re: dialog_interface::ask_path() の文字エンコードに付いて
引用：文字コードの変換が不安定のようですが、 ask_pathなどはどのタイミングで呼ばれているでしょうか。使い方は、極普通の使い方です。不安定と表現したのは、同じ操作でうまくいく場合といかない場合があることです。私のMACは、非力で且つ非標準のアップグレードをしているのが、危ういことの理由かなと思ってます。 MACの場合、encode、decode処理が間に入ってないようなのでうまくいく場合は、どちらも正常動作するようです。 Windows版の場合は、プラグインにboost::filesystem を利用(MACとWindowsでソースの統一のため)しているため、それによる問題があるかも知れません。次回のアップ時に再度詳細を調査してみるつもりです。
画像投稿機投稿数: 448 管理人	投稿日時: 2011-10-08 20:10 Re: dialog_interface::ask_path() の文字エンコードに付いて
文字コードの変換が不安定のようですが、 ask_pathなどはどのタイミングで呼ばれているでしょうか。 plugin_interface::do_itやwindow_interface::mouse_downなどのような Shadeから呼び出されるプラグイン関数内であれば、そのプラグインに対する文字コード変換は正常に行われるはずですが、 OSのタイマーイベントやウィンドウプロシージャなど Shadeからの呼び出し以外のタイミングで呼ばれた場合は直前に呼ばれた別のプラグインからの呼び出しと誤認して不正な文字コード変換が行われる可能性があります。
MASA_ 投稿数: 308	投稿日時: 2011-10-07 15:25 Re: dialog_interface::ask_path() の文字エンコードに付いて
MACの件再確認しました。 shade.message() を付加して再チェックしたところ日本語部分は、読み込み時も書き込み時もutf8のようでした。また、書き込みも読み込みをうまく動作しているようです。私のMACの場合時たま不安定になることがあるようです。これで、問題は、Windowsでの読み込み時だけです。今回は、日本語ファイル名及びディレクトリは、使用しないことを制限事項にして公開することにしました。
画像投稿機投稿数: 448 管理人	投稿日時: 2011-10-06 18:26 Re: dialog_interface::ask_path() の文字エンコードに付いて
こちらでは再現できませんでした。 dialog_interface::ask_path() で取得した文字列を shade_interface::message()でメッセージウインドウに表示した場合に正しく表示されているでしょうか。
MASA_ 投稿数: 308	投稿日時: 2011-10-06 11:12 Re: dialog_interface::ask_path() の文字エンコードに付いて
ソースを確認しましたが、保存時は、false(defaultを使用) 読み込み時は、trueになってます。英語名の場合は、ちゃんと読み書きできてますので、それはないと思います。整理すると以下のようになります。保存、 Windows 　英語ファイル名->正常保存　日本語ファイル名->正常保存 MAC 　英語ファイル名->正常保存　日本語ファイル名->予期せぬエラー読み込み Windows 　英語ファイル名->正常読み込み　日本語ファイル名->ファイルが見つからないエラー MAC 　英語ファイル名->正常読み込み　日本語ファイル名->保存できないため未チェックです。
画像投稿機投稿数: 448 管理人	投稿日時: 2011-10-05 18:41 Re: dialog_interface::ask_path() の文字エンコードに付いて
`std::string path = dialog->ask_path( true,"..." ) ; compointer<text_stream_interface> stream shade.create_text_file_interface( path.c_str(), true )) ;` 最初の質問のコードは上記のようになっていますが、これはファイル保存(Save)ではなくファイル読込(Open)になっています。このあたりで間違いはないでしょうか。 // Save dialog. { compointer<sxsdk::dialog_interface> dialog(scene->get_dialog_interface()); const std::string path(dialog->ask_path(false, "Text\|txt")); if (!path.empty()) { compointer<sxsdk::text_stream_interface> text_stream(shade->create_text_file_interface(path.c_str(), false)); if (text_stream) { text_stream->write_line("ABC"); } } } // Open dialog. { compointer<sxsdk::dialog_interface> dialog(scene->get_dialog_interface()); const std::string path(dialog->ask_path(true, "Text\|txt")); if (!path.empty()) { compointer<sxsdk::text_stream_interface> text_stream(shade->create_text_file_interface(path.c_str(), true)); if (text_stream) { const char *linep = 0; text_stream->read_line(linep); if (linep) { const std::string line(linep); shade->message(line); } } } } 上記のコードでファイルが読み書きできることを確認しました。
MASA_ 投稿数: 308	投稿日時: 2011-10-05 15:23 Re: dialog_interface::ask_path() の文字エンコードに付いて
ちなみにMAC(OSX10.6)の場合は、保存時点で「予期せぬエラーが起きました」となって保存できませんでした。勿論、通常のファイル名では、保存できました。 (もしかしたら、MACでの環境設定のエンコード指定で現象が変わるかも知れません。)
画像投稿機投稿数: 448 管理人	投稿日時: 2011-10-04 11:30 Re: dialog_interface::ask_path() の文字エンコードに付いて
引用： get_text_encoding って、plugin_interface 内のコールバック関数でしょうか？ SDKでメンバー検索しても出てきません。 get_text_encoding はSDKのメンバー関数ではなく、create_interface, has_interfaceなどと同じ dllentries.h に定義されているdllexport関数です。これらの関数は、Shadeがプラグインをロードした後にShade側が呼びます。 get_text_encoding は必須ではないため、実装されていない場合はデフォルトの設定になります。デフォルト設定は、Shade 7以降であれば、WIndows、MacともにUTF-8になっています。そのため、とくに指定がなければUTF-8になっているはずです。引用：通常の文字列では、テキストファイル内の文字も、Shade内の文字列もUTF8にしてますが、Windowsでのファイル名がUTF8では、エキスプローラでは表示できないので、ask_path内でUTF8から、Windowsのファイル用のネイティブのコードに変換しているものと思ってました。(今Windowsのネイティブのフィル名は何なんでしょう？) それをさらに、ask_pathの読み込み時に、ファイル名をencodeしているので、それをそのままで、create_text_file_interface がファイルオープンしているからと思ってたのですが。 WindowsはUTF-16LE、MacはUTF-8とプラットフォームによってエンコーディングが異なるため、データの互換のために内部フォーマットはUTF-8で統一して、 WIndowsの場合は、APIにアクセスする直前でUTF-8 -> UTF-16に変換して使用されます。 create_text_file_interface にUTF-8で正しいファイルパスがわたっていれば、 WIndowsでは、UTF-8 -> UTF-16に変換して動作するはずです。プラグイン ← [utf8] ← ask_path ← [utf8] ← Shade ← [utf8] ← [decode] ← [utf16] ← Windows プラグイン → [utf8] → create_text_file_interface → [utf8] → Shade → [encode] → [utf16] → Windows ここでのdecode/encode はShadeが基準になっています、 decode：外部形式からShadeが使用する形式(UTF-8)へ変換 encode： Shadeが使用する形式(UTF-8)から外部形式へ変換 shade_interface::decode/encode関数が同様の動作をします。 MacはシステムがUTF-8なのでencode/decodeは入りません。
MASA_ 投稿数: 308	投稿日時: 2011-10-03 19:40 Re: dialog_interface::ask_path() の文字エンコードに付いて
早速の回答有難うございます。ただ、プラグインはディフォルトで UTF8だと思います。デバッグ時に、文字列をVisual Stadio 2005 で眺めて意味不明の文字列なので、デバッグに当惑していますから。また、 get_text_encoding って、plugin_interface 内のコールバック関数でしょうか？ SDKでメンバー検索しても出てきません。通常の文字列では、テキストファイル内の文字も、Shade内の文字列もUTF8にしてますが、Windowsでのファイル名がUTF8では、エキスプローラでは表示できないので、ask_path内でUTF8から、Windowsのファイル用のネイティブのコードに変換しているものと思ってました。(今Windowsのネイティブのフィル名は何なんでしょう？) それをさらに、ask_pathの読み込み時に、ファイル名をencodeしているので、それをそのままで、create_text_file_interface がファイルオープンしているからと思ってたのですが。引用：画像投稿機さんは書きました： Shadeの内部文字列エンコーディングはUTF8固定になっていますが、プラグインではget_text_encodingで値を返すことでプラグイン毎に異なるエンコーディングを使用できるようになっています。
画像投稿機投稿数: 448 管理人	投稿日時: 2011-10-03 19:01 Re: dialog_interface::ask_path() の文字エンコードに付いて
create_text_file_interface が引数のpathをdecodeし忘れているために発生している問題のようです。 Shadeの内部文字列エンコーディングはUTF8固定になっていますが、プラグインではget_text_encodingで値を返すことでプラグイン毎に異なるエンコーディングを使用できるようになっています。そのため、utf8_encoding以外を指定したプラグインとShadeで文字列をやり取りする場合には、encodeとdecode処理が入ります。例：get_text_encoding が shift_jis_encoding を返している場合プラグイン ← [sjis] ← get_* ← [encode] ← [utf8] ← Shade プラグイン → [sjis] → set_* → [decode] → [utf8] → Shade インターフェイスが正しく実装されていれば、問題なく動作するはずでしたが、 create_text_file_interface が引数のpathをdecodeが抜けているため、プラグイン ← [sjis] ← ask_path ← [encode] ← [utf8] ← Shade プラグイン → [sjis] → create_text_file_interface → [sjis] → Shade となりsjisをutf8文字列として処理して日本語文字列については失敗するようです。推奨される対応策は、プラグインのエンコーディングをUTF8にすることです。
MASA_ 投稿数: 308	投稿日時: 2011-10-03 15:05 dialog_interface::ask_path() の文字エンコードに付いて
掲題の件での確認と対応策があれば、よろしく願います。ファイルパスを取得する掲題の関数で、ファイル保存時にファイル名に日本語を指定したところ、ちゃんとエキスプローラで読めるファイル名になりました。ところが、そのファイルを、今度は同じ ask_path() で指定して、得られた文字列を使って、stream でオープンするとエラーになります。現時点で、詳しいデバッグはしてないので、詳細は不明ですが、 std::string path = dialog->ask_path( true,"..." ) ; compointer<text_stream_interface> stream shade.create_text_file_interface( path.c_str(), true )) ; のように渡すと、 stream が得られません。自作のファイル取得ダイアログが、保存時に文字化けしてしまうので、ask_pathを利用しようとしたところ見つかった現象です。 Shadeは、12.0.3 OSは、Windows7です。 MACはチェックしてません。

スレッド表示 | 古いものから　投稿するには登録が必要です

前のスレッド | 次のスレッド | トップ

最近の投稿