Question

在与CharacterSet合作时，我遇到了一个有趣的问题。根据我目前收集的内容CharacterSet基于UnicodeScalar;您可以使用标量初始化它并检查集合中是否包含标量。查询集合以确定它是否包含Character，谁的字形可以由几个unicode标量值组成，但没有意义。

我的问题在于我使用表情符号进行测试，这是一个单一的unicode标量值（十进制128518）。因为这是一个单一的unicode标量值，我认为它会起作用，结果如下：

"" == UnicodeScalar(128518)! // true

// A few variations to show exactly what is being set up
let supersetA = CharacterSet(charactersIn: "")
let supersetB = CharacterSet(charactersIn: "A")
let supersetC = CharacterSet(charactersIn: UnicodeScalar(128518)!...UnicodeScalar(128518)!)
let supersetD = CharacterSet(charactersIn: UnicodeScalar(65)...UnicodeScalar(65)).union(CharacterSet(charactersIn: UnicodeScalar(128518)!...UnicodeScalar(128518)!))

supersetA.contains(UnicodeScalar(128518)!) // true
supersetB.contains(UnicodeScalar(128518)!) // false
supersetC.contains(UnicodeScalar(128518)!) // true
supersetD.contains(UnicodeScalar(128518)!) // false

正如您所看到的，如果CharacterSet包含单个标量值（可能是由于优化），则检查有效，但在任何其他情况下，它都不会按预期工作。

我无法找到有关CharacterSet的较低级别实现的任何信息，或者它是否以某种编码工作（即NSString之类的UTF-16），但因为API与{UnicodeScalar进行了很多交易。 1}}我很惊讶它没有这样做，我不确定它为什么会发生，或者如何进一步调查。

任何人都可以解释为什么会这样吗？

Answer 1

CharacterSet is available, actually.的源代码contains的来源是：

fileprivate func contains(_ member: Unicode.Scalar) -> Bool {
    switch _backing {
    case .immutable(let cs):
        return CFCharacterSetIsLongCharacterMember(cs, member.value)
    case .mutable(let cs):
        return CFCharacterSetIsLongCharacterMember(cs, member.value)
    }
}

所以它基本上只是调用CFCharacterSetIsLongCharacterMember。 is also available, although only for Yosemite的源代码（El Cap和Sierra的版本都说“即将推出”）。然而，Yosemite代码似乎与我在Sierra的反汇编中看到的相匹配。无论如何，代码看起来像这样：

Boolean CFCharacterSetIsLongCharacterMember(CFCharacterSetRef theSet, UTF32Char theChar) {
    CFIndex length;
    UInt32 plane = (theChar >> 16);
    Boolean isAnnexInverted = false;
    Boolean isInverted;
    Boolean result = false;

    CF_OBJC_FUNCDISPATCHV(__kCFCharacterSetTypeID, Boolean, (NSCharacterSet *)theSet, longCharacterIsMember:(UTF32Char)theChar);

    __CFGenericValidateType(theSet, __kCFCharacterSetTypeID);

    if (plane) {
        CFCharacterSetRef annexPlane;

        if (__CFCSetIsBuiltin(theSet)) {
            isInverted = __CFCSetIsInverted(theSet);
            return (CFUniCharIsMemberOf(theChar, __CFCSetBuiltinType(theSet)) ? !isInverted : isInverted); 
        }

        isAnnexInverted = __CFCSetAnnexIsInverted(theSet);

        if ((annexPlane = __CFCSetGetAnnexPlaneCharacterSetNoAlloc(theSet, plane)) == NULL) {
            if (!__CFCSetHasNonBMPPlane(theSet) && __CFCSetIsRange(theSet)) {
                isInverted = __CFCSetIsInverted(theSet);
                length = __CFCSetRangeLength(theSet);
                return (length && __CFCSetRangeFirstChar(theSet) <= theChar && theChar < __CFCSetRangeFirstChar(theSet) + length ? !isInverted : isInverted);
            } else {
                return (isAnnexInverted ? true : false);
            }
        } else {
            theSet = annexPlane;
            theChar &= 0xFFFF;
        }
    }

    isInverted = __CFCSetIsInverted(theSet);

    switch (__CFCSetClassType(theSet)) {
        case __kCFCharSetClassBuiltin:
            result = (CFUniCharIsMemberOf(theChar, __CFCSetBuiltinType(theSet)) ? !isInverted : isInverted);
            break;

        case __kCFCharSetClassRange:
            length = __CFCSetRangeLength(theSet);
            result = (length && __CFCSetRangeFirstChar(theSet) <= theChar && theChar < __CFCSetRangeFirstChar(theSet) + length ? !isInverted : isInverted);
            break;

        case __kCFCharSetClassString:
            result = ((length = __CFCSetStringLength(theSet)) ? (__CFCSetBsearchUniChar(__CFCSetStringBuffer(theSet), length, theChar) ? !isInverted : isInverted) : isInverted);
            break;

        case __kCFCharSetClassBitmap:
            result = (__CFCSetCompactBitmapBits(theSet) ? (__CFCSetIsMemberBitmap(__CFCSetBitmapBits(theSet), theChar) ? true : false) : isInverted);
            break;

        case __kCFCharSetClassCompactBitmap:
            result = (__CFCSetCompactBitmapBits(theSet) ? (__CFCSetIsMemberInCompactBitmap(__CFCSetCompactBitmapBits(theSet), theChar) ? true : false) : isInverted);
            break;

        default:
            CFAssert1(0, __kCFLogAssertion, "%s: Internal inconsistency error: unknown character set type", __PRETTY_FUNCTION__); // We should never come here
            return false; // To make compiler happy
    }

    return (result ? !isAnnexInverted : isAnnexInverted);
}

所以我们可以跟进，弄清楚发生了什么。不幸的是，我们必须破坏我们的x86_64装配技能才能做到这一点。但不要害怕，因为我已经为你做了这件事，因为显然这就是我周五晚上为了好玩而做的事。

有用的是数据结构：

struct __CFCharacterSet {
    CFRuntimeBase _base;
    CFHashCode _hashValue;
    union {
        struct {
            CFIndex _type;
        } _builtin;
        struct {
            UInt32 _firstChar;
            CFIndex _length;
        } _range;
        struct {
            UniChar *_buffer;
            CFIndex _length;
        } _string;
        struct {
            uint8_t *_bits;
        } _bitmap;
        struct {
            uint8_t *_cBits;
        } _compactBitmap;
   } _variants;
   CFCharSetAnnexStruct *_annex;
};

我们还需要知道CFRuntimeBase到底是什么：

typedef struct __CFRuntimeBase {
    uintptr_t _cfisa;
    uint8_t _cfinfo[4];
#if __LP64__
    uint32_t _rc;
#endif
} CFRuntimeBase;

猜猜是什么！还有一些我们需要的常量。

enum {
        __kCFCharSetClassTypeMask = 0x0070,
            __kCFCharSetClassBuiltin = 0x0000,
            __kCFCharSetClassRange = 0x0010,
            __kCFCharSetClassString = 0x0020,
            __kCFCharSetClassBitmap = 0x0030,
            __kCFCharSetClassSet = 0x0040,
            __kCFCharSetClassCompactBitmap = 0x0040,
    // irrelevant stuff redacted
};

然后我们可以打破CFCharacterSetIsLongCharacterMember并记录结构：

supersetA.contains(UnicodeScalar(128518)!)

(lldb) po [NSData dataWithBytes:$rdi length:48]
<21b3d2ad ffff1d00 90190000 02000000 00000000 00000000 06f60100 00000000 01000000 00000000 00000000 00000000>

根据上面的结构，我们可以弄清楚这个字符集的构成。在这种情况下，相关部分将成为cfinfo的{{1}}的第一个字节，即字节9-12。这个的第一个字节CFRuntimeBase包含字符集的类型信息。它必须0x90与AND __kCFCharSetClassTypeMask，0x10，__kCFCharSetClassRange。

对于这一行：

supersetB.contains(UnicodeScalar(128518)!)

结构是：

(lldb) po [NSData dataWithBytes:$rdi length:48]
<21b3d2ad ffff1d00 a0190000 02000000 00000000 00000000 9066f000 01000000 02000000 00000000 00000000 00000000>

此时间字节9为0xa0，AND掩码为0x20，__kCFCharSetClassString。

此时，Monty Python演员正在尖叫“Get On With It！”，所以让我们浏览CFCharacterSetIsLongCharacterMember的来源，看看发生了什么。

跳过所有CF_OBJC_FUNCDISPATCHV垃圾，我们到达这一行：

if (plane) {

在这两种情况下，这显然都是真实的。下一个测试：

if (__CFCSetIsBuiltin(theSet)) {

在两种情况下评估为false，因为两种类型都不是__kCFCharSetClassBuiltin，所以我们跳过该块。

isAnnexInverted = __CFCSetAnnexIsInverted(theSet);

在这两种情况下，_annex指针都为null（请参阅结构末尾的所有零），因此这是false。

此测试将true出于同样的原因：

if ((annexPlane = __CFCSetGetAnnexPlaneCharacterSetNoAlloc(theSet, plane)) == NULL) {

带我们去：

if (!__CFCSetHasNonBMPPlane(theSet) && __CFCSetIsRange(theSet)) {

__CFCSetHasNonBMPPlane宏检查_annex，所以这是假的。当然，表情符号不在BMP平面中，所以对于两个情况来说这实际上似乎是错误的，即使是那些返回正确结果的情况。

__CFCSetIsRange检查我们的类型是否为__kCFCharSetClassRange，这是第一次才真实。所以这是我们的分歧点。第二次调用它会产生不正确的结果，在下一行返回：

return (isAnnexInverted ? true : false);

由于附件为NULL，导致isAnnexInverted为false，因此返回false。

至于如何解决它...好吧，我不能。但现在我们知道它为什么会发生。据我所知，主要的问题是在创建字符集时没有填充_annex字段，并且因为附件似乎用于跟踪非BMP平面中的字符，所以认为它应该存在于两个字符集中。顺便提一下，如果您决定file one（我会将其提交给CoreFoundation，因为那是实际问题所在的位置），此信息可能会对错误报告有所帮助。

检查单个UnicodeScalar的CharacterSet会产生奇怪的行为

1 个答案: