On 4/6/2015 4:03 PM, Greg Parker wrote:
Right. But what you were describing *would* be UCS-2. To claim UTF-16 support, variable length encoding must be handled. You cannot legitimately claim UTF-16 support by only handling a fixed-size encoding (i.e., a single code unit). So, if UTF-16 support is intended, as documented, then there has to be a bug, as I stated in an earlier post; and as you did also in a later post (albeit with a different reasoning).On Apr 6, 2015, at 2:20 PM, pscott <psc...@skycoast.us> wrote:On 4/6/2015 12:29 PM, Greg Parker wrote: I'm not an expert here, but my understanding is that when Cocoa says "character" it usually means "UTF-16 code unit". @"🚲".length == 2, for example. Cocoa's string API designed when Unicode was still a true 16-bit character set.That would be UCS-2 encoding. If the full Unicode character set of 1,112,064 characters isn't supported it should not be documented as supporting UTF-16.No, it's not UCS-2. The API generally works as if it were manipulating an array of UTF-16 code units. @"🚲" displays correctly; it would not if the system were truly UCS-2.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 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
