I am experience some trouble decoding the output of a 1D Chinese Barcode Reader. The reader uses a USB interface and connects as a Keyboard HID device (which I have no problem with). After interfacing the device with Labview and generating the inf driver file I tried reading device interrupt data from a test barcode in the configuration manual "000200" the output of the Device is sent serially and is as follows "39 39 39 31 39 39 40".
I am guessing that 40 is the escape character the 39 is 0 and the 31 is 2.
After doing some research I could not find the relevant key code table for this encoding. I have tried disabling all other encoding formats using the configuration manual (39, full ascii, int 2 to 5..).
The module was able to read Upper case letter and send an additional character noting that it is an Upper Case
The device stopped reading the barcode after disabling the Code 128. I re-enabled this option and reading was successful. however the code 128 table have the "G" assigned to the 39 output and not the 0 which messes up the reading.
Did anyone work with the following format? if so which key code is it? or should I map the character set manually?
The following is a link to the purchased Module:
Reader
Thank you it is much appreciated!
As per this answer, a USB HID device sends USB usage codes, not ASCII character codes. That answer links to the lengthy official documentation on usb.org, but this document from microsoft.com appears to be a concise summary. If those links break in future, a web search for usb hid key codes or similar should find an equivalent.
Looking at the HID Usage ID column on the Microsoft document, the code for '0' is 27 in hexadecimal, which is 39 in decimal. '2' is 1F which is 31, and 40 decimal is 28 hex which corresponds to Return. That would be consistent with the output you're seeing, assuming you're reporting it as a sequence of decimal values. As you've observed, a capital letter is sent as two codes, the first of which will probably correspond to the 'shift' key in the HID usage table.
You could try searching or asking around for a LabVIEW VI to translate these codes into ASCII characters but it's probably quicker to build your own based on the table linked above. To test it, you could use a barcode generator program or webpage to create barcodes for all the characters you want to be able to decode and check that scanning them with your device gives the correct output.
Example:
Open "C:\...\someFile.txt" For Output As #1
Print #1, someString
Close #1
If someString contains non-ASCII characters, how are they encoded? (UTF-8, Latin-1, some codepage depending on the Windows locale, ...)
On my system, the code above seems to use Windows-1252, but since neither the documentation of the Open statement nor the documentation of the Print # statement mention string encodings, I cannot be sure whether this is some built-in default or some system setting, and I'm looking for an authorative answer.
Note: Thanks to everyone suggesting alternatives for how to create files with specific encodings (ADODB.Stream, Scripting.FileSystemObject, etc.) - they are appreciated. This question, however, is about understanding the exact behavior of legacy code, so I am only interested in the behavior of the code quoted above.
Testing indicates that the VBA Print command converts Unicode strings to the single-byte character set of the code page for the current Windows "Language for non-Unicode programs" system locale. This can be illustrated with the following code, which attempts to write the Greek word Ώπα:
Option Compare Database
Option Explicit
Sub GreekTest()
Dim someString As String
someString = ChrW(&H38F) & ChrW(&H3C0) & ChrW(&H3B1)
Open "C:\Users\Gord\Desktop\someFile.txt" For Output As #1
Print #1, someString
Close #1
End Sub
When run with Windows set to the default locale for US English, the resulting file contains the bytes
3F 70 61
which correspond to the Windows-1252 characters ?pa. Windows-1252 is the character set most commonly (but incorrectly) referred to as "ANSI".
However, after changing the Windows "non-Unicode" locale setting to Greek (Greece)
the same VBA code writes a file containing the bytes
BF F0 E1
which correspond to the Windows-1253 (Greek) characters Ώπα.
I've been trying to write a simple script compiler for a custom language used by the Game Boy Advance's Z80 processor.
All I want it to do is look at a human-readable command, take it and its arguments and convert it into a hexadecimal value into a ROM file. That's it. Each command is a byte, and each may take a different number of arguments - arguments can be either 8, 16, or 32 bits and each command has a specific number of arguments that it takes.
All of this sort of code is handled by the game and converted into workable machine code within the game's memory, so I'm not writing a full-on assembly compiler if you will. The game automatically knows how many args a command has, what each command does, exactly how to execute it as it is, etc.
For instance, you have command 0x4E, which takes in one 8-bit argument and another 32-bit argument. In hex that would obviously be 4E XX YY YY YY YY. I want my compiler to read it from text as foo 0xXX 0xYYYYYYYY and directly write it into a file as the former.
My question is, how would I do that in VB.NET? I know it's probably a very simple answer, but I see a lot of different options to write it to a file--some work and most don't for me. Could you give me some sample code as to how I would do this?
Writing an assembly compiler as I understand it is not so simple. I recomed you to use one already written see: Software Development Tools for Z80 Family
If you are still interested in writing it here are instructions:
Write the text you want to translate to some file (or memory stream)
Read it line by line
Parse the line either splitting it to an array or with regular
expressions
Identify command and arguments (as far as I remember it some commands
does not have arguments)
Translate the command to Hex (with a collection or dictionary of
commands)
Write results to an array remembering the references for jump
addresses
When everything is translated resolve addresses and write them to
right places.
I think that the most tricky part is to deal with symbolic addressees.
If you are still interested write a first piece of code (or ask how to do it) and continue with next ones.
This sounds like an assembler, even if it for a 'custom language'.
Start by parsing the command lines. use string.split method to convert the string to an array of strings. the first element in the array is your foo, you can then look that up and output 4E, then convert the subsequent elements to bytes.
I'm trying to convert Delphi code to vb.net and I'm not sure about this line:
stream.Seek($42, soFromBeginning);
I'm familiar with using seek on filestreams (in vb.net) but I'm not sure about the $42.
I'm assuming that corresponds to a position, but how does that translate to vb.net?
$ is the prefix for a hexadecimal constant. In VB.NET, that's &H, so you would write &H42.
The code required for VB.net is almost identical:
stream.Seek(&H42, SeekOrigin.Begin)
The points of note here are:
$ in Delphi is the prefix for hexadecimal.
The soFromBeginning corresponds to SeekOrigin.Begin.
The $42 value is the offset from the beginning of the stream.
In VB.NET that would be :
reader.BaseStream.Seek(66, IO.SeekOrigin.Begin)
This is from a Oracle SQL query. It has these weird skinny rectangle shapes in the database in places where apostrophes should be. (I wish we would could paste screen shots in here)
It looks like this when I copy and paste the results.
spouse�s
is there a way to write a SQL SELECT statement that searches for this character in the field and replaces it with an apostrophe in the results?
Edit: I need to change only the results in a SELECT statement for reporting purposes, I can't change the Database.
I ran this
select dump('�') from dual;
which returned
Typ=96 Len=3: 239,191,189
This seems to work so far
select translate('What is your spouse�s first name?', '�', '''') from dual;
but this doesn't work
select translate(Fieldname, '�', '''') from TableName
Select FN from TN
What is your spouse�s first name?
SELECT DUMP(FN, 1016) from TN
Typ=1 Len=33 CharacterSet=US7ASCII: 57,68,61,74,20,69,73,20,79,6f,75,72,20,73,70,6f,75,73,65,92,73,20,66,69,72,73,74,20,6e,61,6d,65,3f
EDIT:
So I have established that is the backquote character. I can't get the DB updated so I'm trying this code
SELECT REGEX_REPLACE(FN,"\0092","\0027") FROM TN
and I"m getting ORA-00904:"Regex_Replace":invalid identifier
This seems a problem with your charset configuracion. Check your NLS_LANG and others NLS_xxx enviroment/regedit values. You have to check the oracle server, your client and the client of the inserter of that data.
Try to DUMP the value. you can do it with a select as simple as:
SELECT DUMP(the_column)
FROM xxx
WHERE xxx
UPDATE: I think that before try to replace, look for the root of the problem. If this happens because a charset trouble you can get big problems with bad data.
UPDATE 2: Answering the comments. The problem may be is not on the database server side, may be is in the client side. The problem (if this is the problem) can be a translation on server to/from client comunication. It's for a server-client bad configuracion-coordination. For instance if the server has defined UTF8 charset and your client uses US7ASCII, then all acutes will appear as ?.
Another approach can be that if the server has defined UTF8 charset and your client also UTF8 but the application is not able to show UTF8 chars, then the problem is in the application side.
UPDATE 3: On your examples:
select translate('What. It works because the � is exactly the same char: You have pasted on both sides.
select translate(Fieldname. It does not work because the � is not stored on database, it's the char that the client receives may be because some translation occurs from the data table until it's showed to you.
Next step: Look in DUMP syntax and try to extract the codes for the mysterious char (from the table not pasting �!).
I would say there's a good chance the character is a single-tick "smart quote" (I hate the name). The smart quotes are characters 91-94 (using a Windows encoding), or Unicode U+2018, U+2019, U+201C, and U+201D.
I'm going to propose a front-end application-based, client-side approach to the problem:
I suspect that this problem has more to do with a mismatch between the font you are trying to display the word spouse�s with, and the character �. That icon appears when you are trying to display a character in a Unicode font that doesn't have the glyph for the character's code.
The Oracle database will dutifully return whatever characters were INSERTed into its' column. It's more up to you, and your application, to interpret what it will look like given the font you are trying to display your data with in your application, so I suggest investigating as to what this mysterious � character is that is replacing your apostrophes. Start by using FerranB's recommended DUMP().
Try running the following query to get the character code:
SELECT DUMP(<column with weird character>, 1016)
FROM <your table>
WHERE <column with weird character> like '%spouse%';
If that doesn't grab your actual text from the database, you'll need to modify the WHERE clause to actually grab the offending column.
Once you've found the code for the character, you could just replace the character by using the regex_replace() built-in function by determining the raw hex code of the character and then supplying the ASCII / C0 Controls and Basic Latin character 0x0027 ('), using code similar to this:
UPDATE <table>
set <column with offending character>
= REGEX_REPLACE(<column with offending character>,
"<character code of �>",
"'")
WHERE regex_like(<column with offending character>,"<character code of �>");
If you aren't familiar with Unicode and different ways of character encoding, I recommend reading Joel's article The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!). I wasn't until I read that article.
EDIT: If your'e seeing 0x92, there's likely a charset mismatch here:
0x92 in CP-1252 (default Windows code page) is a backquote character, which looks kinda like an apostrophe. This code isn't a valid ASCII character, and it isn't valid in IS0-8859-1 either. So probably either the database is in CP-1252 encoding (don't find that likely), or a database connection which spoke CP-1252 inserted it, or somehow the apostrophe got converted to 0x92. The database is returning values that are valid in CP-1252 (or some other charset where 0x92 is valid), but your db client connection isn't expecting CP-1252. Hence, the wierd question mark.
And FerranB is likely right. I would talk with your DBA or some other admin about this to get the issue straightened out. If you can't, I would try either doing the update above (seems like you can't), or doing this:
INSERT (<normal table columns>,...,<column with offending character>) INTO <table>
SELECT <all normal columns>, REGEX_REPLACE(<column with offending character>,
"\0092",
"\0027") -- for ASCII/ISO-8859-1 apostrophe
FROM <table>
WHERE regex_like(<column with offending character>,"\0092");
DELETE FROM <table> WHERE regex_like(<column with offending character>,"\0092");
Before you do this you need to understand what actually happened. It looks to me that someone inserted non-ascii strings in the database. For example Unicode or UTF-8. Before you fix this, be very sure that this is actually a bug. The apostrophe comes in many forms, not just the "'".
TRANSLATE() is a useful function for replacing or eliminating known single character codes.