by Michael S. Kaplan, published on 2013/02/12 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2013/02/12/10392953.aspx
The other day, colleague David noticed:
Hi all,
Does anybody know off-hand if launching Explorer programmatically (using either ShellExecute or ShellExecuteEx) should fail to open a directory containing surrogate pairs?
If I first create a directory, say, “c:\コンポ𠮷𠮟㐂“, and then run…
ShellExecuteW(NULL, L"open", L"explorer", L"c:\\コンポ𠮷𠮟㐂", NULL, SW_SHOWNORMAL);
Then ShellExecute succeeds and Explorer opens, but it just punts and opens My Documents.
If I try the above with any other existing path that does not contain surrogates (like “c:\test” or even “C:\コ㐂”) then the Explorer opens in the requested directory.
This occurs on both Win7 and Win8. Is this an expected limitation with surrogate pairs?
Thanks,
David
He's right, it doesn't find supplementary paths.
I doubt it is actually ShellExecuteW, for what it's worth.
Something to do with the verb syntax, or how NTFS indexes the files, or more likely the way Explorer searches them, maybe?
Depressing that even in Windows 8 such problems exist.
A good bug with surrogate pairs and supplementary caracters, in any case!
Yuhong Bao on 12 Feb 2013 1:38 PM:
On Unicode in Zip files, there is now this hotfix:
Doug Ewell on 12 Feb 2013 2:30 PM:
This sort of thing will become more and more annoying, since all those emoji are encoded in the supplementary zone. I'm sure people are already trying to use emoji to create folder names, and no, I'm not being facetious or sarcastic (for once).
Char in .NET makes it soooo easy to use Unicode transparently, while still getting supplementary characters wrong.
Mike Dimmick on 13 Feb 2013 5:11 AM:
In Windows 7, the Folder class's 'open' command is delegated to an IExecuteCommand implementation, CLSID_ExecuteFolder, which is implemented in %SystemRoot%\system32\explorerframe.dll. The folder name is presumably passed through IExecuteCommand::SetParameters, though DelegateExecute is not well documented.
So the likelihood is that the parsing of surrogates goes wrong either in CLSID_ExecuteFolder, or in whatever IPC it uses to communicate with the running instance of Explorer. If navigating to the folder in Explorer itself works, I'd suspect the IPC. Unless, of course, ShellExecuteW isn't detecting that the item *is* a folder.
Mike Dimmick on 13 Feb 2013 7:59 AM:
Actually I've just seen Raymond's blog post for today, which links to two of his old posts:
DelegateExecute and IExecuteCommand: blogs.msdn.com/.../9977246.aspx
Explaining the lpClass member of SHELLEXECUTEINFO: blogs.msdn.com/.../10033224.aspx