Socket Encoding and Decoding using Ascii Encoding

Socket Encoding and Decoding using Ascii Encoding

• Fang Liu

  Followup: I tried to go back from a String to Byte() with String.ToChars() and the AscW function. That's a no-go. Specifically, bytes in the range &H80..&H9F convert back to a Unicode value > &HFF. &HFF converts back to 0. You'd better keep your data in a Byte()...
  
  
  
  

• JoelT3

  SJ,

  Now there seems to be light at end of the tunnel. What you have said makes sense to me now. Have managed to get the documents relating to the interface and I am sure I will make some headway now.

  Thanks for all the help. I will let you know when my application is singing and dancing

  Thanks again.

  
  
  

• Sun Foster

  In the code try changing the Chr to CType(value, char)
  You should also make sure that if you go back to binary you don't use any Encoding methods. Namely use the same method except instead of value, char in your ctype you would go value, byte. Also how are you verifying that it is not converting propertly
  
  My code is in C# and it uses Casts and not Chr which may be why there is still encoding loss.
  
  

• dhooger

  If you are receiving binary data, Encoding.ASCII is not a good one to use. It only converts byte values 0..127 and replaces any byte with the high bit set (128..255) with a ' '. Try to keep the received data in a Byte array rather than converting it to a string. If you really, really want a string, try Encoding.Default()
  
  
  

• Beeche

  MarcD,

  Thanks for the help man. What makes me sure that I am loosing data is that I have put a packet sniffer in between my application and the source. I must admit I have taken a bit of a beating on this one. Will try out what you suggested and see if this works.

  Many thanks

  TCS

  
  
  

• Szmooz

  Hi MarcD,

  is it possible you could share with me some of you code that take character by character. I have tried that as well but cannot convert it back to byte properly.

  
  
  

• sroche

  When it comes down to socket protocols, it's a case of documentation - whoever transmits the data needs to give the persons who are responsible for decoding it a piece of paper with the protocol on it. If you don't have that, then you are stabbing in the dark .

  The protocol is the key, though: most protocols are:

  1. Fixed length (always a certain number of bytes)

  2. Have a fixed length header containing the total message length (typically in bytes)

  3. Have a Header 'marker' and a tail 'marker', marking the bounds of the message

  You have to have one of these methods, or else you have no idea where a message starts or ends.

  There is a two step process to 'decode' the received bytes:

  a. Reliably recieve the bytes.

  b. Interpret the bytes.

  It's a good idea to separate out these into different routines: generally, you would receive your bytes into your own internal buffer. Then you would work on that buffer to interpret them. Once again, though, to do the latter the protocol is required.

  If you know where the string starts and ends, you should be able to decode it correctly: I would expect that the 'transmitter' is using an ANSI encoding scheme (1 byte per character), or UTF-8. The latter will have a variable byte length for a fixed number of characters, though, which may be messing you up.

  Experiment: do you have access to the transmitter can you transmit known strings

  Protocols can be anything - there's no 'one stop shop' for protocols (most people make it up as they go along). It may be a publically accesable protocol - ask the person who supplies the transmitter. Or, it may be proprietary: which means you need to definately experiment - you may be lucky - but if I was developing a 'secret' protocol, I know that I'd definately throw in something which makes decoding it harder (such as 'if the message length is even, then throw in 4 random bytes as certain offsets, and reverse all bytes after the half way point').

  \

  
  
  

• cybrenergy

  nobugz thanks for the response I have tried all the encodings and still have issues. now maintaining it as a byte would make it difficult to manipulate. a bit stuck but I know someone out there has done this before.
  
  

• krauser36

  I've always found that you can't strust any of the Encoding methods. Almost all of the encoding methods will mess up certain binary characters depending upon what you are going to. I usually do it by taking it character by character. From my experience this is the only safe way to do manipulate binary data safely if you have to convert it to a string and/or back. I've not seen whether 2.0 solves any of this however .NET 1.0 and 1.1 always mangled a few of the upper and or lower character. Some more so then others.
  
  

• empty mind

  Hi Guys,

  I have this function which used to work fine in VB6. I use this to pack binary data to a compressed byte.

  Private Function EncodeBitmap(ByVal HexStream As String) As String

  Dim strChars As [String] = [String].Empty

  Dim strHexStream, strTmp As String

  Dim bytAscii As Byte

  Dim i As Short

  'Encode Bitmap

  For i = 1 To Len(HexStream) Step 2

  strTmp = Mid(HexStream, i, 2)

  bytAscii = CByte(CLng("&H" & strTmp))

  strChars = strChars & Chr(bytAscii)

  Next i

  EncodeBitmap = strChars

  End Function

  Now this does not seem to work with VB .NET, Any pointers

  
  
  

• RobClark14

  You can make your own converter. For example:
  Public Function ConvertBinaryToString(ByRef bytes() As Byte, ByVal len As Integer) As String
  Dim cvt As New StringBuilder(len)
  Dim ix As Integer
  For ix = 0 To len - 1
  cvt.Append(Chr(bytes(ix)))
  Next
  Return cvt.ToString
  End Function
  
  
  
  

• MrLunch

  SJ,

  I think you are right, there is a huge learning curve for me here. Ok I get the Source message from a Java Socket and I am not too sure how it is encoding the data thats a start.

  Can you kindly help me with where I can get this informtion. Have to admit lost in wonder land.

  
  
  

• gopalkrishna

  I think you are making this more difficult than it is:

  1. Everything is bytes - there is nothing else.

  2. Bytes can represent a variety of things (for example 4 bytes could represent a single or an integer).

  If the string is converted from a string as ASCII encoding, then when you receive it, you can convert it back to a string via ASCII decoding. Guaranteed. It won't get all jumbled up.

  You need to know how the string is encoded (to bytes) to be able to decode it (Ascii, ANSI, unicode, etc.). It currently seems like you are guessing. Likewise you need the protocol, or again you are guessing (where does the string start and where does it end).

  If you have no information on the encoding scheme, and you are sure that it's only a single byte per character, and ASCII encoding keeps showing question marks, then try the Default encoding to get the ANSI (0-255) characters: of course, this completely depends on your default code page on the receiving machine (this is what nobugz said - the default encoding should give you what you need, there's no need to rip through the array of bytes).

   

  
  
  
• Socket Encoding and Decoding using Ascii Encoding