Re: Unicode filenames with Apple File System and UIManagedDocument
Re: Unicode filenames with Apple File System and UIManagedDocument
- Subject: Re: Unicode filenames with Apple File System and UIManagedDocument
- From: Jean-Daniel <email@hidden>
- Date: Wed, 08 Mar 2017 08:23:12 +0100
> Le 7 mars 2017 à 21:03, email@hidden a écrit :
>
>>
>> On Mar 7, 2017, at 1:19 PM, Alastair Houghton <email@hidden> wrote:
>>
>> On 7 Mar 2017, at 12:47, Jean-Daniel <email@hidden> 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
> ?+òϦ+ä?+à/ إعلام.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 (email@hidden)
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:
This email sent to email@hidden