2016-10-07 4 views
0

У меня есть требование портировать Java-код в объектив. Но я застрял в механизме декодирования, используемом в Java. Из-за неправильного декодирования, используемого в ObjectiveC, мой окончательный вариант не соответствует Java-коду. Ниже приводится код Java, который я застрял:Явное эквивалентное декодирование для ObjectiveC

String s = values.getProperty("s"); 
byte[] salt = Base64.getDecoder().decode(s); 
System.out.println(s); 
System.out.println("Salt DECODED = " + salt); 
System.out.println("Decoded value as string " + new String(salt)); 

Выход выше код следующим образом

's' holds the string value "ZB3NNxAMNB/x6JpAryCd0g==", 
'salt' holds the value "Salt DECODED = [B[email protected]", 
'salt' hold the string value "Decoded value as string d�7" 

Когда же я написал в ObjectiveC, я использовал следующий код

NSString *s = parsedMessageDict[@"s"]; //ZB3NNxAMNB/x6JpAryCd0g== 
NSData *salt = [[NSData alloc] initWithBase64EncodedString:s options:0]; 

Разница заключается в том, что в Java salt задано как byte [] и в объективе C, объявленном как NSData. Это делает какие-то проблемы в будущем. Отныне все данные обрабатываются на основе значения. Поэтому я делаю неправильно здесь сам, безусловно, конечный результат будет неправильным.

В объективе C, следует ли декодировать соль как строку и преобразовать в массив байтов или NSData необходимо преобразовать в массив байтов?

Может ли кто-нибудь дать предложение?

+0

Когда вы печатаете '[B @ ...' это не имеет ничего общего со значениями в байте [], это просто говорит, что у вас есть байт [], и он передавал этот хэш-код, который будет случайным каждый раз, когда вы запустить его. Не было бы разумной причины попытаться воспроизвести это. –

+2

NSData * является * байтовым массивом в ObjC. Кажется, это правильная форма. –

+0

@BenZotto Есть ли какая-либо разница b/w nsdata и массив байтов. –

ответ

0

Экземпляр NSData обертывает буфер байтов и позволяет вам манипулировать им. Это эквивалент ObjC массива байтов Java. Получение байтов из кодированной строки base-64, как вы здесь делаете, является вполне разумным и приводит к экземпляру NSData. (Вторая и третья строки журнала, которые вы распечатываете, не имеют смысла, поэтому вы не должны смотреть на них, чтобы проверить их эквивалентность..)

Поскольку вы используете крипто здесь, это зависит от того, на том, что вы хотите сделать дальше, что определяет, что вы делаете с NSData, которую вы сейчас имеете. Верно, что существует более C-собственное представление пучка байтов (например, unit8_t *), которые потребуются Crypt-API C-style. NSData может дать вам это, если вы вызываете его метод -bytes.

Смежные вопросы