Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 11
  1. #1
    Senior Member
    Join Date
    Jul 2010
    Posts
    219

    get request for metadata to return special characters in correct way

    Hi.

    If I have track urls in a plugin
    how do I get the metadata (track title, artist/album name) of tracks that contains special characters in a way that these special characters are returned/displayed correctly?

    I always end up with the mangled version. I've tried to utf-8 decode something at some point but must be doing it wrong so far. Thank you for your help.

  2. #2
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,530

    get request for metadata to return specialcharacters in correct way

    > If I have *track url*s in a *plugin*
    > how do I get the *metadata* (track title, artist/album name) of tracks
    > that contains special characters in a way that these special characters
    > are returned/displayed correctly?


    Simplest probably is to use the queries, as documented in the CLI. The
    "songinf" query would accept the URL and return the data you want (see
    http://htmlpreview.github.io/?https:....html#songinfo).

    > I always end up with the mangled version. I've tried to utf-8 decode
    > something at some point but must be doing it wrong so far. Thank you for
    > your help.


    If you want to deal with the raw data you might need to
    utf8::decode(...) your data, like those queries do. See eg.
    https://github.com/Logitech/slimserv...eries.pm#L5621

  3. #3
    Senior Member
    Join Date
    Jul 2010
    Posts
    219
    Quote Originally Posted by mherger View Post
    > If I have *track url*s in a *plugin*
    > how do I get the *metadata* (track title, artist/album name) of tracks
    > that contains special characters in a way that these special characters
    > are returned/displayed correctly?


    Simplest probably is to use the queries, as documented in the CLI. The
    "songinf" query would accept the URL and return the data you want (see
    http://htmlpreview.github.io/?https:....html#songinfo).

    > I always end up with the mangled version. I've tried to utf-8 decode
    > something at some point but must be doing it wrong so far. Thank you for
    > your help.


    If you want to deal with the raw data you might need to
    utf8::decode(...) your data, like those queries do. See eg.
    https://github.com/Logitech/slimserv...eries.pm#L5621
    For example, the songinfo_loop array of hashes contains the hash:
    {
    'title' => "Evoca\x{e7}\x{e3}o n\x{ba} 1"
    },

    which should be "EvocašŃo n║ 1".

    But when I do
    Code:
    foreach my $elem ( @{$songinfohash} ){
    	foreach my $key ( keys %{ $elem } ){
    		if ($key eq 'title') {
    			$title = $elem->{$key};
    		}        
    	}
    }
    $log->debug("title = ".$title);
    it comes out as Evoca├ž├úo n┬║ 1.
    I've tried utf8::decode($title), unescape and others. But I can't seem to get the correct string.

  4. #4
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,303
    Quote Originally Posted by afriend View Post
    it comes out as Evoca├ž├úo n┬║ 1.
    I've tried utf8::decode($title), unescape and others. But I can't seem to get the correct string.
    The issue might be what is displaying the string.

    "$log-Debug" output in a file output examined on a terminal screen can be different to a Web page or Touch/Radio display.

  5. #5
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,303
    Looking at the issue another way.

    Quote Originally Posted by afriend View Post
    'title' => "Evoca\x{e7}\x{e3}o n\x{ba} 1"
    This will be a string of octets and not a UTF-8 encoded string.

    I've tried utf8::decode($title), unescape and others. But I can't seem to get the correct string.
    I have used Encode::decode('utf8', $title) to create a string which Perl knows is UTF8 encoded form a string which was a series of octets which had the right values to be UTF-8 encoded.

  6. #6
    Senior Member
    Join Date
    Jul 2010
    Posts
    219
    Quote Originally Posted by bpa View Post
    The issue might be what is displaying the string.

    "$log-Debug" output in a file output examined on a terminal screen can be different to a Web page or Touch/Radio display.
    Eventually the string is supposed to be printed to a plain text log file (uft-8, I guess).

    If I use Encode::decode('utf8', $title) it's still not correct but different. Is the problem maybe that it is mixed, Latin and uft-8? Just a guess because encoding is something I've never really had to deal with as a normal user.

  7. #7
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,303
    Quote Originally Posted by afriend View Post
    Eventually the string is supposed to be printed to a plain text log file (uft-8, I guess).
    Does the file have a BOM ?
    Last edited by bpa; 2021-02-16 at 11:58.

  8. #8
    Senior Member
    Join Date
    Jul 2010
    Posts
    219
    BBEdit says no BOM, just "text file". You can see what I'm trying to do here.

  9. #9
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,530

    get request for metadata to return specialcharacters in correct way

    > BBEdit says no BOM, just "text file". You can see what I'm trying to do
    > '*here*'
    > (https://github.com/AF-1/lms-ratingsl...lugin.pm#L1952).


    Instead of

    FileHandle->new($filename, ">>")

    use

    FileHandle->new($filename, ">>:utf8")

    ....or similar. Check out the documentation for perl's "open" operation.

  10. #10
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,303
    Quote Originally Posted by afriend View Post
    BBEdit says no BOM, just "text file". You can see what I'm trying to do here.
    OK.

    If the characters are encoded correctly as UTF8, then the file contents is correct and the problem is in how the file contents is displayed.

    Have you confirmed the file contents is correctly UTF8 encocded (i.e. no chars or bytes lost) using something like "hd" or "od" ?

    If the file is on a UTF8 system then it will natively show the file correctly as the system will expect the file to be UTF8 encoded.
    If the file is on a UTF8 system and then shared to an "old" Windows system - the same file will probably not be displayed correctly.

    A BOM is not essential for UTF8 but it gives a "hint" for system that have some UTF8 capability. Opening a file with ":utf8" I think will at least tell Perl to put a BOM at start.
    Last edited by bpa; 2021-02-17 at 00:49.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •