LPTSTR содержит только одну букву

Я создаю 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 и его функционированием. Спасибо за любую помощь, которую вы можете оказать.

1

Решение

Вы написали в своем вопросе, что настройки проекта 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.

2

Другие решения

Уже поздно #define UNICODE после #include "stdafx.h", Это должно быть определено до первого #include в stdafx.h сам. Но правильный способ — установить его в свойствах проекта (меню «Проект»> «Свойства»> «Свойства конфигурации»> «Основные»> «Набор символов»> «Использовать набор символов Юникода»).

0

По вопросам рекламы [email protected]