There are any number of ways to do this. You could, for example, treat
|| as being a literal
| and not your field separator. If your current process for decoding your packet involves first splitting it on single
| tokens, you'll probably want to either
- change the split so it uses a regular expression with a negative lookahead to avoid the
- process the packet data linearly instead of pre-emptively splitting it.
That said, I would suggest instead that you don't transmit ASCII data as your packet payloads, but instead serialize them to an efficient binary representation (this is not the same as encrypting them). You'll have far fewer character-escape issues this way, because the structure of your chat packet (for example) will be something like four bytes to indicate a message length, followed by n bytes of character data that you know is the entire message.
(You can, of course, use the length-prefixing technique in an ASCII-format payload as well, as suggested by Byte56 in his answer.)
Alternatively, if you're going to use ASCII payload data for diagnostics and visibility, choose a format that is already known so you can leverage existing specifications for character escapes (or even better, existing 3rd party libraries). I really don't recommend ASCII transports for data that goes across the public internet, but if you are transmitting only in a more controlled environment (LAN or intranet where the bandwidth issue isn't as severe, nor are the visibility concerns) it can be a reasonable approach.