iTunes xml formatting change from NCR to true UTF-8 characters ?

[alec.tron]

Heya,
I have an xml, from:

Code

	<key>Application Version</key><string>3.2.6721.35740</string>

listing this:

Code

			<key>FilePersistentId</key><string>ÿ2</string>

Whereas in an older version:

Code

	<key>Application Version</key><string>3.2.6700.32523</string>

the same was formatted with NCRs like this:

Code

			<key>FilePersistentId</key><string>ÿ2</string>

[PS - blaergh ... the forum  software also reformats NCR into UTF-8 characters... the above ÿ2 should read the following (without the spaces...):

<key>FilePersistentId</key><string>& # 2 5 5 ; 2</string>

]


Was this a conscious & global change ?
Or is this a setting/variable ?

I'm asking as I'm seeing some erratic errors with programs consuming the xmls that weren't present with NCR encoding... and since Apple (did) use NCRs (afaik), I was just wondering what the state/intention is here.

Cheers.
c.

[alec.tron]

Also, what feels odd additionally is that NCRs are still used in some fields...

i.e. these now show UTF-8 characters now for umlauts/diacritic marks etc:
FilePersistentId
Artist
Title

But others still use NCRs instead of full UTF-8 formatting... i.e. most notably the xml keys for
Location
as well as some custom metadata fields of mine that make it into the xml... i.e.
DISCOGS_RELEASE_GENRES

In the short term, if this is intentional, would be nice to have an option still to stick to the (imo) more consistent previous NCR way of things.

Cheers.
c.

[Steven]

Nothing has been changed for the iTunes export but if you have been using any of boroda74's storage/ device plugins then it can set a value in the FilePersistentId field.
The field should really be excluded from the iTunes export, so i have done that for the next patch update

MB currently only converts reserved XML characters to NCRs (<,>,&,',"). I am not aware there is any requirement to convert non-ascii chars to NCRs.


https://getmusicbee.com/patches/MusicBee32_Patched.zip