プロジェクト設定は Unicode であると質問に書きましたが、これは DLL と呼び出し元の EXE の両方に当てはまりますか? 両方が一致していることを確認してください。
Unicode ビルドでは、醜い TCHAR マクロは次のようになります。
LPTSTR --> wchar_t*
_tcscpy_s --> wcscpy_s
_T("Test") --> L"Test"
だからあなたは持っています:
STDAPI_(void) GetMethodVersion(wchar_t* out_strMethodVersion,
int in_intSize)
{
...
wcscpy_s(out_strMethodVersion, 12, L"Test");
}
「マジックナンバー」 12は正しいですか?が指す宛先文字列バッファーout_strMethodVersion
のサイズは少なくとも 12wchar_t
秒 (終端の NUL を含む) ですか?
次に、呼び出しサイト(表示されていません) を見てください。
返された文字列をどのように出力しますか? おそらく、ANSI char 関数を使用しているため、返された文字列が ANSI 文字列として誤っchar*
て解釈され、Unicode UTF-16 文字列の最初の0x00
バイトが呼び出しサイトで NUL ターミネータとして誤って解釈され、文字列が次の場所で切り捨てられます。印刷されたときの最初の文字?
Text: T e s t NUL
UTF-16 bytes: 54 00 65 00 73 00 74 00 00 00
(hex) **<--+
|
First 00 byte misinterpreted as
NUL terminator in char* ANSI string,
so only 'T' (the first character) gets printed.
編集
コメントで次のことを明確にしたという事実:
私は DLL を ANSI に切り替えました。EXE も明らかにそれでしたが、exe は Unicode として文書化されていました。
EXEはUTF-8 Unicodeエンコーディングを想定していると思います。
ANSI 文字列と同様に、UTF-8 のバイトは文字列 NUL ターミネータであるため、文字列 NUL ターミネータとして誤っ0x00
て解釈されたUTF-160x00
バイト ( 内wchar_t
)の以前の分析が適用されます。
純粋な ASCII は UTF-8 の適切なサブセットであることに注意してください。そのため、純粋な ASCII 文字 ( など"Test"
) を使用して EXE に渡すだけで、コードが機能する可能性があります。
ただし、EXE が Unicode UTF-8 を使用していることが文書化されている場合は、正しいことを実行して DLL から UTF-8 文字列を返すことをお勧めします。
文字列は (ANSI 文字列の場合と同様に) 経由で返されますが、将来の微妙なバグを回避するために、DLL がその文字列を返すために使用するエンコーディングがUTF-8char*
であることを確認することが重要です。
Windows API と Visual Studio で使用される一般的な用語は"Unicode"ですが、実際にはこれらのコンテキストでのUTF-16 Unicode エンコーディングを意味します。
ただし、利用可能な Unicode エンコーディングは UTF-16 だけではありません。たとえば、インターネットでテキストを交換するには、UTF-8エンコーディングが広く使用されています。あなたの場合、EXE は Unicode UTF-8 文字列を期待しているようです。