Чтение NSNumber из NSData

Question

Я довольно новичок в Objective-C (и сам C) и должен потреблять NSData с выхода HTTP. Я никогда не работал с байтовыми массивами или не беспокоился о проблемах с маленькими/большими концами, и немного пытался написать следующий метод для чтения NSNumber с указанной длиной от NSData.

- (NSNumber *)readNumberWithLength:(NSUInteger)length 
{ 
    Byte k[length]; 
    [data getBytes:k range:NSMakeRange(offset, length)]; // big endian byte array representing a number 
    offset += length; 

    NSNumber *number; 
    if (length==4) { 
     number = [NSNumber numberWithUnsignedInt:CFSwapInt32BigToHost(*(uint32_t *)k)]; 
    } else if (length==2) { 
     number = [NSNumber numberWithUnsignedShort:CFSwapInt16BigToHost(*(uint16_t *)k)]; 
    } else if (length==1) { 
     number = [NSNumber numberWithUnsignedChar:*(uint8_t *)k]; 
    } else if (length==8) { 
     number = [NSNumber numberWithUnsignedLongLong:CFSwapInt64BigToHost(*(uint64_t *)k)]; 
    } else { 
     number = [NSNumber numberWithInt:0]; 
    } 

    return number; 
} 

NSData *data меня и NSUInteger offset объявлены как переменные экземпляра.

Правильно ли этот код? О чем я должен беспокоиться? Я еще не тестировал его на самом устройстве (только на симуляторе), и, похоже, он отлично работает для меня. Есть ли у вас какие-либо комментарии по этому поводу?

Спасибо!

Answer 1

Код выглядит более или менее верным.

Кажется, что это трудный путь.

Я был бы удивлен - не полностью потрясен, но удивлен, что данные, возвращаемые с HTTP-сервера, действительно являются просто сырыми байтами. Было бы крайне редко, что это так, и в случае, если это так, дизайн сервера почти наверняка ошибочен. (Есть, конечно, случаи, когда ответ двоично-HTTP-ответа - правильный ответ, но он очень редок).

Если вы не говорите о 100 тысячах значений в данных, накладные расходы, связанные с HTTP, почти наверняка перевесят любые выгоды от перехода на двоичный код. Разбор известных числовых значений из строки не равен , что обременительно, если вы действительно не делаете этого постоянно (что сделало бы использование HTTP не особенно привлекательным в первую очередь).

---

Дизайн сервера: достаточно честный. Еще одна важная причина для этого - это потому, что вы не можете изменить эту часть головоломки.

Я бы лично реализовать код более оборонительно:

• проверить, что локальные размеры данных имеют ожидаемых размеров по сравнению с удаленных/сетевых размеров, чтобы избежать неприятных сюрпризов (это может быть утверждения об инициализации или в некоторый код отладки - я предпочитаю быть защищенным в таких ситуациях).

• используйте оператор case вместо последовательности if/else if/else if/else. Полностью эстетическое решение, но оно будет способствовать ...

• ... имеет значение length, являющееся неожиданным значением путем ведения журнала, даже если он находится только в режиме отладки. Я думаю, что неожиданный размер ценности потенциально очень плохо для общей правильности?