On 06:16 pm, guido at python.org wrote: >On Tue, Sep 30, 2008 at 11:12 AM, <glyph at divmod.com> wrote: >>The one thing it doesn't do is expose the decoding rules for the >>higher- >>level applications to deal with. I am pretty sure I don't understand >>how >>the interaction between filesystem encoding and user locale works in >>that >>case, though, so I can't immediately recommend a way to do it. > >You can ask what the filesystem encoding is with >sys.getfilesystemencoding(). On my Linux box I can make this return >anything I like by setting LC_CTYPE=en_US.<whatever> (as long as ><whatever> is a recognized encoding). There are probably 5 other >environment variables to influence this. :-( Only 5? Great! :-) >Of course that doesn't help for undecodable filenames, and in that >case I don't think *anything* can help you unless you have a lot of >additional knowledge about what the user might be doing, e.g. you know >a few other encodings to try that make sense for their environment. There are other ways to glean this knowledge; for example, looking at the 'iocharset' or 'nls' mount options supplied to mount various filesystems. I thought maybe Python (or some C library call) might be invoking some logic that did something with data like that; if not, great, one day when I have some free time (meaning: never) I can implement that logic myself without duplicating a bunch of work.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4