>>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.

It gets weirder - now MY computer exhibits unexpected results...
I looked at the thing from a few sides - afiles() reads correct file names, even down to "§", "°", "," and so on.
in command window Umlaute are shown - verified by dir-ing known problematic file areas.
Piping those from command line directly: Umlaute in result file.
Hypothesis: somehow my calling modes from vfp drop wrong chars.
As you know, vfp Runs worst side is the inability to pipe results into text file.
So I usually execute such stuff via script host, as there I can pipe and hide the COMSPEC window.
Fallback for environments with disabled scripting is generating and calling batch flies, which can pipe even from RUN.
No such luck - generating big stage files for worst offender frm the commandline working errorless before results in bad droppings...
The I realize that monster result file, piping dirs of ALL discs has correct Umlaute! Also the first (smallest disc)...
Next hypothesis: when a file has somehow been fed Umlaute early, they will stay correct later on.

Piping via command and batch into an erg file already fed umlaute seems to work, so I quickly insert single file dir calls in front of each call in batch file mode - works. Creating single disc stage files via script host would need more changes, but dropping Dummy files in root works as well in all cases.