![[UtiliKey window]](Window1.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 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:
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 effect. In the normal versions, it is given simply as a stream of bytes; you'll need to turn on in order for Unicode characters to work properly, in which case 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
UtiliKey is released under a BSD License:
Copyright © 2011 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.