Re-programming the output on a Magtek MagWedge - language-agnostic

I am trying to reprogram the the output of my Magtek MagWedge and I cant find any documentation on how the syntax to send to output just the cc number from my cc swipe reader and not of the other data
Below is the example configuration, however I have no clue how to change these values to.
Comment:Set up IntelliPIN to Required Configuration
/rawxact 50B01001011
/rawxact 50E10000000
/rawxact 940101010101010101
/rawxact 564
Comment:99{{SN}}
/rawsend 52
Comment:50Z00000110
/rawsend 42Setup Done
Thanks!

It turns out I needed to get the USBMSR Demo program and then send message 01 03 then send 02, then restart the application and send 01 03 send msg then 02 send msg and it fixed it for me.

Related

Pig count occurrence of strings in text messages

I've got two files - venues.csv and tweets.csv. I want to count for each of the venues the number of times occurs in the tweet message from the tweets file.
I've imported the csv files in HCatalog.
What I managed to do so far:
I know how to filter the text fields and to get these tuples that contain 'Shell' their tweet messages. I want to do the same but not with hard-coded Shell, rather for each name from the venuesNames bag. How can I do that? Also then how can I use the generate command properly to generate a new bag that is matching the results from the count with the names of the venues?
a = LOAD 'venues_test_1' USING org.apache.hcatalog.pig.HCatLoader();
b = LOAD 'tweets_test_1' USING org.apache.hcatalog.pig.HCatLoader();
venuesNames = foreach a generate name;
countX = FILTER b BY (text matches '.*Shell.*');
venueToCount = generate ('Shell' as venue, COUNT(countX) as countVenues);
DUMP venueToCount;
The files that I'm using are:
tweets.csv
created_at,text,location
Sat Nov 03 13:31:07 +0000 2012, Sugar rush dfsudfhsu, Glasgow
Sat Nov 03 13:31:07 +0000 2012, Sugar rush ;dfsosjfd HAHAHHAHA, London
Sat Apr 25 04:08:47 +0000 2009, at Sugar rush dfjiushfudshf, Glasgow
Thu Feb 07 21:32:21 +0000 2013, Shell gggg, Glasgow
Tue Oct 30 17:34:41 +0000 2012, Shell dsiodshfdsf, Edinburgh
Sun Mar 03 14:37:14 +0000 2013, Shell wowowoo, Glasgow
Mon Jun 18 07:57:23 +0000 2012, Shell dsfdsfds, Glasgow
Tue Jun 25 16:52:33 +0000 2013, Shell dsfdsfdsfdsf, Glasgow
venues.csv
city,name
Glasgow, Sugar rush
Glasgow, ABC
Glasgow, University of Glasgow
Edinburgh, Shell
London, Big Ben
I know that these are basic questions but I'm just getting started with Pig and any help will be appreciated!
I presume that your list of venue names is unique. If not, then you have more problems anyway because you will need to disambiguate which venue is being talked about (perhaps by reference to the city fields). But disregarding that potential complication, here is what you can do:
You have described a fuzzy join. In Pig, if there is no way to coerce your records to contain standard values (and in this case, there isn't without resorting to a UDF), you need to use the CROSS operator. Use this with caution because if you cross two relations with M and N records, the result will be a relation with M*N records, which might be more than your system can handle.
The general strategy is 1) CROSS the two relations, 2) Create a custom regex for each record*, and 3) Filter those that pass the regex.
venues = LOAD 'venues_test_1' USING org.apache.hcatalog.pig.HCatLoader();
tweets = LOAD 'tweets_test_1' USING org.apache.hcatalog.pig.HCatLoader();
/* Create the Cartesian product of venues and tweets */
crossed = CROSS venues, tweets;
/* For each record, create a regex like '.*name.*'
regexes = FOREACH crossed GENERATE *, CONCAT('.*', CONCAT(venues::name, '.*')) AS regex;
/* Keep tweet-venue pairs where the tweet contains the venue name /*
venueMentions = FILTER regexes BY text MATCHES regex;
venueCounts = FOREACH (GROUP venueMentions BY venues::name) GENERATE group, COUNT($1);
The sum of all venueCounts might be more than the number of tweets, if some tweets mention multiple venues.
*Note that you have to be a little careful with this technique, because if the venue name contains characters that have special interpretations in Java regular expressions, you'll need to escape them.

Google Apps Script suddenly started throwing 'invalid mime type' errors

I have a script which processes a shared mailbox and forwards on different email (based on things like the original 'To:' header to various people. It's been working fine for months as a more flexible (and, up till now, reliable) replacement for gmail filters.
The logic is basically
Read each unprocessed message in the inbox
Look up who it was sent 'To:' (e.g. support#domain.com) which is an alias for this gmail inbox
Get a list of the intended recipients (within our organistion)
For each of those, forward the message on
Mark that message as processed, so it doesn't get re-forwarded next time
We've recently received an email which seems to trigger a weird error at the point at which the message is forwarded on. The error is:
Invalid mime type. (line 123, file "Code").
Line 123 of the script reads:
// subject: removes the 'Fwd:' prefix which we don't need, and adds the original target email in square brackets, and sets the replyTo for easy processing
really && msg.forward(rcvr, {subject: msg.getSubject() + " [" + thisTo + "]", replyTo: msg.getFrom()});
Here's a summary of the interesting bits:
really is just a boolean so we can do 'dry runs' for testing
msg is set to the current message being processed, and is of type GmailMessage
rcvr is a string with the recipient's email address
thisTo is a string holding the original 'To:' header
The message in question is a multi-part mime email with plain text and html in it. It displays just fine in gmail, and I can forward it on from there without problems. So, could anyone shed light on what the script engine is complaining about? The raw email looks like this (with some bits taken out for privacy) in case that helps pin it down:
Delivered-To: XXXX#YYYY.com
Received: by 10.182.155.73 with SMTP id vj5sqase239pbc;
Wed, 26 Jun 2013 08:50:48 -0700 (PDT)
X-Received: by 10.68.166.5 with SMTP id zc5m425et238pbb.16.1372261847795;
Wed, 26 Jun 2013 08:50:47 -0700 (PDT)
Return-Path: <support#ZZZZ.com>
Received: from mail.ZZZZ.com (mail.ZZZZ.com. [64.78.193.232])
by mx.google.com with ESMTP id vj5sqwefwe239pbc.316.2013.06.26.08.50.47
for <multiple recipients>;
Wed, 26 Jun 2013 08:50:47 -0700 (PDT)
Received-SPF: pass (google.com: domain of support#ZZZZ.com designates aa.bb.cc.dd as permitted sender) client-ip=aa.bb.cc.dd;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of support#ZZZZ.com designates aa.bb.cc.dd as permitted sender) smtp.mail=support#ZZZZ.com
Date: Wed, 26 Jun 2013 09:50:46 -0600
To: AAAA#YYYY.com, XXXX#YYYY.com
From: ZZZZ <support#ZZZZ.com>
Reply-to: ZZZZ <support#ZZZZ.com>
Subject: ZZZZ (Order #00412744)
Message-ID: <805b426783f23fec38ddafb002ce40b#admin.ZZZZ.com>
X-Priority: 3
X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net)
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_805b426783ff4601fbe72afb002ce40b"
--b1_805b426783ff4601fbe72afb002ce40b
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: 7bit
Hello Andy,
[SNIP]
and destroy all copies of the original message. Thank You
--b1_805b426783ff4601fbe72afb002ce40b
Content-Type: text/html; charset = "utf-8"
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
[SNIP]
and destroy all copies of the original message. Thank You</span></font></p></td></tr></tbody></table></body>
</html>
--b1_805b426783ff4601fbe72afb002ce40b--

Malformed JSON string, encoding issue?

I am requesting a web service and getting a JSON data as shown below. However, I keep getting the following error:
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "\x{feff}\x{feff}{"ur...") at /usr/share/perl5/JSON/Any.pm
http request:
Date: Tue, 16 Apr 2013 10:41:03 GMT
Server: nginx/0.7.67
Content-Type: application/json; charset=utf-8
Client-Date: Tue, 16 Apr 2013 10:41:03 GMT
Client-Peer: 127.0.1.1:80
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
json data:
{"url":"http:\/\/example.com\/service\/rest.htm?req_data=<auth_req><request_token>20130416f186a9c0480e2501e73d19dbcd79d354<\/request_token> <\/auth_req>&user=208860&service=auth.execute&sid=0001&format=xml&v=2.0& sign=pn9xjQjzTgQuAMarLDtiZCMaGZm4bSo8aUTGtkSt1GrxPGtK29oIL1DgHveVMwf2n7rxLHzyWrNd%2BYU6%2BxZCzs56JkMtxQMPxEJ%2Bu9Eqk5SRL6EAjWMeKheix5frPyHi0hQ4nnbiVm%2Bx3bF0KFq3cORvVCeq8wBoZU1HQXD%2BuuY%3D"}
I suspect some kind of encoding issue because the JSON string validates fine in jslint JSON validator. But I don't know what else to look for. Please help, thanks.
\x{feff} is a BOM (Byte Order Mark). I am not sure whether it is allowed at the beginning of a JSON, but it definitely should not be repeated.
thanks to choroba for prompting me to look for the BOM. Greped 3rd party library files which generates the url and surely found the BOM in them.
grep -rl $'\xEF\xBB\xBF' . # Got BOM?
perl -pi -nle 's/^\xEF\xBB\xBF//' *.lib # remove them!
cheers.

Weird character at start of json content type

I'm trying to return json content read from MySQL server. This is supposed to be easy but, there is a 'weird' character that keeps appearing at start of the content.
I have two pages for returning content:
kcb433.sytes.net/as/test.php?json=true&limit=6&input=d
this test.php is from a script written by Timothy Groves, which converts an array to json output
http://kcb433.sytes.net/k.php?k=4
this one is supposed to do the same
I tried to validate it here jsonformatter.curiousconcept.com but just page 1 gets validated, page 2 says that it does not contain JSON data.
If accessed directly both pages has no problems. Then what is the difference, why both don't get validated?
Then I found this page jsonformat.com and tried the same thing. Page 1 was ok and page 2 wasn't but, surprisingly the data could be read. At a glance,
{"a":"b"}
may look good but there is a character in front.
According to a hex editor online, this is the value of the string above (instead of 9 values, there are 10):
-- 7B 22 61 22 3A 22 62 22 7D
The code to echo json in page 2 is:
header("Content-Type: application/json");
echo "{\"a\":\"b\"}";
Your k.php file has BOM signature at the start, save k.php again with UTF8 without BOM.

What is the byte signature of a password-protected ZIP file?

I've read that ZIP files start with the following bytes:
50 4B 03 04
Reference: http://www.garykessler.net/library/file_sigs.html
Question: Is there a certain sequence of bytes that indicate a ZIP file has been password-protected?
It's not true that ZIP files must start with
50 4B 03 04
Entries within zip files start with 50 4B 03 04... ..and often, pure zip files start with a zip entry as the first thing in the file. But, there is no requirement that zip files start with those bytes. All files that start with those bytes are probably zip files, but not all zip files start with those bytes.
For example, you can create a self-extracting archive which is a PE-COFF file, a regular EXE, in which there actually is a signature for the file, which is 4D 5A .... Then, later in the exe file, you can store zip entries, beginning with 50 4B 03 04.... The file is both an .exe and a .zip.
A self-extracting archive is not the only class of zip file that does not start with 50 4B 03 04 . You can "hide" arbitrary data in a zip file this way. WinZip and other tools should have no problems reading a zip file formatted this way.
If you find the 50 4B 03 04 signature within a file, either at the start of the file or somewhere else, you can look at the next few bytes to determine whether that particular entry is encrypted. Normally it looks something like this:
50 4B 03 04 14 00 01 00 08 00 ...
The first four bytes are the entry signature. The next two bytes are the "version needed to extract". In this case it is 0x0014, which is 20. According to the pkware spec, that means version 2.0 of the pkzip spec is required to extract the entry. (The latest zip "feature" used by the entry is described by v2.0 of the spec). You can find higher numbers there if more advanced features are used in the zip file. AES encryption requires v5.1 of the spec, hence you should find 0x0033 in that header. (Not all zip tools respect this).
The next 2 bytes represents the general purpose bit flag (the spec calls it a "bit flag" even though it is a bit field), in this case 0x0001. This has bit 0 set, which indicates that the entry is encrypted.
Other bits in that bit flag have meaning and may also be set. For example bit 6 indicates that strong encryption was used - either AES or some other stronger encryption. Bit 11 says that the entry uses UTF-8 encoding for the filename and the comment.
All this information is available in the PKWare AppNote.txt spec.
It's underlying files within the zip archive that are password-protected. You can have a series of password protected and password unprotected files in an archive (e.g. a readme file and then the contents).
If you followed the links describing ZIP files in the URL you reference, you'd find that this one discusses the bit that indicates whether a file in the ZIP archive is encrypted or not. It seems that each file in the archive can be independently encrypted or not.