Wolfgang said:
When I type in a command prompt on a Win2000/WinXP the well known "dir" command
and redirect the output to a file I got a problem.
I have files in the directory with german umlaute (öäü). When the output is shown at the
command prompt (stdout) they are displayed correctly. But when I open the created text file with
the file listing they are not displayed correctly (e.g. in Notepad or other editors).
(Appologies, this has got long and complicated, but I'll post it anyway incase
it is of use)
Long file names in VFAT filesystems are stored in 16-bit unicode.
File names in NTFS are stored in 16-but unicode.
Data output by DIR is in 8-bit ascii, with extensions.
Windows uses a different character set mapping to DOS. The MS-DOS EDIT command
will show the accented/umlauted characters correctly. EDIT is a MS-DOS based
editor. NOTEPAD is a windows application. MS-DOS applications use the CP437
character set (derived from the 1981 IBM PC spec) . Windows uses (IIRC) an
ISO-8859-1 character set, commonly confused with Windows-1252.
These two conflicting standards rarely agree for any character above character
126 (~)
In CP437, an umlauted lower-case a is character 132 (which appears as a lower
double quote in ISO-8859-1). In ISO-8859-1, the same character is represented
by character 228 (which appears as a greek upper-case sigma in PC-8)
Both are correct, for their respective environments.
Consider yourself lucky that MS-DOS didn't use EBCDIC
To get around this problem, considering that windows knows the names of the file
and will do translation where necessary (but dos doesn't which is the problem),
you need something that uses the windows API to get file names. The functions
you need are FindFirstFile and FindNextFile, something like (in C):
FILE *OutputFile = fopen("SomeOutputFile.txt","w");
char *sFileSpec = "*.txt";
LPWIN32_FIND_DATA FoundFile;
HANDLE hSearchHandle = FindFirstFile(sFileSpec,FoundFile);
if( hSearchHandle != INVALID_HANDLE_VALUE )
do
{
printf(OutputFile,"%s",FoundFile->cFileName);
}
while( FindNextFile(hSearchHandle,FoundFile) );
FindClose(hSearchHandle);
(although I have not even throught about compiling that to see if it actually works)
There's probably something similar available in visual basic, but I have no
plans to be found anywhere near that particular language, thanks.
