Sat 15 Oct 2011 09:56:52 AM UTC, comment #8:
thanks can confirm its working now as it should.
|
Fri 14 Oct 2011 07:20:03 AM UTC, comment #7:
Since we formally dropped release for older compilers after the last release in September, we are now free to assume that we are using a compiler which supports UTF-8 in string constants ... so at last it is possible to support it in gnustep-base.
I've modified the constant string handling to assume that the compiler has provided UTF-8 strings (but that does mean perhaps we should also modify gnustep-make to either alert about or strip out any attempt to tell the compiler to use a different character encoding).
|
Wed 05 Oct 2011 09:24:17 PM UTC, comment #6:
i can confirm that works fine. thanks for another nice workaround.
|
Wed 05 Oct 2011 09:03:30 PM UTC, comment #5:
Oh, you can do this: (UTF8 macro just for clarity)
#define UTF8(x) [NSString stringWithUTF8String: x]
#define kTrackNames [NSArray arrayWithObjects: UTF8("Tannhäuser Stargate"), UTF8("Soylent Black"), UTF8("Quantum Circuit"), UTF8("Blaspheme Quarantine"), UTF8("Frogpill Quasar"), UTF8("Terminal Velocity"), nil]
That works by default in gcc for me. It should work as long as the compiler stores C constant strings as UTF-8.
|
Wed 05 Oct 2011 08:48:08 PM UTC, comment #4:
ugh if there is no way at all to get it into a string constant it really is a pain. i've currently this code and see no way how i'd be able to convert that
#define kTrackNames [NSArray arrayWithObjects:@"Tannhäuser Stargate", @"Soylent Black", @"Quantum Circuit", @"Blaspheme Quarantine", @"Frogpill Quasar", @"Terminal Velocity", nil]
and kTrackNames is used throughout the app.
anyway, i'd be happy if it would work using clang trunk and nothing else.
|
Wed 05 Oct 2011 08:36:28 PM UTC, comment #3:
Pretty much the two workarounds right now are putting the utf-16 codepoints in an array and then using -initWithCharacters:length:, or else loading the string from a file (maybe using NSLocalizedString?)
unichar string[2] = { 0x0068, 0x00e }; // utf-16 codepoints for "hé"
NSLog(@"%@", [[[NSString alloc] initWithCharacters: string length: 2] autorelease]);
That's a pain, though.
The \u escape sequence is probably treated the same by the compiler as loading a utf-8 source file, so it makes sense that it doesn't work at the moment.
btw, here is a mailing list post that may have some useful info: http://lists.apple.com/archives/cocoa-dev/2008/Nov/msg02226.html
|
Wed 05 Oct 2011 08:08:55 PM UTC, comment #2:
>historically non-ascii data in ObjC string constants has been disallowed
yes, historically, but this has been changed with Mac OS X 10.5 and i think GNUstep should follow here. source files are encouraged to be UTF-8 and objc string constants with special chars work now - though i couldn't find an official apple document encouraging it. but the fact that they changed things to make it work and Xcode also doesn't warn on this even with all warnings turned on - suggests its here to stay.
> discouraged all uses of anything which implies a default C string encoding elsewhere
yes but i think C string encoding is a completely different issue.
anyway i think this shouldn't be that high priority.
whats more disturbing is that even the workaround, manually specifying the unicode escape sequences doesn't work. e.g.
[mybutton setTitle:@"Her name is M\u00E4dchen"]; // ä
how is this done in gnustep?
|
Wed 05 Oct 2011 07:23:30 PM UTC, comment #1:
I think this is probably an application bug since historically non-ascii data in ObjC string constants has been disallowed (ie strings documented as having to be ascii and behavior for non-ascii documented as unsupported/undefined).
Apple have also active discouraged all uses of anything which implies a default C string encoding elsewhere, and have afaik deprecated all such methods ... so they seem serious about being well behaved and requiring you to specify the encoding of all C strings generally.
However ...
1. you may know of some recent documentation defining a policy change and specifying how non-ascii data is to be handled in future or
2. it might be worth reverse engineering the latest OSX behavior and implementing that even if apple don't want developers to depend on it.
|
Wed 05 Oct 2011 05:41:30 PM UTC, original submission:
gnustep has a problem with non-ascii string constants e.g.
[myButton setTitle: @"hello umlaut ä, ö, ü "];
will result in garbage, even if the line is in a file encoded as UTF-8.
this obviously works fine on Mac OS X / Cocoa.
trivial sample project attached.
|