Filename collation order FZclient 2 and 3-beta

[mwrmwr]

{If I could make this a low priority report I would !}
This is a borderline UI-bug or New feature request depending how you view it.
FZ3b11
With many retries over a week, I have just completed a 76 part download where the names are of the form
<filename>.0
<filename>.1
<filename>.2
:
<filename>.10
<filename>.11
:
<filename>.20
<filename>.21
:

I was happy to live with the awkward and very frustrating to use collation order in FZ (and maybe all FTP servers - maybe its a UNIX standard ?) and cursed the split program for not using .nnn format.
Under FZ, that order shows as:
<filename>.0
<filename>.1
<filename>.10
<filename>.11
:
<filename>.19
<filename>.2
<filename>.20
<filename>.21
etc.

HOWEVER
when I got to check for completeness under M$oftWinXP,
I was pleasantly surprised to find that the more user-friendly order [0,1,2,3...19,20,21, ...] was displayed.

Could FZ directory listing panels use that "friendly-order" (by option if neccessary) or is there some FTP-standard constraint ? Arguably, if the application runs under Windows it should show a consistent collation order with its host.

(Clearly there are issues with trailing space in a file name, but if such a filename can be created (not by standard Windows dialogues) it would have to have been made programmatically - long time since I tried that sort of thing.)

Mark

[Tim Kosse]

Moved to feature request.

Strings are lexicographically sorted with the character order depending on the current locale (FZ 2.x) or simply their value (FZ 3).

A sort order as described above would require a full-blown external library, possibly ICU (​http://www.icu-project.org/)

Impact on sorting performance has to be monitored closely.

[Alexander Schuch]

This is a duplicate of #2978.