02-08-2014 08:03 AM
Calling toUff8 (this message didn't include attachment but it doesn't matter):
02-08-2014 09:51 AM - edited 02-08-2014 10:12 AM
The function fromHex that you're saying has a bug in it - only converts hexadecimal to bytes. Again, hexadecimal is 0-9,a-f, anything else is not valid hex.
Keys and IVs in the sample are using hex to make displaying and saving trivial. Base64 could have just as easilly been used.
There is nothing wrong with using the faster 8bit conversion when the function's behaviour only makes sense with hex.
However - if your local platform doesn't use latin1 as the local8 bit encoding, then toAscii or toLatin would be correct - but there's no reason to use a multibyte conversion function. What are your regional settings? What is your local8bit encoding of the letter 'f' ? However - the fromHex and nibble functions record a failure that the input was not hex and a toasts shows you that... The encryption/decryption does not proceed.
The é in Montréal is UTF-8 encoded - it's there only to demonstrate that the sample is UTF-8 correct. Below is a screenshot of Japanese converted correctly. The code that works with plain and decrypted text is using utf8 conversions.
02-09-2014 04:45 AM - edited 02-09-2014 04:47 AM
I will re-check.
In my case my message is encrypted, packed into json file, emailed, read on the other device, json is parsed and finally the cipher is decrypted.
02-09-2014 05:35 AM
I can confirm that sample runs fine with Slovenian special characters.
It is email's blame that characters 0-9+a-f has been translated into different encoding. But if I use toUtf8 instead of toLocal8Bit, the message is read OK.