Greetings, Lester Caine. In reply to Your message dated Saturday, March 21, 2020, 15:28:41, > On 21/03/2020 09:25, Christoph M. Becker wrote: >> On 21.03.2020 at 02:37, Andrey Repin wrote: >> >>> Greetings, Lester Caine. >>> >>> In reply to Your message dated Wednesday, March 18, 2020, 1:03:49, >>> >>>> On 17/03/2020 19:11, Sam Hobbs wrote: >>>> >>>>> You still did not answer the question of what OS. The answer for Windows >>>>> is not simple. So before doing exotic testing, you really should look at >>>>> the documentation for the relevant OS. >>>> >>>> He said he is on MacOS and the other answers align up with that. The >>>> problem is that while Windows is reliably case insensitive and crap on >>>> unicode file names, >>> >>> That's not really true. Windows can be configured for anything you wish, and >>> UNICODE names were a problem of PHP, which was solved not-very-recently in V7. >> >> More precisely, as of PHP 7.1.0: >> <https://www.php.net/manual/en/migration71.windows-support.php#migration71.windows-support.long-and-utf8-path>. > But is far as I am aware windows is STILL using 16 bit per character It uses UTF-16 for internal representation. Which is far from "16 bit per character". > wide string format for file names along with somewhat unreliable case > conversions on the basic ASCII character subset? The strength of your desire to attack the OS you dislike is very clear. However, I suggest you learn first, attack later. If there's still something to attack. https://stackoverflow.com/a/52203901/1449366 > While we can use UTF8 characters in Linux file names they do not map through > to the windows file name? They do. It is guaranteed by the UNICODE standard. Exceptions to this rule are not in character mapping, but in differences of underlying OS/filesystem. (F.e. you can't reliable represent a dot at the end of a file in Windows, while in Linux it is perfectly normal.) > This is nothing to do with PHP ... That much is true. -- Sincerely Yours, Andrey Repin <anrdaemon@xxxxxxxxxxx>
