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.