Bug 81400

Created attachment 5963 [details]
lucida's patch on this issue

It works for Chinese. If it wouldn't affect other languages, please accept it.

Hi, I didn't submit this patch because it's kind of "dirty hack". In fact, it's not the problem of kfile-plugins, but the taglib's. You may wanna check this:

http://bugs.kde.org/show_bug.cgi?id=78200

The best way is to add an option and let user choose the encoding for their id3(as the new kio-ftp does), but before this, I think it's better to leave thing untouched.

Well, these patches definitely won't work in a lot of cases.  Specifically ID3v2 does properly support Unicode and this would mangle the output coming back.

Also using the current locale won't work in a lot of cases because then you won't be able to display files that you get from someone outside of your locale, or things will break if you switch from one locale on your system to another (say you upgrade your distro and it's using UTF8 -- all of the sudden you won't be able to read your tags anymore).

The basic problem is that ID3v1 is a bad format -- it doesn't support text encodings other than ISO-8859-1, but that hasn't stopped people from throwing arbitrary data in there.

The only acceptable hack in my opinion is to make this something that's selectable by the user.

Please also see:

http://bugs.kde.org/show_bug.cgi?id=78428
http://bugs.kde.org/show_bug.cgi?id=77710

You can check if something is valid utf-8 and fall back to locale if not.
See KStringHandler::isUtf8(const char *buf)

> You can check if something is valid utf-8 and fall back to locale if not.

Well, but actually both of those are incorrect.  :-)  The original report is actually incorrect -- the plugin doesn't currently assume utf-8 as most programs write either ISO-8859-1 or the local encoding.  This gets messy because the current locale may not be the locale at the time or machine that the file was tagged.  (And since, well, a lot of mp3 files are downloaded this just complicates things.)

*** Bug 82640 has been marked as a duplicate of this bug. ***

Input charsets problems may be difficult to solve (one has to guess if file was encoded in local encoding or UTF-8.

But worse is that even editing tags is broken (entered local characters seem to be autoconverted to latin1). This surely could be fixed, as it is possible to check for current charset.

*** Bug 83821 has been marked as a duplicate of this bug. ***

Created attachment 8342 [details]
Patch to convert from TString to QString and QString to TString

Created attachment 8343 [details]
Snapshot showing a tag

Comment on attachment 8342 [details]
Patch to convert from TString to QString and QString to TString

With this patch is possible to display a unicode tag correctly and whe saving a
tag convert it in utf-8. It works for me. See the seconde attach I made for a
screenshot.

Right, but that won't work for tags that are actually valid.

Then, a kcm module would be nice.

How is this going?

Don't get your hopes up. You're asking the developer to break the compliant behaviour so that broken files can be read.

What is your apptitude towards an environment variable?

GStreamer has populated[1] a environment variable GST_ID3_TAG_ENCODING used to phrase the id3v1 tags. It would be a good start if kdemultimedia could use that encoding to phrase id3v1 tags.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=149274#c17

Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.