Turns out I was barking up the wrong tree. My FoxPro (Craig Boyd) and .NET (Bouncy Castle) Blowfish encryption routines are returning encrypted strings of different lengths, and I thought this was the cause. Encoding.GetBytes(string) is being used to convert the string to byte[], and it successfully converted /n to a single CHR(10) byte. I'm not sure why the different lengths. Encrypting a 16-byte string in FoxPro returns a 16-byte encrypted string, in .NET it returns 24 bytes. Probably just an implementation difference. In my case, I was able to workaround by reducing my string to 15 bytes which gets the same result from Fox and .NET. Thanks for the help.

>A string is composed of characters, think of it as a character array. Internally a char is represented in Unicode (UTF-16) and occupies 2 bytes
>
>C# is not converting it to '\n', it just displays it as '\n'
>
>Also, bear in mind that in C#, a character is kept in UTF-16 format http://en.wikipedia.org/wiki/UTF-16/UCS-2
>
>If the chars are later stored to say a text file, they are converted to a sequence of bytes using an Encodig http://msdn.microsoft.com/en-us/library/system.text.encoding.aspx
>
>A char can occupy 1, 2, 3 or 4 bytes depending on (1) The encoding and (2) the char itself
>
>Encrypting and Decrypting are never done on chars, but always on bytes
>
>Consider using bytes if possible
>
>

>

>>Here's my scenario: I am storing a small number as a single character in a string. If that number happens to be 10, C# is converting it to "\n". I imagine I will run into the problem with other escape codes as well. I really need CHR(10) to be stored in the string, not "\n". I've tried Convert.ToChar(myint), (char)myint, and even went so far as to use VisualBasic.Strings.Chr(), but it always comes back as "\n" in the string. The string is later encrypted, and that's where it is really messing things up. Is there anyway to "escape the escape" and prevent this from happening?
>>
>>Thanks.