[TIMOB-16606] iOS: base64encode does not handle extended ascii characters
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Low |
| Status | Closed |
| Resolution | Duplicate |
| Resolution Date | 2017-08-08T21:13:45.000+0000 |
| Affected Version/s | Release 3.2.1 |
| Fix Version/s | n/a |
| Components | iOS |
| Labels | defect, ios |
| Reporter | dennis booth |
| Assignee | Eric Merriman |
| Created | 2014-03-08T19:01:09.000+0000 |
| Updated | 2017-08-15T20:14:15.000+0000 |
Description
UPDATE: The strings I was using had non-breaking spaces in them (returned form the OS). Please read comments for more info.
When a string that contains parentheses and spaces is base64 encoded then decoded into a blob, blob.text (and toString()) returns an invalid, truncated, string.
Bug appears to be is in base64encode when creating blob. If you paste the result encoded string into a decoder tool, you see the truncated string.
mimetype of the resultant blob is 'application/octet-stream'.
Tested on iOS and Android. Bug appears only to exist on iOS.
Code to reproduce:
var example = "(602) 555-4848,(480) 555-5857,(480) 555-4849,(623) 555-7777,(303) 555-3030,(480) 555-1235,(480) 555-9998,(480) 555-2222";
var encoded = Ti.Utils.base64encode(example);
var decoded = Ti.Utils.base64decode(encoded);
Ti.API.debug('ORIGINAL :',example);
Ti.API.debug('DECODED :',decoded.text);
Ti.API.debug('ENCODED :',encoded.text);
Ti.API.debug('CHECKS :',decoded.length, decoded.text.length, decoded.text === json);
Output on iOS Simulator:
[DEBUG] : ORIGINAL : (602) 555-4848,(480) 555-5857,(480) 555-4849,(623) 555-7777,(303) 555-3030,(480) 555-1235,(480) 555-9998,(480) 555-2222
[DEBUG] : DECODED : (602) 555-4848,(480) 555-5857,(480) 555-4849,(623) 555-7777,(303) 555-3030,(480) 555-1235,(480) 555-9998,(480) 555-22
[DEBUG] : ENCODED : KDYwMinCoDU1NS00ODQ4LCg0ODApwqA1NTUtNTg1NywoNDgwKSA1NTUtNDg0OSwoNjIzKSA1
[DEBUG] : NTUtNzc3NywoMzAzKSA1NTUtMzAzMCwoNDgwKSA1NTUtMTIzNSwoNDgwKSA1NTUtOTk5OCwo
[DEBUG] : NDgwKSA1NTUtMjI=
[DEBUG] : CHECKS : 119 117 0
(Updated to imply that the encode is the culprit after checking the encoded string in an external tool). Curious: why does the blob.length report the correct length even though .text is in fact truncated?
I just found out that on iOS the phone results from a device contacts query returns char code 160, non breaking spaces, between terms. Therefore, would this really be considered a bug or are base64 utils not intended to handle ascii codes >127? For now, I'm just converting them to code 32.
Moving this ticket to engineering as I can reproduce the issue with a modified test case that uses characters with ascii code 162. Documentation does not specify the supported character list so it may either be a product bug or doc improvement.
var example = "¡¡¡¡¡¡¡¡¡¡"; var encoded = Ti.Utils.base64encode(example); var decoded = Ti.Utils.base64decode(encoded); Ti.API.debug('ORIGINAL :',example); Ti.API.debug('DECODED :',decoded.text); Ti.API.debug('ENCODED :',encoded.text); Ti.API.debug('CHECKS :',decoded.length, decoded.text.length, decoded.text === example);Marking as duplicate of TIMOB-20395.
Closing as duplicate.