On Tue, Sep 30, 2008 at 2:43 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: > Of the suggestions I've seen so far, I like Marcin's Mono-inspired > NULL-escape codec idea the best. Since these strings all come from parts > of the environment where NULLs are not permitted, a simple "'\0' in > text" check will immediately identify any strings where decoding failed > (for applications which care about the difference and want to try to do > better), while applications which don't care will receive perfectly > valid Python strings that can be passed around and manipulated as if the > decoding error never happened. I'm not so sure. While it maintains *internal* consistency, printing and displaying those filenames isn't likely going to give useful results. E.g. on the terminal emulator I happen to be using right now null bytes are simply ignored. Another danger might be that the null character may be seen as the end of a string by some other library. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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