Is this a bug for chinese path supporting in MSVC?

Today I want to import an STL file through RWStl::Read method, but it returns a null Handle.

I found this problem occurs when the first argument (path) contains Chinese words, such as `几何\1.stl`.

The interesting thing is I tracked the process and located the problem.

In the RW stage, OCCT trying to open a file by the OSD_OpenStream method.

  std::filebuf aBuf;
  OSD_OpenStream (aBuf, theFile, std::ios::in | std::ios::binary);
  if (!aBuf.is_open())
  {
    return Standard_False;
  }

The OSD_OpenStream code is:

template <typename T>
inline void OSD_OpenStream (T& theStream,
                            const char* theName,
                            const std::ios_base::openmode theMode)
{
#if defined(_WIN32)
  // redirect to method taking UTF-16 string
  const TCollection_ExtendedString aFileNameW (theName, Standard_True);
  OSD_OpenStream (theStream, aFileNameW, theMode);
#else
  theStream.open (theName, theMode);
#endif
}

It looks like OCCT always converts `theName`  to a UTF-16, `theName` is directly read from `main(int argc, char** argv)` but the `theStream.open` method can work well with it rather than the aFileNameW. The aFileNameW displayed in debugger is not correct after convert to UTF-16 (`{mystring=0x000001dccc9da340 u".\\¼¸º͜out0.stl" mylength=14 }`). So when input char contains Chinese words the RWStl::Read will failed.

My system platform is Windows 10 2004, and VS is 2019 (Windows SDK 10.0.18362).

Kirill Gavrilov's picture

 `theName` is directly read from `main(int argc, char** argv)`

Your application just doesn't support UNICODE input on Windows platform, which is what OCCT expects.
The code should define the main function with wchar_t** argument or use CommandLineToArgvW().