Solver wins a T-Shirt!!! HELP!!!!!

Anon

Hi All,

I have a couple of machines using a web application in PHP, we use a magnetic-card reader connected to the keyboard. The problem is that given the same data in the card the keyboard returns different things according to the language being used in the computer.

I wonder if there's some kind of mapping function or conversion functions to solve the problem. I can fix this in a local app by changing the keyboard language for the running appplication but this is impossible for a web application.

Any ideas will be welcome and if someone does indeed have a good soluion I'll send you a free t-shirt....

toma42

http://php.net/manual/en/function.mb-language.php
is a good place to start, maybe.

mithril

Luis,

It's perhaps not the most elegant of solutions, but if you can fix the problem in a local app why not just fork a new process which calls the external app and returns the standardized data to the web-app. It sounds like you're running in an intranet environ, so the impact on the server shouldn't be too bad unless the card needs to be swiped for ever action.

The other idea that comes to mind is to use the gnu_gettext functions. I've never used gettext myself, but the way I interpret it is that you specify the output language in the header of your script and the gettext() function will translate whatever string's it's given into the defined language (as long as both languages are in the translation table on the server).

Just a couple random thoughts from someone who's half asleep, which most likely make little sense🙂 That being said...... I'm going to bed. HTH,

Cheers,

Geoff A. Virgo

Anon

You really do have a problem. To use server-side code to straighten things out is going to get messy. You cannot accurately decode the character sets unless you know two pieces of information:
1) What the credit card source characterset was
2) What language the client's PC was setup for.

For example the following thought experiment:

Client scans customer's Country#1 credit card (contains ASCII characters above 127) into a Country#1 configured client PC. The characters should be correctly interpretted. The customer walks down the street to a different client which uses a different keyboard configuration and buys something. The same Country#1 credit card is scanned and interpretted differently since this client's keyboard is set to a different language (Country#2). Similarly, what if two different international credit cards are scanned into the same magstrip reader. Without the two pieces of information noted above, you cannot accurately decode the data.

Given this, you probably need to solve the problem on the client-side.

The problem occurs due to the fact that your magstrip reader is running as a keyboard wedge. It is just generating keyboard scan codes which the PC is interpretting as keystrokes. Two solutions:
1) Check if the magstrip reader can be configured for different keyboard/language setups. Most modern barcoding equipment is quite configurable. Look for an advanced reference manual at the manufacturer's website, then read it in depth. Things like this may be buried in the fine print somewhere near the configuration/setup section.
2) Use an interface box between the magstrip reader and the keyboard/PC. These boxes usually contain more intelligence (and configurability) than the barcoding/magstrip devices themselves. Have the interface box handle the language issues (see #1 above).
3) Don't connect the magstrip reader up as a keyboard wedge. Connect it to a COM port or something similiar. This will require more code mods on the client's setup for you to get the data, but circumvents the whole problem.

FYI... I am working with two different clients right now. One is doing barcode scanning (with an interface box that does magstrip readers). The other needs a language module for international character conversion. Hours of fun for the whole family. :-)

Good luck!
-- Michael
Darkstreak Computing & Innovations
www.darkstreak.com

Anon

(Yes, I am following up to my own posting.)

Experimenting with your problem a little, there is a solution if certain conditions are met. If the data you are interested is in a predictable character set on the (credit?) card, then using a keyboard wedge-style magstrip reader will still work.

If the source data is predictable, then the problem becomes one of writing a conversion table for each client language configuration and keeping track of which client uses which language config. This could be done on either the client-side or the server-side. I would recommend doing it on the server-side since that would reduce the long term maintenance by limiting the amount of code going over the net, plus it also reduces the likelihood of someone messing with your code.

Gotta go. Just arrived at a client's site.

-- Michael
Darkstreak Computing & Innovations
www.darkstreak.com