Re: Information Request.

[Shark8 <onewingedshark@gmail.com>]

On Friday, September 27, 2013 2:08:02 PM UTC-6, Austin Obyrne wrote:
> 
> In my crypto scheme I'm planning on every message being prepared as a sring of hex.  I'm arguing that this is now a string of plaintext that can be encrypted by any ASCII based encryption program (albeit hexadecimal digits I plan to treat them as alphanumeric characters in ASCII)- it will decrypyt exactly right I can assure everybody.
> 
> Alternatively I might read in the hexadecimal integer (180B say), convert it decimal and use that as the operand in the computaton of my vector ciphertext. The benefit of doing this is that the ciphertext expansion is kept to a minimum.
> 
> Both of these methods require the natural language plaintext to be submitted as a string of hex. That of course requires an interpreter on site.

Er, it sounds to me as if you don't really know what you're talking about. In general, there are two items in play dealing with text: the encoding, and the character-set. Unicode is a character-set [kinda], encoding for Unicode can be 8-bit/variable-length, 16-bit/variable-length, 32-bit/fixed-length. In any case, the difference between the two is this: one maps some bit-sequence to a value (this is the encoding), the other maps a value to a glyph (this is the character-set).

Example:
Value $4C => '<' EBDIC
Value $4C => 'L' ASCII/Unicode
Hex $e2b4a5 => Value $2D25 (via 8-bit encoding) => GEORGIAN SMALL LETTER HOE [unicode]
Hex $00002d25 => Value $2D25 (via 32-bit encoding) => GEORGIAN SMALL LETTER HOE [unicode]

So there are [at least] two different 'mappings' in place when you're talking about text. (Three if you want to talk about typing, as there's something called keyboard scan-codes involved.)