How to get the length value for fields whose length is specified at the beginning of the field in jPos? - iso8583

For more control and clarity of the unpack ISO8583 message , I wanted to print the length of each field, my first attempt was this:
.getFieldPackager(i).getLength()
In a code like this:
Gp=new GenericPackager("./iso87ascii.xml");
message.setPackager(Gp);
for (int i = 0; i <= 128; i++) {
if (message.hasField(i)) {
System.out.println(message.getPackager().getFieldDescription(message, i) +
Gp.getFieldPackager(i).getLength()+
message.getString(i));
}
For fields with variable lengths, it shows the maximum length, not the actual length.
Can any body help?
Edit:
As stated in the comment, We can calculate the length of field:
message.getString(n).getLength()
but we can not figure out what length Jpos has as the length of the field, and if JPos is wrong, there is no way to control it.
We only need the first number of the field, which represents the length of the field, with Jpos terms

You are printing out the configuration of the jPOS Packager, you won’t have addressability to data and its field lengths until you parse and unpack a message using a packager into an ISOMsg Object using message.unpack() - once you unpack() you can get the length of the data using message.getString(n).getLength() or equivalent.

Related

protocol-buffers: string or byte sequence of the exact length

Looking at https://developers.google.com/protocol-buffers/docs/proto3#scalar it appears that string and bytes types don't limit the length? Does it mean that we're expected to specify the length of transmitted string in a separate field, e.g. :
message Person {
string name = 1;
int32 name_len = 2;
int32 user_id = 3;
...
}
The wire type used for string/byte is Length-delimited. This means that the message includes the strings length. How this is made available to you will depend upon the language you are using - for example the table says that in C++ a string type is used so you can call name.length() to retrieve the length.
So there is no need to specify the length in a separate field.
One of the things that I wished GPB did was allow the schema to be used to set constraints on such things as list/array length, or numerical value ranges. The best you can do is to have a comment in the .proto file and hope that programmers pay attention to it!
Other serialisation technologies do do this, like XSD (though often the tools are poor), ASN.1 and JSON schema. It's very useful. If GPB added these (it doesn't change wire formats), GPB would be pretty well "complete".

SSRS Report builder LENGTH expression & size specific field

I'm trying to build a bank file using SSRS report builder (3.0). I'm running into two issues:
I'm trying to get a length expression to work on a check number field but LEN(Field) doesn't work (returns 4 as the value regardless of the actual length of the field).
And LENGTH(Field) gives me an error:
The Value expression for the textrun 'Textbox15.Paragraphs[0]. TextRuns[0\' contains an error: [BC30451] Name 'LENGTH' is not declared*
The only reason why I'm even trying to get #1 to work is because I need to have one of the fields on the bank file have a constant length. Regardless of the check number, I need to make sure this field is always at 14 characters with leading zeros. I thought the best way to do this is to do a switch statement and add the number of appropriate zeros in depending on the size of the check number field.
Thanks for the help.
Edit: using a SQL server DB
For the length issue:
There are two ways to get string length
Using the LEN function
= LEN(Fields!myfield.Value)
Using the length property
= Fields!myfield.Value.Length
If your field is not a string, try converting first by using the Cstr function
= LEN( Cstr(Fields!myfield.Value) )
= Cstr(Fields!myfield.Value).Length
For the formatting issue:
For numeric fields set the cell format expression to have as many zeros as required eg. for 14 digit numbers
= "00000000000000"
I don't know on which database you are working if you are using sql server then try LEN
function and LENGHT in oracle.
I think you first convert it into integer if it's character and then try len function.

Field with variable length for ISO8583 using jPOS

I am using jPOS for creating ISO8583 message, I am using the genericpackager but it seems it only support data fields of fixed length. I want to prepend the length of the field before the field if it has a variable size.
I am using below:
<isofield
id="34"
length="32"
name="Extended Primary Account Number"
class="org.jpos.iso.IF_CHAR"/>
and in .java fileisoMsg.set(34, "12345ABCDE");
What change do I need to make to prepend the length of the field before the field.
For each isofield - you need to modify the class to match the requirements for the appropriate field configuration.
http://jpos.org/doc/javadoc/org/jpos/iso/packager/GenericPackager.html
For instance you can use any of the isofield classes with a Length indicator (L)
such as:
class="org.jpos.iso.IFA_LLCHAR"/>
Or
class="org.jpos.iso.IFB_LLNUM"/>
to support a variable length field.
Where the first example is ASCII 2 byte Length and the second one is Binary 2 byte Length.
you can find a list of sample generic packagers here: https://github.com/jpos/jPOS/tree/master/jpos/src/dist/cfg/packager
you can find a list of isofield classes (start with IF_) here: https://github.com/jpos/jPOS/tree/master/jpos/src/main/java/org/jpos/iso

Determining whether a column is an encryption key or plain text

We have a column of type varchar(25) in a SQL Server table that mistakenly had plain text values inserted when they should have been encrypted with AES. We are going to remove the plain text values from the database. The plan was to verify the block size of the field, though this would cause some unencrypted values to be left. Is there any other criteria I can check to reliably identify valid encrypted data?
We need it to be a T-SQL only solution.
Update
Just dug a little deeper, it's getting the values back from a web service. This web service encrypts them using AES in ASP.Net. It takes the returned byte array and then it uses this method to conver the byte array to a string:
static public string ByteArrToString(byte[] byteArr)
{
byte val;
string tempStr = "";
for (int i = 0; i <= byteArr.GetUpperBound(0); i++)
{
val = byteArr[i];
if (val < (byte)10)
tempStr += "00" + val.ToString();
else if (val < (byte)100)
tempStr += "0" + val.ToString();
else
tempStr += val.ToString();
}
return tempStr;
}
For clarity, I should say I did not originally write this code!
Cheers
Not really, especially since the encoding method doesn't look normal to me. It is more common to base64 encode the data which makes it very distinctive. It really depends what the unencrypted data consists of as to how easily it is to determine whether the data is encrypted or not - for instance, is it words, numbers, does it have spaces etc (since the encoded data has no spaces for instance).
It looks like your encoded data will all be numeric represented as a string so depending on length of data, you could see if your column will cast to a BIGINT.
Not sure the best way off the top of my head but there is an answer here that might help you "try cast" in T-SQL StackOverflow-8453861

Objective C: Parsing JSON string

I have a string data which I need to parse into a dictionary object. Here is my code:
NSString *barcode = [NSString stringWithString:#"{\"OTP\": 24923313, \"Person\": 100000000000112, \"Coupons\": [ 54900012445, 499030000003, 00000005662 ] }"];
NSLog(#"%#",[barcode objectFromJSONString]);
In this log, I get NULL result. But if I pass only one value in Coupons, I get the results. How to get all three values ?
00000005662 might not be a proper integer number as it's prefixed by zeroes (which means it's octal, IIRC). Try removing them.
Cyrille is right, here is the autoritative answer:
The application/json Media Type for JavaScript Object Notation (JSON): 2.4 Numbers
The representation of numbers is similar to that used in most programming languages. A number contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part.
Octal and hex forms are not allowed. Leading zeros are not allowed.