Я создаю DLL для приложения. Приложение вызывает библиотеку DLL и получает строку длиной от 8 до 50.
У меня проблема в том, что только первая буква любого сообщения, которое получает приложение, показывается.
Ниже приведена функция GetMethodVersion.
#include "stdafx.h"STDAPI_(void) GetMethodVersion(LPTSTR out_strMethodVersion, int in_intSize)
{
if ((int)staticMethodVersion.length() > in_intSize)
return;
_tcscpy_s(out_strMethodVersion, 12, _T("Test"));
//staticMethodVersion should be insted of _T("Test")
}
Настройки проекта установлены в Юникод.
После некоторых исследований я верю, что существует проблема с форматом Unicode и его функционированием. Спасибо за любую помощь, которую вы можете оказать.
Вы написали в своем вопросе, что настройки проекта 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
размером не менее 12 wchar_t
с (включая завершающий NUL)?
Затем взгляните на сайт вызова (который вы не показали).
Как вы печатаете возвращенную строку? Может быть, вы используете ANSI char функция, поэтому возвращаемая строка неправильно как char*
ANSI строка и так первая 0x00
байт строки Unicode UTF-16 неверно истолковывается как 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, Кодировка Юникод.
Как и в строках ANSI, 0x00
байт в UTF-8 является строковым NUL-терминатором, поэтому предыдущий анализ UTF-16 0x00
байт (в wchar_t
) неправильно в качестве строки применяется терминатор NUL.
Обратите внимание, что чистый ASCII является правильным подмножеством UTF-8: поэтому ваш код может работать, если вы просто используете чистые символы ASCII (как в "Test"
) и передать их в EXE.
Однако, если задокументировано, что EXE использует Unicode UTF-8, вы можете сделать все правильно и вернуть строку DLL UTF-8.
Строка возвращается через char*
(что касается строк ANSI), но важно убедиться, что UTF-8, это кодировка, используемая DLL для возврата этой строки, чтобы избежать незначительных ошибок в будущем.
Хотя общая терминология, используемая в Windows API и Visual Studio, «Unicode», это на самом деле означает UTF-16 Кодировка Unicode в этих контекстах.
Однако UTF-16 — не единственная доступная кодировка Unicode. Например, для обмена текстом в Интернете UTF-8, Кодирование широко используется. В вашем случае это звучит так, как будто ваш EXE ожидает строку Unicode UTF-8.
Уже поздно #define UNICODE
после #include "stdafx.h"
, Это должно быть определено до первого #include
в stdafx.h
сам. Но правильный способ — установить его в свойствах проекта (меню «Проект»> «Свойства»> «Свойства конфигурации»> «Основные»> «Набор символов»> «Использовать набор символов Юникода»).