Unpack ISO8583 version 93 using jpos - iso8583

Hi I am using JPOS for packing and unpacking ISO8583 version 1993 financial messages.
My sample message is like
"1200ð0 € (1699999900000000003110000000000000000000323221152172201308202147072013082020006504465323221152172FKL0033U 40UNI CHANDANNAGAR WEST BENGAL INDINR041300000^0153001530103422610^356^0.00^0200^32027 0927010185639003MOB005UBNET"
Will jpos be able to unpack as the primary bitmap looks like junk.Can i use iso93ascii.xml to unpack or anything else required?

Please take a look at this blog post that explains why you think the bitmap is junk:
http://jpos.org/blog/2014/09/message-hex-dump/
It is not, problem is you're seeing an ASCII representation, which has unprintable characters.
Get a real binary dump.

Related

vCard 4.0 doesn't display correctly, with labels ignored and wrong character decoding, among other things

I have created a vCard 4.0 file with a text editor according to RFC 6350 by IETF. It is simple, and looks kind of like this:
BEGIN:VCARD
VERSION:4.0
KIND:individual
FN:René Descartes
N:Descartes;René;;;
TITLE:Façade Engineer
ADR;
GEO="geo:46.975308,0.699597";
LABEL="Headquarters":
;;29 Rue Descartes;;Descartes;37160;France
TEL;VALUE=uri;TYPE=home:tel:+33247597919
END:VCARD
The file is saved as somename.vcf (with CRLF and in UTF-8) and inspected on my iOS/macOS devices. However, the display of the file has many issues.
Non-ASCII characters are not decoded correctly.
The labels are all wrong.
The URI scheme is prepended to the phone number.
It is as if vCard 4.0 is not supported at all. Or did I make any mistakes?
The screenshot is attached below.
Like you suggested, it looks to me like the client does not support vCard
version 4. For example, URI-formatted telephone numbers are only supported by version 4, which might explain why it is not rendering the phone number properly. Try using a version 3 vCard.
Your ADR property is formatted strangely. I might trying
putting it all on one line to see if that makes any difference. If your intent is to make use of line
folding, each additional line must be prefixed with a
single space according to the RFC. You are using two spaces.

How can I decode Wordnet entites?

in my experiment, I am using WordNet18 data, which contains triplets of the form (subject, predicate, object), some examples are as follows:
03964744 _hyponym 04371774
00260881 _hypernym 00260622
02199712 _member_holonym 02188065
I would like to know what the entity IDs, like 03964744, stand for. Is there anybody knows how to decode the entities?
Thank you in advance. 
The 8-digit numbers you see are probably the byte offset of the entry in the data files. See http://wordnet.princeton.edu/wordnet/man/wnintro.5WN.html
After quite a bit of hunting around, I think you are looking at the numbers of WordNet 3.0 (the byte offsets for a given synset differ between versions; 3.1 is the latest version).
Your first entry seems to be saying that swing is a type of toy:
http://compling.hss.ntu.edu.sg/omw/cgi-bin/wn-gridx.cgi?usrname=&gridmode=grid&synset=04371774-n&lang=eng&lang2=eng
http://compling.hss.ntu.edu.sg/omw/cgi-bin/wn-gridx.cgi?synset=03964744-n

How to send xon/xoff in case of binary data?

In case of software data flow control, we use xon and xoff (0x11 and 0x13) standard characters to pause and resume transmission. But if we want to send binary data which contains characters which match with the ascii value of xon and xoff, what character set should we use to send xon or xoff ?
I simple solution is to use base64 encoding, which you have it in python ..
base64.b64encode(yourData) - encode
base64.b64decode(yourData) - decode,
it adds the additional overhead but the sent data is in simple character format. even HDLC used base64 so this will be one option for you I suppose.
Using software handshaking precludes the sending of binary data.
Short of doing something esoteric (sending 9 bits/byte instead of 8 - very non-standard) there is no distinction between 2 of the 256 different binary data and the 2 codes selected for uses as XON/XOFF.
There are various protocols that attempt to deal with this. They all encode the "binary data" into something efficient but not a one-to-one mapping. One can use escape codes, compression, data packets, etc. Of course, both ends of the communication need to know how to encode/decode. This often limits your choices. If in doubt, start with Binary-to-text encoding as it tends to be easier to debug. http://en.wikipedia.org/wiki/Binary-to-text_encoding
To be able to use those two special characters as control ones, you have to make sure they do not occur in the payload data. One way to do that is to encode payload with a reduced alphabet that does not include the special characters. The binary-to-text encodings mentioned in a parallel answer would do the job, but if low overhead not depending on distribution of input bytes is critical, then the escapeless encoding may help.

How Do I Convert a Byte Stream to a Text String?

I'm working on a licensing system for my application. I'd like to put all licensing information (licensee name, expiration date, and enabled features) into an object, encrypt that object with a private key, then represent the encrypted data as a single text string which I can send via email to my customers.
I've managed to get the encrypted data into a byte stream, but I don't know how to convert that byte stream into a text value -- something that contains no control characters or whitespace. Can anyone offer advice on how to do that? I've been researching the Encoding class, but I can't find a text-only encoding.
I'm using Net 2.0 -- mostly VB, but I can do C# also.
Use a Base64Encoder to convert it to a text string that can be decoded with a Base64Decoder. It is great for representing arbitary binary data in a text friendly manner, only upper and lower case A-Z and 0-9 digits.
BinHex is an example of one way to do that. It may not be exactly what you want -- for example, you might want to encode your data such that it's impossible to inadvertently spell words in your string, and you may or may not care about maximizing the density of information. But it's an example that may help you come up with your own encoding.
I've found Base32 useful for license keys before. There are some C# implementations linked from this answer. My own license code is based on this implementation, which avoids ambiguous characters to make it easier to retype the keys.

Char.ConvertFromUtf32 not available in Silverlight

I'm converting a WinForms app to Silverlight (VB.NET). What should I use instead of Char.ConvertFromUtf32 as it's not available to use in Silverlight?
UTF-32 is currently not part of Silverlight, so you have to find a way around the limitation. I think you should stop a moment and think exactly why you need to read UTF32-encoded text.
If you are reading such text from a database or a file on the server, I would perform the conversion server-side (if possible I would convert everything to UTF-8 and get rid of the UTF-32 data in one shot).
If you are parsing a user-provided file on the client side, I would detect the UTF-32 encoding and gently tell the user that the file encoding is not supported. UTF32 is pretty rare nowadays, so I guess it should not be a very common case (but I could be wrong not knowing your exact situation).
In order to detect the file encoding you have to look at the first few bytes (byte order mark) -more information here, if they are not present the task becomes much harder and involves some kind of heuristics based on character frequency.
From: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/types/how-to-convert-between-hexadecimal-strings-and-numeric-types
You can use a direct cast, like:
// Get the character corresponding to the integral value.
string stringValue = Char.ConvertFromUtf32(value);
char charValue = (char)value;
Small warning, it will only work up to 0xffff. It will not work for high range Unicode from 0x10000 to 0x10ffff.
Also, if you need to parse \uXXXX, try this other question: How do I convert Unicode escape sequences to Unicode characters in a .NET string?