wsdl xml parsing , maxlength problem after encoding of text - c#

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.

Related

How to convert escape characters to ANSI from string in XML

When i use a Windows service written in C# to send a raw string to a receipt printer that uses escape sequences to initiate features within the printer. Such as:
\x1b\x64\x02
to operate the paper cutter.
I'm using a receipt template file on another server and placing the text, base 64 encoded, into XML to give it to the Windows service. The problem is that the text is literally printed on the receipt when extracting it from the XML and it's something to do with the escape characters not being translated.
I'm guessing that when i type those escape sequences into Visual Studio, it represents the ANSI character right there in the string (because it works when i do it that way and then the paper cutter triggers).
How would i translate the string containing escape sequences into the proper format for use within the C# Windows service? The goal is to type these simple escape sequences into a template file and then convert them properly on the other end.
C# code i have at the moment that is trying to decode base 64 and then convert to ANSI encoding:
byte[] data = Convert.FromBase64String(content);
content = Encoding.Default.GetString(data);
byte[] utf8Bytes = Encoding.UTF8.GetBytes(content);
content = Encoding.GetEncoding("Windows-1252").GetString(utf8Bytes);
return RawPrinterHelper.SendStringToPrinter(getConfig().receiptPrinter, content);
Here is the content of the test receipt that is received by the service:
XHgxYlx4MWRceDYxXHgxIE1OSG9tZU91dGxldC5jb20yMzAwIFdlc3QgSGlnaHdheSAxMw0KQnVybnN2aWxsZSwgTU4gNTUzMzcNCjk1Mi0yNzktMTU4Nw0KDQpceDFiXHgxZFx4NjFceDBceDFiXHg0NFx4Mlx4MTBceDIyXHgwIERhdGU6IDIwMTctMDYtMTVceDkgVGltZTogMzo0NmFtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KXHgxYlx4NDUgU0FMRSANClx4MWJceDQ2
When i base 64 encode \x7 for example,
From within the service: Bw== (as ASCII)
From within the service: BwA= (as Unicode)
From a string in php: XHg3
So i've found a solution that requires a small amount of change to the template:
On the template side, using PHP, I convert the \x7 style unicode reference to  and then before i base 64 encode it:
$receipt_str = mb_convert_encoding($receipt_str, 'UTF-8', 'HTML-ENTITIES');
This is working so far. I'm just not sure if there is a better way or if there are limits to this.

Encoding/Decoding PDU 7bit septets GSM long messages

I'm looking for Encoding/Decoding algorithm.
I have tried this:
http://codeproblem.hamaraquetta.com/articles/languages/81-net-framework/76-encoding-sms-in-pdu-format-in-net?showall=&start=1
and no luck. :(
Here is what I'm trying
This is the text:
This is a long text message greater than 160 characters. You can encode it to PDU format using the SMS-PDU lib for .NET, It also supports UCS-2 encoding, and special characters like { [ ] } are also supported. Its quite simple to use in your code.
From this text there should 2 messages encoded to septets and after I should be able to submit the message.
This is the result i get:
Part 1:
0041000C917952205197720000A00500033F0201A8E8F41C949E83C220F6DB7D06D1CB783AA85D9ECFC3E732E82C2F87E96539888E0EBB41311B0C344687E5E131BD2C9FBB40D9771D340EBB4165F7F84D2E83D27410FD0D8212AB20F35BDE0ED341F579DA7D06D1D165D0B4396D418955103B2D0699DF7290CB59A4B240493A28CC9EBF41F33A1CFE96D3E7A0EA70DA9281CAEEF19B9C769F59
Part 2:
0041000C917952205197720000690500033F020240613719348797C7E9301B344687E5E131BD2C9F83D8E97519B44181363CD0C607DAA4406179191466CFDFA0791D0E7FCBE965B20B94A4CF41F17A9A5E06CDD36D38BB0CA2BF41F57919947683F2EFBA1C347E93CB2E
this is doesn't work.
How do I solve this?
Btw: this is the phonenumber i know it's important.
+972502157927
Library works completely correctly. ComposeLongSms() returns a string array of PDUs and you should send("submit" as you said) all these PDUs to your GSM modem like separate SMSes. Any concatenating won't work, you can notice that each PDU starts with the same part, which contains encoded additional information for outgoing SMS. You can verify your PDUs here

custom encode ascii chars between 0-31 in C#

i read some data from a device. Then i send this data to a web server via xml. The data should be represented in xml so this makes me convert characters between 0-31 because these chars can not be displayed on xml.
The question is how can i convert the chars between 0-31 decimal in a string like [00]abcde[01]fgh[02]...
Are there any built-in function in .net framework or any accepted pattern?
Thanks
You should use standard XML encoding:
Your XML API will do that for you, so you don't need to worry about anything.
You can simply encode the number as an XML entity you write &# followed by the number and a semicolon
so 1 becomes  and 13 becomes 
 and so on and so forth
However as noted by dan04 you can't represent 0 as a numeric character reference, so in the case where your data might include 0 you will have to use a different encoding. You could encode the entire binary data as base64
Most XML toolboxes will do the encoding to NCRs for you though so you really shouldn't have to worry about that

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

Can a Base64 String contain tabs?

Simple yes or no question, and I'm 90% sure that it is no... but I'm not sure.
Can a Base64 string contain tabs?
It depends on what you're asking. If you are asking whether or not tabs can be base-64 encoded, then the answer is "yes" since they can be treated the same as any other ASCII character.
However, if you are asking whether or not base-64 output can contain tabs, then the answer is no. The following link is for an article detailing base-64, including which characters are considered valid:
http://en.wikipedia.org/wiki/Base64
The short answer is no - but Base64 cannot contain carriage returns either.
That is why, if you have multiple lines of Base64, you strip out any carriage returns, line feeds, and anything else that is not in the Base64 alphabet
That includes tabs.
From wikipedia.com:
The current version of PEM (specified
in RFC 1421) uses a 64-character
alphabet consisting of upper- and
lower-case Roman alphabet characters
(A–Z, a–z), the numerals (0–9), and
the "+" and "/" symbols. The "="
symbol is also used as a special
suffix code. The original
specification, RFC 989, additionally
used the "*" symbol to delimit encoded
but unencrypted data within the output
stream.
As you can see, tab characters are not included. However, you can of course encode a tab character into a base64 string.
Sure. Tab is just ASCII character 9, and that has a base64 representation just like any other integer.
Base64 specification (RFC 4648) states in Section 3.3 that any encountered non-alphabet characters should be rejected unless explicitly allowed by another specification:
Implementations MUST reject the
encoded data if it contains
characters outside the base alphabet
when interpreting base-encoded
data, unless the specification
referring to this document explicitly
states otherwise. Such specifications
may instead state, as MIME does,
that characters outside the base
encoding alphabet should simply be
ignored when interpreting data ("be
liberal in what you accept").
Note that this means that any
adjacent carriage return/ line feed
(CRLF) characters constitute
"non-alphabet characters" and are
ignored.
Specs such as PEM (RFC 1421) and MIME (RFC 2045) specify that Base64 strings can be broken up by whitespaces. Per referenced RFC 822, a tab (HTAB) is considered a whitespace character.
So, when Base64 is used in context of either MIME or PEM (and probably other similar specifications), it can contain whitespace, including tabs, which should be handled (stripped out) while decoding the encoded content.
Haha, as you see from the responses, this is actually not such a simple yes no answer.
A resulting Base64 string after conversion cannot contain a tab character, but It seems to me that you are not asking that, seems to me that you are asking can you represent a string (before conversion) containing a tab in Base64, and the answer to that is yes.
I would add though that really what you should do is make sure that you take care to preserve the encoding of your string, i.e. convert it to an array of bytes with your correct encoding (Unicode, UTF-8 whatever) then convert that array of bytes to base64.
EDIT: A simple test.
private void button2_Click(object sender, EventArgs e)
{
StringBuilder sb = new StringBuilder();
string test = "The rain in spain falls \t mainly on the plain";
sb.AppendLine(test);
UTF8Encoding enc = new UTF8Encoding();
byte[] b = enc.GetBytes(test);
string cvtd = Convert.ToBase64String(b);
sb.AppendLine(cvtd);
byte[] c = Convert.FromBase64String(cvtd);
string backAgain = enc.GetString(c);
sb.AppendLine(backAgain);
MessageBox.Show(sb.ToString());
}
It seems that there is lots of confusion here; and surprisingly most answers are of "No" variety. I don't think that is a good canonical answer.
The reason for confusion is probably the fact that Base64 is not strictly specified; multiple practical implementations and interpretations exist.
You can check out link text for more discussion on this.
In general, however, conforming base64 codecs SHOULD understand linefeeds, as they are mandated by some base64 definitions (76 character segments, then linefeed etc).
Because of this, most decoders also allow for indentation whitespace, and quite commonly any whitespace between 4-character "triplets" (so named since they encode 3 bytes).
So there's a good chance that in practice you can use tabs and other white space.
But I would not add tabs myself if generating base64 content sent to a service -- be conservative at what you send, (more) liberal at what you receive.
Convert.FromBase64String() in the .NET framework does not seem to mind them. I believe all whitespace in the string is ignored.
string xxx = "ABCD\tDEFG"; //simulated Base64 encoded string w/added tab
Console.WriteLine(xxx);
byte[] xx = Convert.FromBase64String(xxx); // convert string back to binary
Console.WriteLine(BitConverter.ToString(xx));
output:
ABCD DEFG
00-10-83-0C-41-46
The relevant clause of RFC-2045 (6:8)
The encoded output stream must be
represented in lines of no more
than 76 characters each. All line
breaks or other characters not
found in Table 1 must be ignored by
decoding software. In base64 data,
characters other than those in Table
1, line breaks, and other white
space probably indicate a transmission
error, about which a warning
message or even a message rejection
might be appropriate under some
circumstances.
YES!
Base64 is used to encode ANY 8bit value (Decimal 0 to 255) into a string using a set of safe characters. TAB is decimal 9.
Base 64 uses one of the following character sets:
Data: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
URLs: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_
Binary Attachments (eg: email) in text are also encoded using this system.

Categories