> Le 7 mars 2017 à 21:03, davel...@mac.com a écrit : > >> >> On Mar 7, 2017, at 1:19 PM, Alastair Houghton <alast...@alastairs-place.net> >> wrote: >> >> On 7 Mar 2017, at 12:47, Jean-Daniel <mail...@xenonium.com> wrote: >>> >>> Did you try to use NSString -fileSystemRepresentation instead of UTF-8, or >>> even better, use URL. While using UTF-8 for path worked well on HFS+, It >>> was never guaranteed to work on all FS. >> >> FWIW, the macOS kernel does use UTF-8 at the VFS interface (and therefore >> the BSD syscalls that take path arguments expect UTF-8). This is different >> to most other UNIXen (which tend to treat paths as a bunch of bytes, at >> least at syscall level and often at filesystem level too). It’s definitely >> the case that for the built-in FAT, NTFS and HFS+ implementations, UTF-8 >> will work. Other filesystem implementations really *should* be treating >> what they get as UTF-8 too, but obviously that’s not guaranteed. >> >> AFAIK all -fileSystemRepresentation does is it processes the Unicode string >> according to the rules in TN1150 and then convert to UTF-8; but you don’t >> actually *need* to do the HFS+ mapping (TN1150) before calling the BSD API >> (and it doesn’t even make any sense to do so unless the filesystem is HFS+, >> which -fileSystemRepresentation has no way of knowing). The main benefit is >> that the result will compare bytewise equal with a filename read from the >> filesystem (assuming HFS+). On other filesystems, well, things are >> different. VFAT and later variants store UTF-16, as does NTFS, but the >> rules in both cases differ. ExtFS, UFS et al. tend to regard filenames as a >> bunch of bytes and don’t even try to record what encoding was used. I don’t >> know what ZFS, XFS or JFS do; using Unicode at filesystem level on a >> UNIX-like system is not unproblematic (because it may very well *not* be the >> same encoding being used at the user’s terminal), but equally the bunch of >> bytes approach creates all kinds of fun (you may *see* a file with a >> particular name, but you can’t necessarily name it yourself from the >> keyboard...) >> >> Not that I’d recommend *not* using -fileSystemRepresentation; Apple says we >> should, so we should. I’m just observing that it isn’t a particularly good >> API and in future it’ll either be deprecated or do the exact same thing as >> -UTF8String because there’s really no other good option I can see. >> >> Kind regards, >> >> Alastair. > > I saw the other posts about fileSystemRepresentation and tried the code I > posted earlier in the thread didn’t have any effect. > > My app has the option to zip up the directories UIManagedDocument creates and > email it (so users can back up their data or share it with others). The > person sent it to me. Below is what I did in the Terminal so you can see what > happens when I try to unzip it. If this doesn’t come through on the email > list with the characters looking correct, I can screenshot it. > > This is one of the data files that was created on iOS 10.2 and then won’t > open now on an iOS 10.3 device. It appears the directory name and zip file > name do not match and it won’t unzip correctly. It does create a directory > but the directory is empty instead of containing the StoreContent and > persistentStore files. The zip file is 34KB so it may or may not actually > have the data in it. > > $ ls > إعلام.zip > > $ unzip *.zip > Archive: إعلام.zip > checkdir error: cannot create Ϻ+?Ϧ+?Ϻ+?/StoreContent > No such file or directory > unable to process Ϻ+?Ϧ+?Ϻ+?/StoreContent/persistentStore. > checkdir error: cannot create Ϻ+?Ϧ+?Ϻ+?/StoreContent > No such file or directory > unable to process Ϻ+?Ϧ+?Ϻ+?/StoreContent/persistentStore-shm. > checkdir error: cannot create Ϻ+?Ϧ+?Ϻ+?/StoreContent > No such file or directory > unable to process Ϻ+?Ϧ+?Ϻ+?/StoreContent/persistentStore-wal. > > $ ls > ?+%F2Ϧ+%E4?+%E0/ إعلام.zip > > When you unzip it, it should create a directory with the exact same name as > the .zip file (just without the .zip extension). > > This may be enough information that it’s worth filing a bug report now. Does > anyone have any other suggestions? Again, creating an Arabic file on iOS 10.3 > works fine, but these ones that were created on 10.2 do not open on 10.3.
If new files work but old ones are broken, so it is probably a FS migration issue. Look like something went wrong while converting HFS to APFS, and I’m not sure you can do something about it (but fill a bug report to Apple). _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
