1

I seem to be stuck on special characters (like äöü) in windows file paths. They are legal names for folders (users can set them).

A part of my program has to be able to traverse the filesystem. When trying to enter a childfolder with the name 'öö' (testcase) I get the error that the directory does not exist.

I am rather sure that the problem is this 'line':

wstring newPath = oldPath + ffd.cFileName + L"\\";

From

void reevaluateJob(wstring newPath) {
    WIN32_FIND_DATA ffd;
    HANDLE findFileHandle = FindFirstFile((newPath + L"\*").c_str(), &ffd);
    //skipping invalid case handling and loop
    if (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
        if ((wcscmp(ffd.cFileName, L".") != 0) && (wcscmp(ffd.cFileName, L"..") != 0))
            reevaluateJob(newPath + ffd.cFileName + L"\\");  //<=== new path here
    } else {
        //skipping file part
    }
}

Because printing the new path (or ffd.cFileName as wstring) results in different characters. Is there another data type that doesn't have this problem?

EDIT: This works totally fine as long as the folder names do not contain special characters (like äöü etc.).

Cœur
  • 37,241
  • 25
  • 195
  • 267
Arkbob
  • 11
  • 4
  • 1
    The `L"\*"` doesn't look like real code. Also, it indicates that `newPath` is not backslash-terminated. That's most likely the basic error here. In addition you have probably introduced a misinterpretation of your data by "printing" the `wstring". – Cheers and hth. - Alf Sep 27 '14 at 22:41
  • L before a string is used for an extended character set. http://stackoverflow.com/questions/6384118/what-does-the-l-in-front-a-string-mean-in-c – ArnonZ Sep 27 '14 at 22:50
  • I'll randomly guess that newPath + ffd.cFileName is missing a backslash. Debugger ought to be helpful. – Hans Passant Sep 27 '14 at 23:19
  • Did you try using `#define UNICODE`? – ArnonZ Sep 27 '14 at 23:30
  • @Cheersandhth.-Alf Does using wstring break chars like üöä? I use wcout << path; as output. – Arkbob Sep 27 '14 at 23:53
  • @Arkbob: using `wstring` doesn't break those characters. but output using `wcout` translates to the active narrow codepage of the console. most likely you have a default active code 437. if so then what you see in the console is not what you have internally. well i already said this, misinterpretation. check it out. – Cheers and hth. - Alf Sep 28 '14 at 03:12
  • @ArnonZilca: `\*` is not a valid escape sequence. – Cheers and hth. - Alf Sep 28 '14 at 03:14

1 Answers1

0

As pointed out by @ArnonZilca, #define UNICODE solved half of the problem. Sadly not all windows functions stick to that rule. Some also want #define _UNICODE.

In the process of trying to fix the problem, I also changed my whole code to use WCHAR* instead of wstring. I assume (but cannot be 100% sure) that this does NOT make a difference.

Arkbob
  • 11
  • 4
  • I just changed back to an older version of my code. Using wstring works too, as long as there is #define _UNICODE and #define UNICODE at the top. – Arkbob Sep 28 '14 at 10:43
  • Huh. Ordinarily I would expect the compiler to define those for you. Perhaps your build settings are wrong? – Harry Johnston Sep 28 '14 at 20:07
  • I start using c++ lik 5 days ago. So it's just a fresh visual studio 2013 with a windows console c++ project. – Arkbob Oct 01 '14 at 08:54
  • In Configuration Properties, under General, what does it say for "Character Set"? What about "Preprocessor Definitions" under C/C++ Preprocessor? C/C++ Command Line shows you the command line for the compiler; does it include `/D "_UNICODE"` and `/D "UNICODE"` ? – Harry Johnston Oct 01 '14 at 20:00