On Mon, Dec 01, 2014 at 10:38:40AM +0200, pizdel...@gmail.com wrote: > On Sat, Nov 29, 2014 at 09:48:53PM +0100, Dmitrij D. Czarkoff wrote: > > That said, the standard provides just enough facilities to make > > filesystem-related aspects of Unicode work nicely, particularily in case > > of utf-8. Eg. ability to enforce NFD for all operations on file names > > could actually make several things more secure by preventing homograph > > attacks. > > How do you 'enforce' NFD?
Anything that stores filenames outside the filesystem (e.g. in a database) for later use will have problems if NFD or NFC is enforced by the filesystem. Version control systems are particularly prone to this issue. Apple HFS+ does such normalisation behind the application's back. Put a file with a funky name on disk, read the containing directory back, and you might not find any directory entry matching the byte sequence written. Not a smart idea if you ask me since it breaks applications which weren't written with normalization in mind. Example: http://subversion.tigris.org/issues/show_bug.cgi?id=2464 Git suffers from the same problem (and ended up committing a patch that simply ignores compat to existing repositories from version 1.7.12 onwards?!?) http://mail-archives.apache.org/mod_mbox/subversion-users/201208.mbox/%3C501D29CF.6000308%40web.de%3E The only VCS I know of which normalized from day one is Veracity. Not because the developers were experts on Unicode, but because they had the benefit of hindsight -- they link to the above SVN bug from a comment in their code. Design-by-committee giving us standards that ignore existing realities.
