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 init.py:

LOCAL_ENCODING = locale.getpreferredencoding(do_setlocale=False);
if not LOCAL_ENCODING or LOCAL_ENCODING == "ANSI_X3.4-1968":
    LOCAL_ENCODING = 'latin1';

If LOCAL_ENCODING is either None or ANSI_X3.4-1968, the encoding is treated as latin1. In my Gentoo box, with do_setlocale is configured False, getpreferredencoding 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.

We may investigate the Linux locale behavior later, for the time being let’s apply the patch to eyeD3’s __init__.py:

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