Interesting, I have made a similar project, except instead of rotN, it encodes the input as UTF-8, and then shifts up the codepoints to display each byte as a d

Interesting, I have made a similar project, except instead of rotN, it encodes the input as UTF-8, and then shifts up the codepoints to display each byte as a different character to what it would normally be. The invariant is that `byte & 0xff` is the real byte value. I call it "Mojibake Steganography": https://incoherency.co.uk/mojibake/ https://incoherency.co.uk/mojibake/ I think in principle (judging by the description of rot8000), my tool should be able to decode rot8000 messages natively, but it doesn't seem to work on the example given here. From looking directly at the codepoints given, I think the example is wrong. It starts: u+7c5d u+7c71 u+7c6e - which works out to "]qn" instead of "The", unless I am misunderstanding something. And in fact that looks definitely wrong if we're expecting ASCII output because they're all more than 127 away from 0x8000, no matter how it works. The rot8000 page says: > It also bypasses 32 control characters, technically making it rotFFE0, sometimes with an additional offset. I definitely don't understand how this is meant to work. Why does skipping 32 control characters turn it from rot8000 into rotFFE0? Should that say 7FE0? I still don't see how ASCII is coming out as 7Cxx. Taking `char - 0x7c09` gets the expected ASCII output.