An issue with cross-platform support of unicode characters in paths

[birdofpreyru]

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())?

[birdofpreyru]

For record: the decision I took — all paths and filenames returned by library functions should not be escaped in any way, and should be unicode-normalized to their NFC form, with the normalization, if necessary, done at the native side, for optimal performance.

Corresponding fix was done for readDir() on iOS, and macOS (see c5307815d8603dc3ea1417159266300eb29eaa50), but I guess a similar fix might be needed for other iOS and macOS methods. I don't have capacity to thoroughly test every method now, thus I'll keep this ticket with In Progress and On Hold status, meaning I'll probably be further testing and fixing methods for this issue only as I bump into it causing problems to my projects.