2010-12-28 9 views
0

私たちのアプリケーションは、実行時にShGetFolderPathを呼び出して、マイドキュメントフォルダを取得します。これは通常正常に動作します。しかし、Дмитрий、JörgとJörgenの3人のユーザ(パターンを見つけることができるかどうかを参照してください)には、非常に奇妙な結果が返されます。例えば、Дмитрий、の呼び出しが戻る:SHGetFolderPathは疑問符を含むパスを返します

c:\Users\???????\Documents 

私は文字エンコーディングshenaniganはおそらくUnicodeに関連し、ここで起こってのいくつかの並べ替えがありますと仮定し、私はそういったことの経験を持っていません。どのようにして情報のレジストリキーを掘り下げることなく、ウィンドウからフォルダ(および他の関連フォルダ)への便利なパスを取得できますか?

C:\Users\43D6~1\Documents 

だから私は、「正常な」バージョンを取得する方法があります知っている:私に電子メールで

、Дмитрий(「ドミトリー」)は、彼の「マイドキュメント」フォルダが実際にここに位置していた私に言いましたWindowsからの道のり、私はちょうどそれが何であるか分からない。

背景:私たちのアプリケーションはユニコード対応ではなく、標準の "char *"文字列を使用しています。どのようにして「正常な」経路を得ることができますか?私は関数の "ユニコード"バージョンを呼び出すことに反対していない、それは可能であれば "通常の"テキストに変換します。アプリケーションを完全にUnicodeを使用するように変換することは、ここではオプションではありません(時間がありません)。

ありがとうございました。

+0

標準文字 'char'は、デフォルトで8ビットのオクテットです。英語、キリル文字、その他すべての言語固有の文字エンコーディングを格納するには、8ビットで十分なスペースがありません。 *ワイド文字やUTCなどの文字列には、別のベースを使用する必要があります。 –

+0

GetShortPathName()。それは正常ではありません。 Dimitryはプログラムを機能させるために、システムコードページをWindows 1251に変更する必要があります。 Unicodeを無視すると自動的に解決されるため、ユーザーはライセンスの更新をやめるだけです。 –

+0

setlocaleは回避策になる可能性があります。私はsetlocale(LC_ALL、 "Russian")がドミトリーの問題を解決すると思います。私は前にそれを使用しましたが、それは醜い解決策ですが、速いです。 – DReJ

答えて

5

ファイルパスをUnicodeで取得します。次に、短いパス名のコンポーネントに変換するためにGetShortPathNameWを呼び出します。 Unicode関数であっても、ASCII範囲外の文字は出力に含めないでください。その後、各Unicode文字を8ビットに切り捨てて、char文字列を作成することができます。

2

"unicode"バージョンの関数を呼び出して、それが可能であれば "通常の"テキストに変換することに反対していません。

あなたはSHGetFolderPathWSHGetFolderPathにお電話を変更する場合は、Unicode文字列であるタイプLPWSTRの文字列、を提供します。そこから、その文字列を使用して、さまざまなUnicode関数(Wで終わる)を使用して、必要なフォルダにアクセスできます。

関連する問題