You have two options: the first is a category adding a stringWithUnichar method to NSString:
@interface NSString (MNNSStringWithUnichar)
+ (NSString *) stringWithUnichar: (unichar) value;
@end
@implementation NSString (MNNSStringWithUnichar)
+ (NSString *) stringWithUnichar:(unichar) value {
NSString *str = [NSString stringWithFormat: @"%C", value];
return str;
}
@end
Then call it with
NSString *otherString = @"TestString";
NSString *str = [NSString stringWithUnichar:[otherString characterAtIndex:1]];
or you could just directly go like this:
NSString *str = [NSString stringWithFormat:@"%C",[otherString characterAtIndex:1]];
Choose the category if you want to use it repeatedly, or if you only have to do it once, use the stringWithFormat example!!
Not to sure about the internals of NSString, but I'd guess it is probably wrapping a
unichar *
or an array of unichars (like a C char *)
A unichar is simply a 16bit value that is used to store a character. Unlike an unsigned char which is only 8 bits, it can hold more than 0-255, so it can hold unicode characters as well, which are 16bits. A NSString is a (cluster of) class[es] that contains an array of unichars
EDIT
Here are a few articles about what people think an NSString is:
http://cocoawithlove.com/2008/08/string-philosophies-char-arrays.html
http://www.reddit.com/r/programming/comments/6v1yw/string_philosophies_char_arrays_stdstring_and/
Hope that helps!
Another option is to use the class method:
+ (id)stringWithCharacters:(const unichar *)characters length:(NSUInteger)length;
So just using:
yourString = [NSString stringWithCharacters: &yourChar length: 1];
The yourChar parameter must be a pointer.
NSString is really a class cluster. That means for various reasons including performance based on content and size and to support toll free bridging to CFString when you create an NSString you may actually get one of many private classes that return YES to isKindOf: when you ask it if it is an NSString and it will respond to all of the methods in the NSString class. It's like a Protocol but all objects will say and do and be NSString in the public API.
As the documentation states for NSString and CFString it is conceptually an array of UTF16 unichar It may and will use a different internal representation where it presents an advantage to the implementation. Usually performance sometimes memory size. But you can rely on it giving you a C array of unichar when asked or anything else the API promises.
It's had a long time to mature and is tweaked internally in nearly every release.
In short yes you can think of it as being backed by an array of UTF16 unichar largely matching the description of a logical string in the Unicode standard. But the thing to keep in mind is that you really should not need to worry what's inside, only what it tells you is inside.
It's one of the best implementations of Unicode. If you want a fuller picture of how it works you can look at ( most ) of the source of CFString at opensource.apple.com It's C and Core Foundation (object oriented C) and fairly stylized, so don't expect to understand it all at once.
NSString and CFString do have methods to return and create from unichar. Most people should not need those most of the time. If you do, be careful, be prepared to read a lot and to make naive mistakes. Unicode is a big topic. Handling it correctly is a science and an art at that level. That is one of the reasons for NSString. It handles a lot of the hard stuff so you do not have to so often, unless you want to or need to.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With