We Keep Coding

IRC receiving 0x02 value, treat as formatting?

Once I register a nick with a IRC server (in this case Freenode), I receive a message like this:
:NickServ!NickServ#services. NOTICE IRCLIBtester :*IRCLIBtester* is not a registered nickname.
I have inserted asterisks(*) where the weird 0x02 byte is received. Since the servers 005 ISUPPORT contained
CASEMAPPING=rfc1459 CHARSET=ascii
I assumed the messages would be pure ASCII, but in ASCII 0x02 is the Start-of-text marker. Looking at how other clients (in this case HexChat) parsed the string I noticed they took it as a "bold-font" toggle, so the nick would be in bold. Is this practice? And if so, which format is this?
My first thought is RTF, but since I display the text in a richtextbox(C#), it should have parsed the 0x02 byte itself right?

0x02 is the code for BOLD in IRC. These are undocumented in the RFC (1459 and onwards) but can be found via google.
You may find other format codes here: http://forum.egghelp.org/viewtopic.php?t=3867

How can I decode PDU with GSMComm or PduBitPacker?

I want to Decode PDU Text Retrieved from GSM Modem in C#, How can I decode it with GSMComm or PduBitPacker?
Please answer me with a code
TY
(P.S. I have encoded text and I do not need to get it from Modem)

Make sure you include PDUConverter.dll in your project.
IncomingSmsPdu sms = IncomingSmsPdu.Decode("0791893905004100640C9189398978168400003160915151238110050003110202C26735B94D87DF41", true);
Console.WriteLine(sms.UserDataText);
The first argument of Decode is your RAW PDU string including header at the end, the second argument is a flag telling the decoder that a header is present.
Inside of UserDataText you will find the SMS text.
If you see estrange characters at the beginning, it is because you have a "Smart Message", that is, a multi-part SMS that should be concatenated into a single large message, this is a trick invented by Nokia.
The class GsmComm.PduConverter.SmartMessaging.SmartMessageDecoder could be of help if you want to deal with this smart messaging thing.

Decoding Base64 / Quoted Printable encoded UTF8 string

In my ASP.Net application working process, I need to do some work with string, which equals something like
=?utf-8?B?SWhyZSBCZXN0ZWxsdW5nIC0gVmVyc2FuZGJlc3TDpHRpZ3VuZyAtIDExMDU4OTEyNDY=?=
How can I decode it to normal human language?
Thanks in advance!
Update:
Convert.FromBase64String() does not work for string, which equals
=?UTF-8?Q?Bestellbest=C3=A4tigung?=
I get The format of s is invalid. s contains a non-base-64 character, more than two padding characters, or a non-white space-character among the padding characters. exception.
Update:
Solution Here
Alternative solution
Update:
What kind of string encoding is that: Nweiß ???

It's actually a base-64 string:
string zz = "SWhyZSBCZXN0ZWxsdW5nIC0gVmVyc2FuZGJlc3TDpHRpZ3VuZyAtIDExMDU4OTEyNDY=";
byte[] dd = Convert.FromBase64String(zz);
// Returns Ihre Bestellung - Versandbestätigung - 1105891246
string yy = System.Text.Encoding.UTF8.GetString(dd);

I've written a library that will decode these sorts of strings. You can find it at http://github.com/jstedfast/MimeKit
Specifically, take a look at MimeKit.Utils.Rfc2047.DecodeText()

This seems to be MIME Header Encoding. The Q in your second example indicates that it is Quoted Printable.
This question seems to cover the variants fairly well. In a quick search I didn't find any .NET libraries to decode this automatically, but it shouldn't be hard to do manually if you need to.

That's not UTF8. Thats a Base64 encoded string.
the UTF-8 only indicates that the target string is in UTF8 format.
After decoding the Base64 string:
SWhyZSBCZXN0ZWxsdW5nIC0gVmVyc2FuZGJlc3TDpHRpZ3VuZyAtIDExMDU4OTEyNDY=
You'll get the following result:
Ihre Bestellung - Versandbestätigung - 1105891246
See Base64 online decode/encode

Looks like a base64 string.
Try Convert.FromBase64String
http://msdn.microsoft.com/en-us/library/system.convert.frombase64string.aspx

This is an encoded word, which is used in email headers when there is non-ASCII content. Encoded words are defined in RFC 2047:
https://www.rfc-editor.org/rfc/rfc2047#section-2
The BNF for an encoded word is:
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
So the correct way to interpret this is:
The data is the stuff between the 3rd and 4th question marks
It has been Base64 encoded (the 'B' stands for Base64; if it were a
'Q' then it would be quoted-printable).
Once you decode the
data, it will be in the UTF-8 character set.
The result, as #Shai correctly pointed out, is:
Ihre Bestellung - Versandbestätigung - 1105891246
This is German. The umlaut is obviously the reason for the UTF-8 and thus the need for an encoded word. The translation is:
Your order - Delivery confirmation - 1105891246
Apparently it's a tracking number for an order.
All modern email clients (and Outlook) transparently support encoded words.

This is a bit of guesswork, but let's try
remove =? from start and ?= from end
keep the start up to the next ? as the character set
Remove the B? - don't know, what it is
Convert the rest to a byte[] via System.Convert.FromBase64String()
Convert this to the final String via Encoding.GetSTring() using the character set remembered in the second step

Encode data for easy passing over phone

I need to encode some data (text) so that it can easily be passed by the user over phone.
The text contains random characters and is normally not longer than 100 chars. Example:
"37-b,kA.sZ:Bb9--10.y<§"
I'd like to encode this text into more human readable form so that it can easily be passed over phone.
Base36 produces a text that can easily be passed over phone, but I don't see how to encode/decode this correctly.
Any ideas or alternatives?
(Platform is .net 3.5 SP1)

Base 36 sounds like a good choice (when using symbols a-z and 0-9, it is the largest space of characters, that can be easily passed over the phone). I would suggest you make the output contain blocks of 6 or 8 characters, to make it easier to read. Also; consider adding a checksum in the end, so you can verify there are no errors in the data.
100 characters in this encoding will still not be easy to read over the phone and get right the first time. Have you considered another delivery mechanism ? Text message (SMS) ?
On Wikipedia, there is an example of encoding Base36 in Python - shouldn't be too hard to convert to C#.

wsdl xml parsing , maxlength problem after encoding of text

We are working together with another firm. our application communicates with the other application through WCF on our side and a custom implemented java wsdl handler on the other side. They specify the wsdl format and one of the rules is that a specific string cannot contain more then 15 characters. (normally it's 60, but i take 15 for easy example reasons)
When we try to send the following string to them we get an error that the string is too long according to the wsdl:
"example & test" > this is a string of 14 characters, so it should be allowed
the microsoft wcf parser translates this to "example & test" . This encoded string is 18 characters long.
Now what is the standaard behavior to check a maxlength defined in a message? Is it the encoded message or the decoded message? I would think it's the decoded message , but i ain't sure. If it is the encoded message, how should we handle this so we would know how we have to split the string?

http://www.w3.org/TR/xmlschema-2/#rf-maxLength
4.3.3 maxLength
For string and datatypes ·derived· from string, maxLength is measured in units of characters as defined in [XML 1.0 (Second Edition)]
Charsets
[Definition: A parsed entity contains text, a sequence of characters, which may represent markup or character data.]
Reading that I would think the standard behaviour is the decoded as a marked up character should be treated as a single character.
So usually you do any splitting/truncation before you encode it.
Otherwise you run into issues if you truncate through the middle of an encoded character.
I've tested this against a WCF web service with BizTalk behind it and it's fine with an XML encoded string that is longer than the maxLength.
It sounds like they are doing it before the decode it though.
So you may have to encode it first and then split it on the white space.