1) Sorting is pretty much alphabetical - going through files one by one, and that includes any subfolders you may unnecessarily include (so if you have files
"AA", "BB" and
"DD" in the main folder and a
"CC" subfolder with some other images, the subfolder stuff will be processed before the
"DD" file). The only differences come with the numbers: normally it uses a sorting similar to the one in modern Windows and the first number it encounters (e.g.
"abc1211de3") is treated as a single entity (so
"42" comes before
"111"), but if you include a leading zero in said number then it goes back to "classic" alphabetical sorting (i.e. evaluating each digit separately, e.g.
"page011" comes before
"page04" because it first compares 0 to 0 and then the first 1 to 4). Another exception: filenames with JUST the numbers seem to end up before numbers mixed with letters (so
"01","02","2","02withletters"). It's also case-insensitive AFAIK. Thus - if there's a file named
"credits.jpg" or
"cover.jpg" it will come before
"page5.jpg" files, but
"page6_credits.jpg" will come after it.
^that's mostly conclusion based on observation so there may be some more quirks I'm not aware of
2) Best to keep them to simple alphanumerics and not use any fancy characters (like decorative symbols and emoji) or non-english alphabet letters (some of them are not liked by the system and it may either make individual pages unprocessable/skipped or even the whole archive if such characters end up in archive's filename itself). Excessive leading zeroes (stuff like "page000000007") may also cause trouble, but it only seems to happen sometimes to some users (no idea what causes it). Rar archives are more sensitive to filenames. Zip archives using other algortihm than DEFLATE will not be extracted (def64 is not supported either).
3) Empty chapter (no pages to select from in the reader) can be caused by stuff like an interrupted upload (flaky connection), using remote upload with a link that's not direct download (i.e. anything that doesn't lead directly to the file and goes through some download page or redirecting instead), all filenames being unprocessable (or just the archive's filename being bad), there being no jpg/png/gif files inside (in case of scanlations, scanlators seldom may forget to convert their layered psd files). If for whatever reason you end up with files with bad extensions that were renamed to the supported ones (so simply changing the name from "Page01.psd" to "Page01.png" without actually converting to png), it should instead end up as a chapter with multiple error pages (because the extractor initially thought it found images but couldn't process them in the end).