Remove hidden CR's and LF's in Byte array

Following is a code excerpt from a network class that decodes a TCP Socket message.
I assume the reason I don’t see the 2nd trace is because there are 1 or more invisible CR’s or LF’s in the data object.
Is there some way of showing these and or removing them so I can reach my 2nd trace?

 // Get a stream object for reading and writing
     stream = client.GetStream();
    int i;
  // Loop to receive all the data sent by the client.
  while ((i = stream.Read(bytes, 0, bytes.Length)) != 0)
  {
  data = Encoding.ASCII.GetString(bytes, 0, i);

//1st trace, I see TRIGGER
  Debug.Log("0 ASSERT Received: data = " + data );
  switch (data)
  {
  case "TRIGGER":
//Don't see this trace!
  Debug.Log(":1 ASSERT TRIGGER RECEIVED");
//etc, etc\

sure, string.Remove:

The char for carriage return is 0x0D, and line feed is 0x0A.

Though honestly… a string is often a slow way to send messages.

Also, you’re forcing a certain method length by using ‘bytes.Length’ as your message size. What if you want to send variable sized messages (plausible if you like want to direct the program to get a specific gameobject by name… the name is variable in length).

What you can do is instead follow a specific format.

1byte - command (byte enum)
4bytes - data length (int32)
Xbytes - data (variable)

Where the 1st byte is a number that coincides with an Enum, of which possible commands are sent (1 byte, 255 commands).

The next 4 bytes is how long the commands arguments/data is.

Then you read how ever many bytes the previous 4 bytes tells you to. This formatting of this might depend on the command sent. If the command is to ‘trigger a message’, it’ll probably be a string. Where as if the command arithmetic, it might just be floats.

Heck you might even make it where some commands don’t even have the data length. It’s always that the leading byte gives you the information how the next leading bytes are formatted. You can even denote a custom ‘extended’ command which is a free form string. But usually you only have a handful of generic commands to send back and forth…

Keep in mind, you’re using TCP here… pack this up as tight as possible so that message transmission is speedy.