Rot8000
rot8000.com
rot8000.com
1. This algorithm will break if the number of valid characters in the BMP becomes odd.
EDIT: As user platforms pointed out, there is an unit test for this.
2. There is an overflow in line 39 because of the check i <= BMP_SIZE in line 37.
3. The web server at rot8000.com exposes at least some errors with stack traces, try rotating the string <script>.
4. In line 42 you are performing a linear search for every character you transform, that is very inefficient, especially with characters at the end of the BMP. At least use a hash map or even better just use an array mapping the input code point directly to the output code point.
5. rot8000.com does at the very least allow rather long inputs which paired with the inefficiency of the linear search makes a DoS attack pretty easy. I tried a 10,000 word lorem ipsum, it was not rejected and the request took a minute to complete.
public static String Rotate(String input)
{
var result = new Char[input.Length];
for (var index = 0; index < input.Length; index++)
{
result[index] = Rotator.map[input[index]];
}
return new String(result);
}quick googling seems to suggest simple bitshifting could be possible..
It comes with presets for various different areas of Unicode, and some example text, although the intended use case was very different, I looked at it from a steganography perspective rather than an honours-system obfuscation perspective.
https://incoherency.co.uk/mojibake/
I initially thought it would be able to decode the rot8000 output without any modification but I think the utf-8 escaping that my tool expects (from its own output) gets confused by the output from rot8000.
https://github.com/rottytooth/rot8000/blob/master/Rottytooth...
More critically, if the # of valid chars changes, previously rot-8000'd text will no longer be reversible through the tool
Also a crude "modern Bacon cipher" using Punycode characters as the B's and ASCII-range characters as the A's.
Most emojis seem to be above the first 16 bits. [1] But there are a number of emojis in the first 16 bits, like the "frowning face" emoji at U+2639 -- it rotates just fine -- plus others in the first 16 bits.
(TIL you can't paste emojis into HN comment threads. Probably all for the best.)
It got in the way of me explaining the Rebus principle used in Egyptian hieroglyphs a little while ago.
Then again, the topic was phalluses in Unicode (which do display!), so maybe you're right.
I'm gonna make a HN where you can only speak in Emoji!
Sorta unrelated, does anyone remember the social network where you could only write in Emoji? http://emoj.li/
https://unicode.org/emoji/charts/full-emoji-list.html
https://unicode.org/emoji/charts/full-emoji-modifiers.html
You might need to split the text over multiple comments. Don’t remember whether or not there is a limit to the length a comment can have. Probably there is.
I can post, for example: ↙️ ↩️ ⌚ ⌛ ⌨ ⏏ ⏩ ⏰ ️⏱ ⏲ ⏳ ️◾
edit: scratch that, they get stripped out.
It's essentially a Unicode version of the old "Rot 13" cypher.
In Rot 13, you translate each letter 13 places down (as if on a code wheel), such that 'A' becomes 'N', 'B' becomes 'O', wrapping such that 'Z' becomes 'M', and so on.
This version, instead of using the simple 'A=1...Z=26' number space, uses the Unicode range and rotates by 32,768 (0x8000).
"rot13 is reversible" -> "ebg13 vf erirefvoyr" -> "rot13 is reversible".
"rot8000 is also reversible" -> "类籸籽籁簹簹簹 籲籼 籪籵籼籸 类籮籿籮类籼籲籫籵籮" -> "rot8000 is also reversible"
Rot13 is English-alphabet only so it skips numbers, while rot8000 doesn't have this limitation because it uses the larger unicode set.
We could go further, straight to Base8000!
It's actually pretty useful for compressing data in Unicode-aware environments, like Twitter. Which makes me wonder if Unicode support is universal enough now that an encoding like this could replace MIME/base64 in email.
* The input bits are packed in the reverse order (e.g. 1A 2B 3C is packed as 0x3C2B1A) unlike most other binary-to-text encodings. The last bits are padded with preceding zeroes.
* A pair of basE91 alphabets encode a number 0 through 8280. The first alphabet is least significant: `AB` encodes 91 and not 1.
* 91^2 = 8281 > 2^13 = 8192, so groups of 13 bits are read and encoded as two basE91 alphabets from the least significant to the most significant. But it's not always the case. Occasionally a group of lowermost 14 bits will be read if the bits are less than 91^2. As a result, the first 8281 - 8192 = 89 values (0..88) and the last 89 values (8192..8280) actually encode 14 bits, and it includes all-zero bits. Its average overhead is therefore 22.93% (16 / lg 8281 - 1) and can reach 14.29% (16 / 14 - 1) when all bits are zero.
It reminds me of Ascii85 [1] which had a shorthand for all-zero groups and all-space groups, but this one is more general. Speaking of generality, probably a binary-to-text encoding with arithmetic coding is now viable?
I feel the same way about https://www.base64decode.org/ . By default, everything gets translated server-side. I wonder how many people use this site on a regular basis for translating secrets. I'd bet my life that the number is greater than zero.