Yet another locale problem

In the last post, we manage to leverage eye3D for standardizing the ID3 tag. But we still got messy code when manually manipulating the tags in the command line. It may result in either wrong arguments or encoding bug.

Further investigation focused on eyeD3’s

LOCAL_ENCODING = locale.getpreferredencoding(do_setlocale=False);
    LOCAL_ENCODING = 'latin1';

Either LOCAL_ENCODING is None or mysterious ANSI_X3.4-1968, the encoding is assumed as latin1. In my Gentoo box, with do_setlocale set False, getpreferredencoding just returns ANSI_X3.4-1968 though the locale is en_US.UTF-8 instead.

According to the documentation:

On some systems, it is necessary to invoke setlocale to obtain the user preferences, so this function is not thread-safe. If invoking setlocale is not necessary or desired, do_setlocale should be set to False.

I need to dig into whether Linux belongs to some systems. Right now, just apply the patch to eyeD3’s

< LOCAL_ENCODING = locale.getpreferredencoding(do_setlocale=False);
> LOCAL_ENCODING = locale.getpreferredencoding(do_setlocale=True);

And remember to specify the encoding of tags using –set-encoding, RTFM for more details.