Implemented in 4.3
WebDAV was the first "trigger" for all these issues, as we can't have "on-the-fly" node renaming as we have in AdminCentral's tree.
- some clients/OSs tend to use one or the other normal forms
- if we allow node names to be created with non-ascii characters in webdav, we must ensure all of Magnolia (tree, renderers, ...) are able to cope.
- the current pitfalls are:
- dialogs: if you url-encode the path (
mgnlPathas an hidden field in the dialog: the browser double-encodes it (which is the expected behavior, and thus we'd need to double-decode on the server as well, which seems quite flaky); if you do not encode this form parameter, it seems some browsers temper with it; Safari has been seen changing a value, which was originally in the NFD form, to NFD)
- having the new service/rest infrastructure in place should help with such issues, as we'll have better control on what gets encoded where, and how.
- the attached
test.jspshows that Safari swaps an NFD-formed string to its NFC form. (Tested Safari 4.0.3 and Chrome 188.8.131.52 on OSX, and Chromium 184.108.40.206 on Ubuntu, which all show this behaviour; Firefox 3.0.4 and Opera 10, on the other hand, seem better behaved and respect the given encoding)
When trying things out, one might need to manually create names in the NFC or NFD forms specifically
Seems we're not the only ones struggling: http://twiki.org/cgi-bin/view/Codev/UnicodeMac
And this confirms that WebKit is probably doing normalization to NFC on purpose! : https://bugs.webkit.org/show_bug.cgi?id=8769 (since 2006) http://www.w3.org/TR/charmod-norm/#sec-UnicodeNormalized