Por algum motivo, quando uso a SHFormatDateTime
função da API do Win32 para obter a Data de Modificação de um arquivo, com qualquer sinalizador, ela acrescenta alguns caracteres especiais estranhos, como a seguir.
Isso ocorre no contexto de loop pelos arquivos ( WIN32_FIND_DATAA findData
), o que pode ou não ser relevante aqui.
Versão ANSI simples - SHFormatDateTimeA
:
hFind = FindFirstFileA(full_path.c_str(), &findData);
while (FindNextFileA(hFind, &findData) != 0) {
char datebuf[80];
DWORD flags = FDTF_DEFAULT;
SHFormatDateTimeA(&findData.ftLastWriteTime, &flags, datebuf, 80);
std::string lastModifiedDateStr = std::string(datebuf);
Saída:?4/?25/?2025 ??9:44 AM
Versão Unicode - SHFormatDateTimeW
:
wchar_t datebuf[80];
DWORD flags = FDTF_DEFAULT;
SHFormatDateTimeW(&findData.ftLastWriteTime, &flags, datebuf, 80);
std::wstring lastModifiedDateStr = std::wstring(datebuf);
Saída:u+200E 4 / u+200E 25 / u+200E 2025 u+200F u+200E 9 : 44 AM
Portanto, independentemente de ANSI/Unicode, a função SHFormatDateTime
adiciona alguns caracteres estranhos antes de cada parte. Tentei várias flags, como FDTF_DEFAULT
, FDTF_SHORTDATE
e até NULL
. Não tenho esse problema com outras funções da API WIn32 do Shell.
U+200E é
LEFT-TO-RIGHT MARK
. Isso garante que o texto formatado seja exibido na ordem da esquerda para a direita quando processado no contexto de um idioma com leitura da direita para a esquerda. Se essas marcas forem inseridas, suaflags
variável será atualizada para incluir o sinalizadorFDTF_RTLDATE
ouFDTF_LTRDATE
correspondente (é por isso que opdwflags
parâmetro é[in, out]
):Por exemplo:
Você pode suprimir esse comportamento especificando o
FDTF_NOAUTOREADINGORDER
sinalizador na entrada: