Some unicode characters, e.g. ö, can be represented in alternative ways (like a single character, or decomposed into a couple of characters, like o + "two upper dots modifier"); and different file systems might handle such characters differently; and in RN code we want to achieve uniform cross-platform behavior, thus perhaps need to level-out the differences.
So far I figured out:
- Android conserves single-characters (composed form), like
ö, in paths as they are. I have not checked / read what does it do with decomposed ö (represented as o + modifier).
- iOS (and, I guess, macOS — to be verified) filesystem decomposes such characters, which on TS side can be expressed that given
path string is transformed into path.normalize('NFD').
- Windows — to be investigated.
What should we do? Perhaps, all paths returned by library methods should be normalized as NFC normalization (the default for JS string.normalize())?
Some unicode characters, e.g.
ö, can be represented in alternative ways (like a single character, or decomposed into a couple of characters, likeo+ "two upper dots modifier"); and different file systems might handle such characters differently; and in RN code we want to achieve uniform cross-platform behavior, thus perhaps need to level-out the differences.So far I figured out:
ö, in paths as they are. I have not checked / read what does it do with decomposedö(represented aso+ modifier).pathstring is transformed intopath.normalize('NFD').What should we do? Perhaps, all paths returned by library methods should be normalized as
NFCnormalization (the default for JSstring.normalize())?