[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.
Marking as duplicate of TIMOB-20395.
Closing as duplicate.