從ANSI轉換爲Unicode並返回時出現問題。以下代碼片段描述了我正在做的事情。我得到的0x57錯誤..QB64中的WideCharToMultiByte
DECLARE DYNAMIC LIBRARY "kernel32"
FUNCTION MultiByteToWideChar& (codePage~&, dwFlags~&, lpszMbstring$, byteCount&, lpwszWcstring$, wideCount&)
FUNCTION WideCharToMultiByte& (codePage~&, dwFlags~&, lpWideString$, BYVAL ccWideChar%, lpMultiByte$, BYVAL multibyte%, BYVAL defaultchar&, BYVAL usedchar&)
FUNCTION GetLastError&()
END DECLARE
DIM Filename AS STRING * 260, NewFilename AS STRING * 260, MultiByte AS STRING * 260
PRINT "Enter filename";: INPUT Filename$: 'Filename$ = Filename$ + CHR$(0)
x = MultiByteToWideChar(0, 0, Filename$, LEN(Filename$), NewFilename$, 260)
IF x = 0 THEN
PRINT "Error 0x"; HEX$(GetLastError)
ELSE
PRINT "Processing: "; NewFilename$
END IF
' do unicode stuff here
x = WideCharToMultiByte(65001, 0, NewFilename$, LEN(NewFilename$), MultiByte$, 0, 0, 0)
' display processed filename
IF x = 0 THEN
PRINT "Error 0x"; HEX$(GetLastError)
ELSE
PRINT MultiByte$
END IF
好的,再次感謝。這應該只是做一段時間,因爲我把所有的代碼拼在一起.. – eoredson
順便說一句:爲什麼FindFirstFileW返回.cAlternateFilename爲NUL? – eoredson
文檔聲明DOS 8.3格式文件名將在'cAlternateFilename'中,除非'cFilename'已經是8.3文件名,在這種情況下'cAlternateFilename'是一個空字符串。例如,'foo.txt'會導致一個空的'cAlternateFilename'成員,而'HelloWorld.txt'和'foo.config'可能導致'HelloW〜1.txt'和'foo〜7.con'。 –