[gstreamer-bugs] [Bug 405072] [API] add gst_tag_freeform_string_to_utf8()

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=405072

  GStreamer | gst-plugins-base | Ver: HEAD CVS





------- Comment #5 from Tim-Philipp Müller  2007-02-08 10:22 UTC -------
> If the user has specified an encoding to use via a Magic Environment Variable,
> we should obey that first and foremost.

Not sure about this, because:

 - conversion from almost any (non-UTF8) 8-bit character
   encoding will be successful, since those encodings tend
   to make use of the whole 8-bit range (minus one or two
   not allowed values, but those tend to be the same). This
   means we can't just "test if this works". It will almost
   always work and then produce bad output.

 - we have environment variables that are very general, like
   GST_TAG_ENCODING and those that are very specific, like
   GST_ID3V1_TAG_ENCODING. Your suggestion would make most
   sense for the very specific ones IMHO.

We could provide API so the caller can tell us which ones are the specific ones
to check first and which ones are the general ones to check later, but I don't
really think it's worth given how small chances are to falsely identify a
non-UTF-8 string as UTF-8.

But then this assertion of mine could just be wrong or, since admittedly I only
checked ISO-8859-* etc. and not, for example, Korean/Japanese/Chinese/other
Asian locales.


> There's an argument that for some of these broken protocols/fileformats, we
> should use the locale after that, and only THEN attempt utf-8, but I don't
> think that's ideal usually.

I think locale should always come last, for the reason mentioned above that
conversion from ISO-8859-* will almost always succeed whatever the input.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email