Nope.
Get what you’re saying… at a byte level there may be two or more ways to represent a non-ansi letter.
So that testing for String or Text equality would fail.
Seems to me there are 2 basic issues:
1/ Case sensitivity… easy to test for and we should really have been doing that for years. (However the vast majority of user installs are case-insensitive as far as Xojo file handling is concerned, so most people dont bother)
2/ Normalisation: if I understand that right, browsing for a file will be OK. Saving a file will be OK. But what could fail is storing a filename today and trying to use it tomorrow to locate a file?
If so, I dont yet follow what we/Xojo need to do to mitigate the normalisation issue caused by storing a file name.
We are not alone dealing with the issue of accented characters. All Europe but UK and Ireland is concerned. I seems XCode is not immune. In the short term, using composited characters does the trick. It looks feasible to have a short method replace all normal accented characters by the composited equivalent.
I have the feeling we may see sooner than later some framework function doing just that. Or they will modify APFS to accept accented characters.
thanks for the insights on encodings, normalization, representations, a.s.o. of chars in files, disks and memory.
I had a couple of issues some times ago, when releasing an app for macOS and Windows, which had to talk to each another
with a server involved, running on Windows. From time to time file contents, filenames, and even pathes, as saved in
configuration files were not be able to open anymore. Which caused some minor incidents with looping backups being created, and so on.
Later I recognized some of this behaviors by looking into files with a HEX viewer, noticing Little Endian, Big Endian, and all those stuff. After switching the whole application, all created files, storages etc. to one Encoding and way they’ve been handled - every thing worked out well. To be honest, in first place I thought it might be a failure of the Xojo Framework, or OS APIs, but then I had to admit that I just was not aware of such issues -> creating cross platform applications always involves further investigation into the operating systems and their Design Principles.
So many thanks for the detailed insights on such issues. I will keep them.
BTW, not sure if that’s already been mentioned, but the Apple APFS engineers eventually saw the light and updated the APFS code to be now more compatible with HFS behavior: On a case-insensitive APFS volume (which should be the default for Macs, vs. case-sensitive for iOS) case and the Unicode form will be preserved but looking up file names will be insensitive to the case and form. Latest macOS versions (10.12.6 and 10.13b4) already behave that way.
I would still encourage everyone to build & test on case preserving case sensitive file systems just to avoid surprises when someone DOES run your software on such a set up
