PHP로 인코딩 된 일부 utf-8 문자열 base64는 iOS base64 라이브러리를 사용하여 디코딩 할 수 없습니까?
sureone
다음은 서버 측에서 PHP로 인코딩 된 중국어 utf-8 텍스트의 한 조각이지만 iOS로 디코딩하면 null을 반환합니다.
또한 텍스트를 잘 디코딩 할 수있는 이 온라인 도구를 사용해 보았습니다 .
NSData *decodedData = [[NSData alloc] initWithBase64EncodedString:content options:0];
content = [[NSString alloc] initWithData:decodedData encoding:NSUTF8StringEncoding];
5aW96ZuF77yM5ZKx5p2l5LiA5L X55qE77yM5pS56Ieq5Lic5Y2X6KW + / + 5YyX6aOO44CCCuS4juS9oOebuOmAou 8jOWFqOaYr + acuue8mOW3p WQiOOAguWPr + + + Wtpui1t adpeWNtOW / g + aGlOaCtOOAggrmgLvmmK / ovpPkuoborqnlho3ljrvlrabvvIzlrabkuobo
다음은 xcode로이 문제를 디버그하기위한 테스트 코드입니다.
NSString * = @"5aW96ZuF77yM5ZKx5p2l5LiA5L+X55qE77yM5pS56Ieq5Lic5Y2X6KW/5YyX6aOO44CCCuS4juS9oOebuOmAou+8jOWFqOaYr+acuue8mOW3p+WQiOOAguWPr+Wtpui1t+adpeWNtOW/g+aGlOaCtOOAggrmgLvmmK/ovpPkuoborqnlho3ljrvlrabvvIzlrabkuobo";
//
NSData *decodedData = [[NSData alloc] initWithBase64EncodedString: options:0];
NSString *content = [[NSString alloc] initWithData:decodedData encoding:NSUTF8StringEncoding] ;
NSLog(content);
Rob
수정 된 질문에는 다음과 같은 base64 문자열이 있습니다.
5aW96ZuF77yM5ZKx5p2l5LiA5L X55qE77yM5pS56Ieq5Lic5Y2X6KW + / + 5YyX6aOO44CCCuS4juS9oOebuOmAou 8jOWFqOaYr + acuue8mOW3p WQiOOAguWPr + + + Wtpui1t adpeWNtOW / g + aGlOaCtOOAggrmgLvmmK / ovpPkuoborqnlho3ljrvlrabvvIzlrabkuobo
This string has a length that is a multiple of four bytes, so the lack of the =/== terminator at the end is not the problem. And, in fact, initWithBase64EncodedString decodes it successfully:
e5a5bde9 9b85efbc 8ce592b1 e69da5e4 b880e4bf 97e79a84 efbc8ce6 94b9e887 aae4b89c e58d97e8 a5bfe58c 97e9a38e e380820a e4b88ee4 bda0e79b b8e980a2 efbc8ce5 85a8e698 afe69cba e7bc98e5 b7a7e590 88e38082 e58fafe5 ada6e8b5 b7e69da5 e58db4e5 bf83e686 94e682b4 e380820a e680bbe6 98afe8be 93e4ba86 e8aea9e5 868de58e bbe5ada6 efbc8ce5 ada6e4ba 86e8
The issue here is that this appears to not be a valid UTF8 string. In fact, when I run it through the http://base64decode.net site you referenced in your original question, it is also unable to convert it to a UTF8 string (I notice that your screen snapshots are using a different converter web site). When I ran it through another converter, it converted what it could, but then complained about the character following 学了 (which is, coincidentally, the character at which your base64 converter web site stopped, too).
By the way, the UTF8 representation of 了 is e4 ba 86. And you'll see that near the end of the hex representation of your base 64 string, followed by one more byte, e8. The thing is, e8, by itself, is not a valid UTF8 character. It almost looks looks like you took a base64 encoded string and just grabbed the first 200 bytes, disregarding whether that resulted in cutting the UTF8 character off in the middle or not.
The original question featured a base64 string of:
5aW96ZuF77yM5ZKx5p2l5LiA5L+X55qE77yM5pS56Ieq5Lic5Y2X6KW/5YyX6aOO44CCCuS4juS9oOebuOmAou+8jOWFqOaYr+acuue8mOW3p+WQiOOAguWPr+Wtpui1t+adpeWNtOW/g+aGlOaCtOOAggrmgLvmmK/
That is not valid base64. It should be a multiple of four bytes in length, but that is only 163 characters, which is missing a character. Either your server isn't properly terminating the base64 string, or it got cut off for some reason.
For example, if I add a = to get it up to 164 characters, I get a valid base64 string:
5aW96ZuF77yM5ZKx5p2l5LiA5L+X55qE77yM5pS56Ieq5Lic5Y2X6KW/5YyX6aOO44CCCuS4juS9oOebuOmAou+8jOWFqOaYr+acuue8mOW3p+WQiOOAguWPr+Wtpui1t+adpeWNtOW/g+aGlOaCtOOAggrmgLvmmK/=
Adding the = would be the right solution if the server simply neglected to terminate the base64 string properly. Anyway, that can be base64-decoded to:
好雅，咱来一俗的，改自东南西北风。 与你相逢，全是机缘巧合。可学起来却心憔悴。 总是
Is that what you were expecting?
서버에서 base64 루틴을 살펴 봐야할까요? 또는 잘린 경우 수신 방법을 확인하고 서버의 원래 base64 문자열 길이를 여기에있는 것과 비교하십시오.
base64로 인코딩 된 문자열을 추가 =하거나 ==끝에 추가하는 방법에 대한 자세한 내용은 base64 wikipedia 페이지를 참조하세요 .
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
에서 수정
몇 마디 만하겠습니다