I understand URL's slashes came from UNIX based directory separator so DIRECTORY_SEPARATOR is almost equal to the URL's.
Though, I think there are a bunch of Windows PHP coders in the world, at least in Asia. (I'm a macOS user but I've seen many)
As a info, in a non-English locale env such as Japan, backslash \ is replaced as ¥ as a directory separator. Yes, different ASCII code they are, so even more annoying.
/ (as a directory separator) is ¥ on Japanese Win env.
And on non-UNICODE encoding env such as Shift-JIS, \ is displayed also as ¥.
Since we have to handle a lot of encodings (Shift-JIS, JIS, EUC, UTF-8, UTF-16) until all the systems become UTF-16 or at least UTF-8, we have to convert encoding each other.
The problem is, Windows10 JP uses half Shift-JIS and half UTF-16 inside, so you can type /, ¥, \ as is.
But once changing the encoding (UTF-8 -> S-JIS) it becomes a mess. Imagine \ as escaping and directory as / becomes all ¥.
Well, I agree "always using / as a directory separator" would be nice. Really.
But so far I think for directory separator purposes using DIRECTORY_SEPARATOR is safer.
that sounds odd... of course a thing to keep in mind.
But so far I think for directory separator purposes using DIRECTORY_SEPARATOR is safer.
not sure if you can generalize that. as i wrote in my post, people are using the DIRECTORY_SEPARATOR and it happened to me more than once, that the well-intentioned DIRECTORY_SEPARATOR simply broke stuff.
of course you arguments are really good ones, i simply try to balance what happens more often, a special encoding which is known to break things or a DIRECTORY_SEPARATOR which is used wrong because it can't be tested on linux systems.
I understand URL's slashes came from UNIX based directory separator so DIRECTORY_SEPARATOR is almost equal to the URL's.
Though, I think there are a bunch of Windows PHP coders in the world, at least in Asia. (I'm a macOS user but I've seen many)
As a info, in a non-English locale env such as Japan, backslash \ is replaced as ¥ as a directory separator. Yes, different ASCII code they are, so even more annoying.
So if you aim to code for an international usage, or run the script on their env., I think DIRECTORY_SEPARATOR is worth to care about it.
Since, with this, you can think less about the locale to access files, run the script. Except if you're using it for URL or directory path.
and to which symbol
/is replaced? if it stays the same your argument that\is replaced to¥also hardens my argument to only use/as separator/(as a directory separator) is¥on Japanese Win env.And on non-UNICODE encoding env such as Shift-JIS,
\is displayed also as¥.Since we have to handle a lot of encodings (Shift-JIS, JIS, EUC, UTF-8, UTF-16) until all the systems become UTF-16 or at least UTF-8, we have to convert encoding each other.
The problem is, Windows10 JP uses half Shift-JIS and half UTF-16 inside, so you can type
/,¥,\as is.But once changing the encoding (UTF-8 -> S-JIS) it becomes a mess. Imagine
\as escaping and directory as/becomes all¥.Well, I agree "always using
/as a directory separator" would be nice. Really.But so far I think for directory separator purposes using
DIRECTORY_SEPARATORis safer.that sounds odd... of course a thing to keep in mind.
not sure if you can generalize that. as i wrote in my post, people are using the
DIRECTORY_SEPARATORand it happened to me more than once, that the well-intentionedDIRECTORY_SEPARATORsimply broke stuff.of course you arguments are really good ones, i simply try to balance what happens more often, a special encoding which is known to break things or a
DIRECTORY_SEPARATORwhich is used wrong because it can't be tested on linux systems.But you shouldn't use DIRECTORY_SEPARATOR on urls, hence your "simply broke stuff" issue.
It's like using
move_uploaded_fileto move file A.txt to B.txt, it simply won't work.