Ошибка преобразования NSString в NSDictionary

У меня есть строка с сервера, и когда я пытаюсь преобразовать ее в NSDictionary, я получаю "nil". Когда я пытаюсь написать то же самое NSString сам - все в порядке!

Я получаю строку, закодированную сервером, затем использую «AES256DecryptWithKey» из NSString+AESCrypt.h для расшифровки и получаю NSString, эту строку я конвертирую в NSData, а затем пытаюсь получить NSDictionary.

NSString *str = @"{\"error\":{\"password\":[\"Error wrong!\"]}}"; //string written by myself

NSData *jsonData = [str dataUsingEncoding:NSUTF8StringEncoding];
    NSDictionary *json = [NSJSONSerialization JSONObjectWithData:jsonData
                                                         options:kNilOptions
                                                           error:&error];

Этот код работает, но затем я получаю эту строку с сервера - нет (

Журнал NSData (сообщение от сервера) - <7b226572 726f7222 3a7b2270 61737377 6f726422 3a5b22d0 9dd0b5d0 bfd180d0 b0d0b2d0 b8d0bbd1 8cd0bdd1 8bd0b920 656d6169 6c20d0b8 d0bbd0b8 20d0bfd0 b0d180d0 bed0bbd1 8c225d7d 7d000000>

Журнал NSData (моя строка) - <7b226572 726f7222 3a7b2270 61737377 6f726422 3a5b22d0 9dd0b5d0 bfd180d0 b0d0b2d0 b8d0bbd1 8cd0bdd1 8bd0b920 656d6169 6c20d0b8 d0bbd0b8 20d0bfd0 b0d180d0 bed0bbd1 8c225d7d 7d>

Если я ввожу строку NSLog с сервера, то это - {"error":{"password":["Ошибка ошибочна!"]}} , строка без "\"

Затем я "po &error.localizedDescription" - ошибка: адрес запрошенного выражения свойства ошибка: 1 ошибка синтаксического анализа выражения

Затем я «po error.localizedDescription» — печать описания ошибки: Error Domain = NSCocoaErrorDomain Code = 3840 «Операция не может быть завершена. (Ошибка Cocoa 3840.)» (Мусор в конце.) UserInfo = 0x7f9940497550 {NSDebugDescription = Мусор в конце.}

Что это может быть??


ios json nsjsonserialization nsdictionary
person Nubaslon    schedule 25.06.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

В сообщении об ошибке говорится:

Мусор в конце.

Итак, сравнивая ваши данные и данные с сервера, мы видим:

Test string data:
<7b226572 726f7222 3a7b2270 61737377
 6f726422 3a5b22d0 9dd0b5d0 bfd180d0
 b0d0b2d0 b8d0bbd1 8cd0bdd1 8bd0b920
 656d6169 6c20d0b8 d0bbd0b8 20d0bfd0
 b0d180d0 bed0bbd1 8c225d7d 7d>

Server data:
<7b226572 726f7222 3a7b2270 61737377
 6f726422 3a5b22d0 9dd0b5d0 bfd180d0
 b0d0b2d0 b8d0bbd1 8cd0bdd1 8bd0b920
 656d6169 6c20d0b8 d0bbd0b8 20d0bfd0
 b0d180d0 bed0bbd1 8c225d7d 7d000000>

Декодированные данные длиннее на 3 байта. Возможно, он дополняется перед шифрованием или в результате вашего дешифрования из-за какого-то параметра заполнения. В качестве обходного пути вы можете удалить случайный 000000.

person Mats    schedule 25.06.2015
comment
Как я могу удалить этот 000000? - person Nubaslon; 25.06.2015
comment
Лучше не вставляйте его в первую очередь. :) - person Eiko; 25.06.2015
comment
Да, пока кто-нибудь не исправит код с лишними нуль-терминаторами. - person Eiko; 25.06.2015
comment
Если на стороне сервера используется mcrypt, не беспокойтесь, исправления не будет, бозо, создавшие mcrypt, решили использовать нулевое заполнение, которое является нестандартным, и не поддерживать заполнение PKCS#7. Разработчики даже отмечают, что заполнение не удастся, если данные имеют завершающий байт 0x00 - nioce touch. Правильным ответом на этот вопрос является добавление заполнения PKCS#7 перед вызовом функции шифрования и замена заполнения PKCS#7 на 0x00 байтов перед вызовом функции расшифровки шифрования. - person zaph; 25.06.2015