How am I supposed to handle multi-byte katakana, especially given that test cases are called with key="" alphabet=""?

And the fixes have been merged, thanks tor letting me know!

Should all be good now, thanks for the reports!

Here is a fork that addresses the issue; someone still needs to approve it though.

this is just beautiful...

MErged.

Confirmed; I published a fork to fix this.

Thanks for the report! I had based the generator on the C++ translation but I can see now that the alphabet selection is indeed incorrect. I'll see about getting this fixed ASAP.

Update: I published a fork with a fix, it just needs a review to go live.

Alphabets are now generated using sampling without replacement.

??
Whenever encode or decode is called, my code prints in order input string and output string..
I Will check.

but... doesnt explain the output auab^... of the expected value ??

can't verify due to not having solved in c++/not seeing your code
but - this looks to me like you're mixing up different test cases, ie. you're showing the input of one test and the expected output of a different one. be careful with how you print and how you read the output.

See above, Go tests seem to have a problem. I have tested some of them with my Python code and I get the same results as my Go code.

For instance:
Encode Key: OZzhEOAUlkOZDh Alpha: ckclVDAJzUsohOEJZQVDw Text: kZOlaAosDQbUE10FcO

My answer: EocJaDQDzVbVD10FzV Expected answer: EocJaDQDkVbVh10FsV

Haha, I just came here to say something is wrong with the Go tests.

The Go version's random tests include duplicate letters in the alphabet. This makes the results ambiguous, because the resulting character in the alphabet depends on which copy of the input character you started at.

In python, all the random tests were completely made up of capital letters and special characters, while the alphabet was all lower case letters, meaning every single random test just returns itself whether encoding or decoding. Seems a bit pointless!