Re: NSString and file system Re: AppleScript in Sandboxed App
Re: NSString and file system Re: AppleScript in Sandboxed App
- Subject: Re: NSString and file system Re: AppleScript in Sandboxed App
- From: Daniel Höpfl <email@hidden>
- Date: Wed, 16 Jan 2013 18:45:26 +0100
Hello,
On Wed, 16 Jan 2013 17:12:15 +0000, email@hidden wrote:
On 16 Jan 2013, at 15:50, Fritz Anderson <email@hidden>
wrote:
On 16 Jan 2013, at 3:52 AM, "email@hidden"
<email@hidden> wrote:
Py_SetProgramName((char *)[[scriptRunner launchPath] UTF8String]);
If a char* is destined for the file system, you should be using
-fileSystemRepresentation, not -UTF8String.
I forget that all the time.
To be honest I rarely remember to call -fileSystemRepresentation.
The docs seem to indicate that its only purpose is to replace
abstract / and . characters with OS equivalents.
On OS X this would have seem to have no net result.
Is there more to this?
For some codepoints (e.g. umlauts) there is more than one way to
represent them in Unicode (composed/decomposed):
NSString *str = @"/äöü.txt";
const char *utf8 = [str UTF8String];
const char *file = [str fileSystemRepresentation];
NSLog(@"utf8: %zd %s", strlen(utf8), utf8);
NSLog(@"file: %zd %s", strlen(file), file);
Results (depending on the filesystem, I guess) in:
UTFFilename[6260:403] utf8: 11 /<glyphs>.txt
UTFFilename[6260:403] file: 14 /<different glyphs>.txt
Think of it as "umlaut-a/o/u" vs. "a/o/u, as umlaut"
Both encodings work but e.g. SVN has (had) problems with files that
contain umlauts: They used the composed name internally but the
filesystem returns the decomposed variant on OS X. Blindly comparing the
UTF-8 byte arrays failed.
Bye,
Daniel
_______________________________________________
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