What The Hell is Ascii (or Ebcdic) Anyway.

Within computers, all data are numbers. Even worse than that, they are binary numbers. Can you imagine programming a computer in binary ?? (I can - I used to use a DGC Nova 210 which had to be booted via a binary front panel...)

Anyway, before things got complicated and Windows was stolen from Xerox, all small single board computers or VDU's used a character generator to produce the characters that you saw on the screen. A character generator was a ROM which contained data about a particular character in an 8x11 or 8x12 (or whatever the character size was) matrix, defining which parts of the cell should be turned on or not by specifying each bit as a one or a zero:

This lead to some interesting things. You could change the screen font of the ACT Sirius quite easily because it was held in RAM rather than ROM. One of the earliest copies of the Australia program used to run on that !!

So, that's how a character is generated - via an offset into a ROM or a File or whatever, but it would be pointless to have different standards because you'd never get one program to run on another machine, or another machine to understand a different machines output if there was not any standard. So, the American Standard Code for Information Interchange was born. EBCDIC by the way is Ascii's big brother for mainframes.

The Ascii Code.

The Ascii code is a 7 bit code that defines a set of values from 0 to 127 which map the various characters you can see on a computer screen into a fixed space. 128 characters was sufficient to provide the upper and lowercase alphabet, the numbers, punctuation and some control characters (more of which later). When windows came along the standard was extended to 255 (and 8 bits) characters and was called Extended Ascii.

So, the table below details the Ascii Characters for the standard 7 bit Ascii Character set:

Printable and Unprintable Characters.

If you look at the top few rows of the table above, you will notice that there are no characters assigned to ASCII codes below 32. Rather, there are a series of codes such as STX, ETX, RS, GS, ESC etc.

These codes are called Control Characters because they were used to control various peripherals. For example character 7 will ring a terminal bell or make a laptop beep. Code 12 will cause a printer to eject the current page and so forth.

So what has this to do with SAP ??

When you are debugging a program, you might see something like this in the debug window:

The string is showing '#' (hash) characters where it has been joined with Tab Characters. This is due to the fact that a Tab character is a control or non-printable character and as such does not have a 'shape' associated to it. SAP displays all control characters in the same way.

To see the values for the characters, click on the magnifying glass. This provides a hexadecimal representation of the variable, with each character taking up two digits:

If you scan along the line you'll see two characters '09' that's the tab character that is being shown as a '#' in the previous figure.

Finding The Ascii Code Of A Character.

Having had a short history lesson, here's how to translate between an ASCII value and it's Character counterpart, and Vice-Versa. This is something like the ASC() and CHR() functions of VB.

First, define a structure consisting of a single hex field:


Data: Begin of t__chr, "ASCII/CHR Converter
asc type x,
End of t__chr,

To obtain the Ascii value of a character move the character to the structure and read the field:

Move 'A' to t__chr.
Move t__Chr-Asc to w_Ascii.

To obtain the character for an Ascii value, move the value to the field and read the structure:

Move 65 to t__chr-Asc.
Move t__Chr to w_Chr.

This can be wrapped up in a procedure:

* Procedure: AscChar
* Purpose: Ascii(C$) or Chr$(N)
* Entry: Character to return Ascii code for
* Or Number to return character for
* Exit: Opposite of above
* Called By: Perform AscChar using 98 changing w_char
* Perform AscChar using 'A' changing w_num.
* Calls:
* Modification History:
* Date Reason Version Who
Form AscChar Using pu_in changing pc_out.
Data: Begin of t__chr, "ASCII/CHR Converter
asc type x,
End of t__chr,
w__chr(5) type c,
w__num type i,
w__len type i,
w__type(1) type c.
* If pu_in is a character, return the ascii value, if it's
* a value return the character.
Move 0 to pc_out.
Describe field pu_in type w__type.
Case w__type.
When 'C'.
Move pu_in to w__chr.
Compute w__len = strlen( w__chr ).
Move w__chr to t__chr.
Move t__chr-asc to pc_out.
When Others.
Move pu_in to w__num.
If w__num > 0
and w__num < 256.
Move w__num to t__chr-asc.
Move t__chr to pc_out.

How does this work ??

This works (not only in ABAP but in other languages that allow structures such as Cobol etc) by utilising default behaviour within the compiler.

When you use a field (such as t__chr-Asc), the compiler knows what the data type is, because you have defined it as a specific data type.

On the other hand, a structure is a collection of fields, and these fields can be of many different types, including other structures.

So, if I say to the compiler:

Write :/ t__Chr-Asc.

It knows exactly how to deal with the value and display it in a sensible form.

But what of a structure ?? What basic type does that conform to ?

The nearest type is a string, and infact this is exactly what the compiler does. When you ask it to display a structure it just displays it as string.

The same applies to moves. When you assign t__Chr-Asc to a variable the compiler knows exactly what type of variable it is, but with a structure it can't tell what type it is because it could be a combination of types and therefore returns a string.

Unfortunately this does not work with Unicode programs.... Watch out for the update.
Show Knowledge Corner Article