![[UtiliKey window]](UtiliKey.png)
UtiliKey is a program designed simply to take a given bit of text and, essentially, play with it in various ways. It has very little depth or complication; however, it could have any number of uses.
UtiliKey requires .Net Framework 4.0 (it uses the full framework, rather than the Client framework, due to using the HttpUtility class for URL-encoding and HTML-entity-encoding), and Windows 7, Windows Vista SP1 or later, or Windows XP SP3. It may also function on Macintosh/Linux using Mono; this is currently largely untested, although MoMA showed no problems. UtiliKey.exe may be placed anywhere, with or without any of the accompanying files, and should still function properly.
The process is simple: type or copy a bit of text into the upper text-box, and select the form of encoding/transformation in the drop-down list. Click on the "Encode" button to encode or transform the text; the encoded version will appear in the lower text-box. If applicable, you may type or copy previously-encoded text into the text-box, and click "Decode" to reverse the process. If you are including unicode-characters, you'll probably need to check the "Unicode" box if applicable, so that they don't get turned into question marks. (If the "Unicode" check-box is disabled, though, it will work fine regardless.)
ROT13 is a simple Caesar cipher: the first half of the alphabet is mutually replaced by the other half of the alphabet — in other words, you "rotate" the alphabet 13 steps. It's for something you want hidden, but not hidden too well; it's been called the equivalent of "magazines which print the puzzle-solutions upside-down." You can get lotsa geek cred for being able to read it regardless. It is also what's known as a "Kama Sutra cypher," because the process for encoding it is the same as decoding it.
ROT13 ignores (most) non-letter characters, and simply includes them intact.
Input:
Output:
Probably one of the most famous codes out there. This version renders dots as periods and dashes as underscores. Letters are separated by spaces, and words are separated by slashes. All other non-alphanumeric characters are preserved.
Note: because Morse Code does not differentiate between uppercase and lowercase letters, all letters are lowercase when you decode them.
Input:
Output:
Designed to encode strings such that it is safe to enclude them in a web-URL; certain characters are considered improper to put in a URL, and might mess things up if you don't deal with them. The normal version only encodes non-URL safe characters; path-safe includes any character, including those which might be part of a URL, in case you might want to use an entire string in a URL's arguments; and the every character version does what it says it does.
Input:
Normal Output:
Path-Safe Output:
Every-Character Output:
Converts a set of characters so that you can display them literally on a web page, without having to worry about the web browser getting confused by ampersands or < and > tags.
Note: the program can decode unconventional entities such as "♥" for ♥, but when encoding, it will simply turn it into the numerical unicode equivalent.
Input:
Output:
It's like this ...
Every character in any ASCII/ANSI/Unicode/whatever system is made out of one or more bytes (that is, eight bits). A byte can count from 0 to 255 for a total of 256 different combinations of bits. Base64 divides these strings into groups of six bits, which go from 0 to 63 (for a total of 64); each of those 64 possibilities has its own character assigned to it, and it spits out the (visibly longer) string. If the number of bytes doesn't divide evenly into six bits, the string is padded with extra = signs.
Input:
Output Without Unicode: (when decoded, the "♥" and the "⑨" will have turned into question marks)
Output With Unicode:
According to Wikipedia, the MD5 Message-Digest Algorithm is a widely used cryptographic hash function that produces a 128-bit (16-byte) hash value. It isn't the best thing to use for security purposes, but it's still useful in a number of ways. Note that it is not possible to get the original data back once it has been processed into a hash; all you can do is take other bits of data, process that, and compare it to the original hash.
Input:
Output:
In computing involving the CJK (Chinese, Japanese, and Korean) languages, characters are classified as either "fullwidth" or "halfwidth"; the name comes from the fact that, in fixed-with fonts, a halfwidth character is half the width of a fullwidth character.
Now, ordinary letters of the English alphabet are technically halfwidth characters, whereas all CJK characters are fullwidth. However, in the event that English letters are required to be the same width as CJK characters (or vice versa, in some cases), there is a set of Unicode characters consisting of fullwidth versions of English characters and halfwidth versions of a small subset of CJK characters. "Encode" will convert all possible letters (English text, halfwidth CJK characters) into fullwidth characters, and "Decode" will convert all possible letters (fullwidth text, Japanese Katakana letters, etc) into halfwidth characters.
Input:
Output:
This encoding system simply takes every character, divides it into the individual bytes that make up each character, and presents the numeric equvalent in either binary ("L" = "01001100"), octal (base 8 or 0-7; "L" = "114"), decimal ("L" = "076"), or hexadecimal (base 16, or 0-9 A-F; "L" = "4c").
The different versions have different effects. In the normal versions, it is given simply as a stream of bytes; you'll need to turn on Unicode encoding in order for Unicode characters to work properly, and all non-unicode characters will have trailing null-bytes. In "full-byte" mode, it is similar to how I'm pretty sure C# strings work: each individual character is treated separately, and if it's a Unicode character, it presented as the full length of the byte, i.e. "L♥" becomes "4c / 2665" instead of "4c 00 / 65 26" or "4c / 3f" (3f being the hex character for "?").
Input:
Hexadecimal Output Without Unicode: (when decoded, the "♥" and the "⑨" will have turned into question marks)
Hexadecimal Output With Unicode:
Hexadecimal Full-Byte Output:
1.0.0.0: August 3, 2011
1.1.0.0: March 21, 2012
1.2.0.0: October 27, 2012
Plans for the future: Add an options menu with settings like fonts, size, what characters to use for Morse code, other options like saving text/loading from files, and so forth ...
UtiliKey is released under the BSD License:
Copyright © 2011-2012 by No Worry NeverFear. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY NO WORRY NEVERFEAR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL NO WORRY NEVERFEAR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.