the same here

for string

'<~mQ?)VbdRNg_W`0n/SEp`4rSS>mC3#W7oLTb*%,X"S7=K\'=o@M&A-AK$$Su`Z;%bko0_p:9P(YMhiX>k\\~>' (two escaped char inside)

expect result:

'î<‚‡Ì¶ÿ\u0018Âé +-gÞv>\u001auùí·üèGS"/\u001c\'n¤œc7$Yüé\u001ad\u0004žQ\u000b3p5\r\nQ\u00129\u00070ùÁ’„0Uâ\f\u0001õ' // randome add \r\n inside

my result, I think correct:

'î<‚‡Ì¶ÿ\u0018Âé +-gÞv>\u001auùí·üèGS\"/\u001c'n¤œc7$Yüé\u001ad\u0004žQ\u000b3p5Q\u00129\u00070ùÁ’„0Uâ\f\u0001õ'

please check random test generator

no problem. and don't feel alone in your troubles – it took me several different implementation approaches before i finally found one that was worth submitting. if you have any more questions, feel free to let me know – i'd be happy to help.

replies to your list:

1. yes, that is correct

2. that was what i initially thought, too. but after finding the bugs in my own code, i realized that the inputs to decode are in the correct ascii85 range

3. You can create a bytestream from a JavaScript string using

    let ord = x => x.charCodeAt(0);
    let bytes = Uint8Array.from('ABCDabcd', ord);
    console.log(bytes);
    [65, 66, 67, 68, 97, 98, 99, 100]
   

4. for the sake of simplicity, i think it's OK that the kata only works on String types (annoying as that might be)

again, i don't think there are character encoding issues here:

• encoding can take any byte and it expects output in the printable, ascii85 range.
• decoding will always give you printable, ascii 85 chars and expects any bytes as output.