I'm having this same issue (I think) as I pass all tests and random tests except when there is a backtick. I don't quite understand the problem? Could someone ellaborate?

@samscudder Eh? When encoding, you always just turn each 13 bits of input into two characters - you don't care what symbols they came from, you will always just take the next 13 bits. Now, when decoding, there are illegal patterns that would decode to 14 bits - specifically, D" through "" would become 8192 through 8280, which would require 14 bits to represent in binary. Those will never be produced by a valid encoder, though.

Still confused though - the linked encoder decodes it's own results consistently, so idfk what's going on there. Tried it in my own solution and I get:

string "1234" -> "QztEN" -> "1234"
string "`234" -> "#ztEN" -> "`234"
string "1`34" -> "xAvEN" -> "1`34"
string "12`4" -> "QzpIN" -> "12`4"
string "123`" -> "QztEY" -> "123`"    

That's input -> encoded -> decoded, and as yanykin originally expected, changing one character only affects the 2-3 characters of the encoded value.

so, yeah. Not a clue what's going on with the linked site's encoding/decoding that's making it skew the entire output in those cases.

This is what happens when people implement something from a vague description instead of a detailed spec :P

My solution passed all the tests but failed with a backtick in the only the second position. I've fixed it locally, and updated my solution, but only the first solution is showing up for me.

It is the exception where you can encode 14 bits instead of 13 (For values 8192 - 8280). This throws off the bits of the following characters and will give you the results you found. If you put an '@' or '`' in the second position it will happen.

It was initially intended to use ruby and its undef feature but I've got lazy and busy in university so it all ended up like this.