Database Search

TechHome

• !!Processing Templates Files with BinaryTag - Insider Tech Notes
• Binary Sort Two Different Fields
• BinaryPeek versus BinaryPeekStr
• BinaryPoke and Bit Swapping Discussion
• BinaryRead File Line by Line
• BinaryReplace With NULL Characters
• BinarySort Considerations
• BinarySort Example
• BinaryXlate Explanation
• Convert to UTF-8
• Could Not Allocate Binary Buffer Error
• Create Zero Length Binary Value
• CryptAcquireContext Gets a Handle to a Key Container within a CSP
• Example of Keeping Track of Multiple Pointers
• Extract Line 79 from a File
• Insert a Delimiter Every 5 Chars
• Nested Binary Sort
• Offset beyond binary EOD
• Parsing Dilemma
• Remove Line from File that Contains a string
• Remove Line from File
• Replace First Instance of a String in a File
• Retrieve last line from a File
• Search and Replace Another Example
• Search and Replace in Binary Buffer
• Splitting Registry Binary Entry for Writing to INI File
• System Ini writing multiple device lines to
• System.Ini and Device lines
• Use Binary Functions to Edit INI Files
• Use BinaryRead Like FileRead
• Using BinaryPeek to Find Null 00 Character

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

BinaryXlate Explanation

Question:

Answer:

Each ANSI character is a byte (8 bits)
Each EBCDIC character is a byte (8 bits)
A Unicode character is a word (16 bits)

So, for example, ANSI and EBCDIC are definitions for character sets.

At some point in the past several different people decided there needed to be some way to represent characters as numeric codes.

They both code to use 8 bit numbers (which can represent numbers from 0 to 255). THen they started assigning numbers to characters,

and it worked!. However there is basically no similarity between the ANSI and EBCDIC codes except that they were both 8 bits per character.

And everything was just fine for a long time.

BUt when these two systems collided, and large text files needed to be trandlated from one system to the other it became a tedious time consuming operation.

thus was born the Xlate operation.

the concept is that if, say, you had a series of numbers that meant something (Say a text file in the EBCDIC format in 8 bit format) and you needed to translate to a series of numbers in a different format (say an ANSI file, also in 8 bit format) you could specially arrange a table consisting of 256 8-bit bytes. You would then take the first byte of the ebcdic file and pretend it is just a number between 0 and 255 representing an offset into the table

you would then find the byte at that offset into the table and pluck it out of that table. And - because the table was "specially arranged" that byte would be the number representing the ANSI value of the same character.

Now of course if you have a text file full of characters, you have to repeat this operation over and over and over for each character.

Thus the BinaryXlate operation is designed to do exactly that.

so for the EBCDIC operation you need a 256 byte table held in a 256 byte binary buffer.

Now lets change the problem. Lets say you want to convert your ANSI 8-bit file to a Unicode file. Unicode characters are 16 bits.

So let see. You have a maximum of 256 possible ANSI characters. Thus they would convert to a maximum of 256 16-bit (2 byte) numbers. so the table would be 256*2 or 512 bytes in length. You would specially arange this table, perhaps stuffing the numbers into a 512 byte binry buffer using the BinaryPoke2 function and advancing the binary offset by 2 on each stuffing operation. And use a Type 1 BinaryXlate operation. Basically BinaryXlate would multiply the value of the ANSI character by 2 to compute the offset into the special table abd use the BinaryPeek2 function to fetch the Unicode character from the table.

For mode 2... the source is a 16-bit number. With 16 bits you can represent numbers from 0 to 65536. And you are translating the number 16-bit number to a 8 bit number(one byte) so you need a 65536 buffer. Binary Xlate would use the 16 bit "from" number and use it as a direct offset into the Binary Buffer and use the BinaryPeek function to pick up the 8 bit number from that spot and use that as the translation.

for mode 3 both the source and target are 16 bit numbers so you would need a table 65536*2 in size to be able to hold all the possibilities....

Ummm I hope this helps.

PS. If you just somewhat masochist you could look into the BinaryHashRec function, and if a real glutton for punishment, you could look into "content addressable memory" where you can find the name of a variable that holds certain data.

Article ID:   W16390

File Created: 2005:02:18:12:20:16

Last Updated: 2005:02:18:12:20:16