Fixed base64 html output for non Latin1 chars

[magnitudoOrg]

Fixed btoa() error for Unicode chars like "\uD83D\uDD25": "Uncaught InvalidCharacterError: Failed to execute 'btoa' on 'Window': The string to be encoded contains characters outside of the Latin1 range."

quick test inverted function: b64 = btoa(unescape(encodeURIComponent(outputCode[1]))); decodeURIComponent(escape(atob(b64))) == outputCode[1]; // must be the same as original text

[Siorki]

Unfortunately, the crash happens earlier, in RegPack.getByteLength(), invoked while building the dictionary in RegPack.findRedundancies():172. Addressing the issue upon displaying the output (packed) string - and only for the base64 encoding btw - comes too late.

As discussed in #50, I'd rather fix that by making sure no malformed string is produced at first.

[magnitudoOrg]

Maybe a misunderstanding: this issue (rel. to #52) is independent from #50 issue, although it looks similar

1) I tested it on http://siorki.github.io/regPack.html and on a local copy -> insert '☠' ("\u2620", its just a simple 2 B Unicode char, not complex 4 B like "\uD83D\uDD25") -> check the base64 output in the checkbox -> crashes with InvalidCharacterError (not the URIError as in #50)

2) Edited that one line in regPack.html (see commit) btoa(...) into btoa(unescape(encodeURIComponent(outputCode[index]))) -> test 1) again -> it won't crash any more :)

3) Maybe unit tests should be written (TODO) -> idea: test with inverted function for several input strings, sth. like: b64 = btoa(unescape(encodeURIComponent(outputCode[1]))); decodeURIComponent(escape(atob(b64))) == outputCode[1]; // must be the same as original text

[Siorki]

Oops sorry, I read too fast and confused both issues.

I'll probably move the code from the GUI towards one of the classes (might be time to create a string helper) to run node.js-based unit tests on it.

[magnitudoOrg]

Okay, thats a good idea to move the code for better testability. :)

[Siorki]

Moved code to StringHelper and added unit tests.