>But as you probably have more encounters with different codepages, languages and what else:
>currently we have to wade through oodles of files dropped willy-nilly some places in the file system.
>Spaces in file names are nothing new, but they drop names with german umlauten, "^", "§", "°" and other stuff.
>
>Did not drill down in programming, but opted for a quick analogue to
>
>dir %1:\*.xyz /s /b > %1_erg_xyz.erg
>
>which gives nice stable stage tables to import, is much faster than coded stuff but is plagued by piping something different from "äöü" into the erg file.
>cleaning german umlaute was easy, but how to prepare for french, spanish, slavic or kyrillic droppings ?
>any strconv(), cpconvert() orenvironment variable to set or transformation you are aware of as typical solution working across many languages ?

The trouble is that if the OS gets a file which it can't create itself, it usually doesn't see it, or, in any tool you use, converts the string into something else, and then when you try to rename the file, it can't find it because the name it's looking for is not the name on disk.

One solution would be to urlencode the filenames, which would give you %20 for every space but then any OS can read it. Just make sure that what your renaming tool reads is the true filename (unicode, preferrably), not some translation.

I've had some trouble with some exported emails, because it created files with several pieces of punctuation in the filename - I think the offending one was the colon. So it created files which windowses can't read. Had to make it run on a partition which was a shared linux disk, and then wrote a routine (in fox) to rename them, running it from fox under wine. However, wine was true to its simulation of windows environment, and refused to see the files. Eventually had to rename them by hand and then I had files usable under windowses.