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 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.
One nice property of rot13 is it reverses itself; rot13(rot13(X)) = X. At least, for basic ASCII alphabet. Your UTF-8 encoding step makes that impossible. I wonder if there's a sensible Unicode-friendly algorithm that has that rot13 property.
This is a very bad idea because it's going to rotate ordinary characters to code points where Unicode normalization has an effect, including combining characters, whitespace, control characters... After normalization, rotating back will produce garbage.
The website explains the primary actual use case for ROT-style transforms:
> It is used to enclose the text in a sealed wrapper that the reader must choose to open - e.g. for posting things that might offend some readers, or spoilers.
AFAIK, this has been a common use of ROT13 since the 1980s. It also preserves substring search and message length (unlike BaseN encodings), which are occasionally useful properties.
Ah ok, I was aware of that usage back in those days (fidonet), but I didn't realise it was still used as such. I haven't seen that function in any modern app, and most have their own spoiler tag implementation (like black on black so you only see the content after highlighting)
In cryptography circles it seems to be kind of a running joke ("just use ROT13 encryption and you'll be set!" is something I've seen several times) ;) I know it was never intended to be secure.
But it makes sense then.
Of course if you work with ROT13 a lot, you will probably gain the ability to read it just by viewing the ROT'd code, defeating its purpose :) The structure of words also gives away a lot, since it doesn't affect spaces, capitalisation or punctuation. I still don't think it's very good at this usecase either.
Rot13 hasn't been a serious encoding scheme for security since the Roman Empire. It's all about making an easy to encode/decode wrapper for hiding spoilers and the like. Back in the olden days, newsreaders had a shortcut key to run rot13 on the text of a post so you could unveil the spoiler or puzzle solution.
I wonder if it is possible to generate a ROT8000 quine, that is a phrase like "hello world" which yields a semantically matching phrase in some other language?
I remember seeing this the last time it was posted on HN [0] in 2018. The About page seems to be a bit outdated since it actually skips a lot more characters than the 32 mentioned.
Running this on CJK text is an interesting exercise.
Nice idea. I often use base64 for this, since it's somewhat recognizable and there are tons of decoding tools available.
Base64 does lengthen the text by a third, which may or may not be a problem. On the other hand, it doesn't need special handling of control characters, and manages to hide word lengths well.
Many years ago I was involved in finding and fixing a messaging bug that only appeared when the base64 encoded payload had a length that was a multiple of 87 bytes (it might have been some other value - it was 15+ years ago).
I am just getting boxes with hex codes in them if I type ascii letters so that is not so very nice. Even if you have all of the required fonts I am not sure it is that great to get characters from a completely foreign language. Also, I suppose, one could end up with surrogate code points which do not have a character representation. To summarize: I think this sounded like more fun in theory than it turns out to be in practice.
Real world use case: geocaching.com uses it to hide hints, so you don't read and spoil yourself by accident. It's pretty much accepted and adopted by the users. I also would ban words like "dumb" or, for another example "easy" in IT and CS contexts.
In this case, it would be very unlikely to actually happen, for a few reasons.
Almost all combining rules (including skin tone modifiers) require a zero-width joiner character between the person emoji and the modifier emoji. So really it's frowning face + ZWJ + brown texture = brown frowning face. (Although technically I don't think frowning face can be modified.) Also, there are relatively few ZWJ combinations.
Technically, there are some older combination emojis that predate ZWJ, mainly the flags, which are composed of two single-letter emojis, e.g. regional-indicator-U + regional-indicator-S = United States flag. So I guess it might be possible to get a couple of those.
And in any case, I think this page assumes that you're staying within the bounds of the basic multilingual plane (it mentions a self-inverting transform would be ROT32768), which doesn't include emojis or skin tone modifiers.
> Almost all combining rules (including skin tone modifiers) require a zero-width joiner character
No, the skin tone modifiers apply directly to eligible person emojis; no ZWJ is involved. (Unless other modifiers that require ZWJ are also present, such as the gender signs.)
True, but some apps don't have the ability to show all these variations and may leave them out (simplify to just a face icon) when copying/pasting. Unicode interpretation is a really complex bundle of quirks these days so I'm pretty sure things will start going wrong.
Hi, I created rot8000 for The Wrong, an online biennial of digital art -- specifically for the pl41nt3xt pavillion, which included text-only works. The pavillion was taken down when the biennial ended, and looks like that link is no longer valid
What is the name of the non-reversible encoding scheme that translates "internationalization" to "i18n", "localization" to "l10n", "kubernetes" to "k8s", and other abbreviations like "f2k" "y1u"?
> While rot13 is the self-inverse for a 26-character system, and rot47 for ANSI, the Basic Multilingual Plane of Unicode requires rot32768 (or 8000 in hex) for a reciprical cypher
Not all emoji is in the BMP, at least some are in the Supplementary Multilingual Plane.
It's weird to me that if you're gonna do this dumb "rot13 but for Unicode", you'd only do it for the BMP, and not ALL of Unicode.
The details you might be missing is that some emoji existed in Unicode before color graphic "emoji" was actually a thing. The stars (and hearts) are examples of ones which used to be just a basic shape in the font but now are commonly full color graphical "images".
There's a couple of browser plugins that do this, with a password, so long as someone else knows the password it will decode. I'm not near my machine that has it, but I know it does Korean, japanese, and Chinese characters - you choose which set you want. And it doesn't back-translate to anything useful, it's just encoding.
I call it "Mojibake Steganography": 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.