Yeah, in a bijective RLE, one needs to take into account that, say, A2A2 can't mean the same as A4. However, since you also want to be able to represent runs l

Yeah, in a bijective RLE, one needs to take into account that, say, A2A2 can't mean the same as A4. However, since you also want to be able to represent runs longer than 255 (if you're doing it on byte level), you can solve both problems. If you encounter repeated runs of the same literal, just combine them into a bigger number. So A2A2 should be read as "A times (0b00000010 00000010)" whereas A4 should be read as "A times (0b00000100)." There are some subtleties still to make it a bijective code, related to end handling and how to represent variable length numbers uniquely, but it's perfectly possible, and once you get it right it isn't really larger than "regular" RLE. It's an interesting challenge to write bijective encodings. I feel it's a bit like writing quines, you have to keep in mind a thing you usually don't. For quines, "what this does to the text you need to output", for bijective encodings, "what this does for the inverse function". Not saying you should give it as an interview question, though!