Still does the same thing
FileGetW will only load a file as Unicode if it contains a BOM for UTF-16. If the file does not contain a BOM at the beginning or it has a BOM for UTF-8, it will treat the file as ANSI and attempt to convert it to Unicode UTF-16. Generally, UTF-8 Unicode files do not have a BOM because it has no meaning, other than to indicate that the file is UTF-8.
The are several ways to determine the character encoding of a file. One fairly simple method is to load the file into a HEX file viewer like the WinBatch Browser utility and look for a BOM and for indicators of UTF-16 and UTF-8 encoding. The BOM is the first one to three bytes of a file and will contain the hex values FFFE or FEFF for UTF-16 and EF, BB and BF for UTF-8.
If a file does not contain a BOM, you can still get a good idea of the encoding by looking at the hex values of the text. If you see a lot of values preceded by a 00 hex value then the file is likely UTF-16. If you see hex values C2, C3, C4, etc., mixed in with regular ANSI values then the file is likely UTF-8.
If it turns out that your file is UTF-8 (which is likely base on evidence presented), the following Tech. DB article demonstrates one technique used to handle UFT-8 in WinBatch
http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/tsleft.web+winbatch/Strings+Convert~To~UTF-8.txt[Edit] Another way to handle UTF-8 is to set the WinBatch code page to UTF-8 using the ChrSetCodePage function before calling
FileGetW. If the file does not have a BOM, the function will assume that the file is UTF-8 and convert it to UTF-16. Make sure to set the code page back to the default after calling
FileGetW. If you don't, the subsequent call to
StrReplace will not work.