Closed ghost closed 9 years ago
Now that I think about it further, normalization (the first solution I thought of) wouldn't have worked. It's improbable that MPD mangle with unicode forms at all. The NFD form probably comes directly from my filenames.
So the proper fix is to do what is necessary to avoid any form mangling at all, which is what we do in this PR.
This also make our steps to reproduce more precise:
Also, here's a link that explains what this whole NFC/NFD thing is all about: https://en.wikipedia.org/wiki/Unicode_equivalence . See the table for an illustration of the differences.
Thanks for pointing this out
Previously, browsing entities with non-ascii characters in their URI under Safari wouldn't work. Directories would be empty, songs wouldn't be added. I haven't tried it, but this behavior seems to be common to Webkit-based browsers, so Chrome would be affected too.
This turned out to be because Safari normalizes all unicode strings to NFC, breaking the link with MPD-spewed URIs, which are in NFD.
An obvious fix would have been to normalize all URIs to NFD, but unfortunately, Safari doesn't have
str.normalize()
. Adding normalization capabilities to our JS side would have involved introductiing libraries such asunorm
, which is rather big.We could have done it on the C side, but it involves introducing
icu
, which is far from trivial too.After much fussing around, I stumbled on a simple solution: URI-encode our URI when creating our browser table row. This magically prevents Safari from trying to mess with our unicode form before we get the chance to send it back to our server.