Hello Anatol, Tuesday, July 30, 2013, 10:13:28 PM, you wrote: > In addition to the fact that 8.3 names are an issue themselves as they > might be not present on a particular system, I don't see any issue if 8.3 are not present. If they don't they don't. I think then com would even be able to create such a name for me to use it with php. There are many features required of optional to run the language, like particular c++ libraries present on the system. It's up to coder to if around the issue if he thinks that not every system would have a feature. > it's about a multibyte name > in your case. So it needs to be encoded and decoded. In my case there is not a multibyte name. PHP should not do any encoding or decoding here. How is that programs that never heard of Unicode from 1990s are able to open Unicode named files perfectly fine ? The real issue is if a program gets slightly aware of a feature so it is able to detect it but not cope with it. PHP should not touch the name as it was given in the function. > Not sure about that and whether it's needed. I'd rather do inside out, > use a non unicode filename with CURL and then move that file into some > unicode name using a cmd script. Or even move it using COM. Yeah, I know of that way. I filled a bug here: https://bugs.php.net/bug.php?id=65358 But they dismissed it as duplicate. It has nothing to do with these bugs: https://bugs.php.net/bug.php?id=64699 https://bugs.php.net/bug.php?id=61315 Where people tried to put Unicode strings *directly* into php functions. Again I understand that it not works and wont work until a nowhere seen php6 with Unicode support comes up. Here I want to protect php from seeing the Unicode, but it still knows better and tries to resolve these shortened path. I wonder if someone who dismissed my bug even looked at it for more of one second. -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
