0
\$\begingroup\$

I'm no cs student, I'm a programmer. I have a couple of questions and a few assumptions that I will make here (correct me if I'm wrong please).

From my understanding is that all the sequences of 1 and 0's that computers execute are just representations of actual data or instructions that tell other hardware on a system what to do like telling a graphic card to change a pixels color on the monitor.

01100001 being the representation of the letter "a" and that this sequence of bits has been chosen by the fathers of computing/ascii or what have you to represent that letter, it could just as well have been some other sequence right?

All computer systems have agreed that those bits mean the letter "a" for all of the computers around the globe to be interoperable, if there were no standards in place for this the internet would be a mess.

What I want to know is: where is the information stored on a computer that tells it that these sequences of bits here mean/represent the character "a"? Is it in the OS or directly on the motherboard or am I just completely wrong?

\$\endgroup\$
  • \$\begingroup\$ It's called a character set. \$\endgroup\$ – Andy aka Sep 5 '15 at 9:27
  • \$\begingroup\$ I know what character sets are but that is not getting to the point. Each time that the sequence of bits for the letter a is received by a computer how does the graphic card know to form the symbol "a" on the screen by changing the color of some pixels on the screen. Where does that information come from? It certainly is not contained within 01100001 alone. \$\endgroup\$ – Larry Lawless Sep 5 '15 at 9:35
  • 1
    \$\begingroup\$ At one level the answer is just "in memory". You could regard "01100001" as a number' 0x61 or 97, and look up the 97th slot in the font table, where you would see a picture (bitmap) of the letter a for example. Usually a very basic version is stored in the boot rom or BIOS or even the graphics card, for boot messages, and the rest are loaded from disk as the OS boots. \$\endgroup\$ – Brian Drummond Sep 5 '15 at 10:04
  • \$\begingroup\$ Ok thanks! Do you know a good book that I can read up on these sort of things? \$\endgroup\$ – Larry Lawless Sep 5 '15 at 10:08
  • \$\begingroup\$ a computer neither relies on nor cares about the ascii representation of a binary string. it is purely interested in using said binary string. It is us slow inefficient humans that need to at least comprehend what a computer is doing. Same thing with colours... Us humans assign a typeface to a certain binary string \$\endgroup\$ – JonRB Sep 5 '15 at 20:01
2
\$\begingroup\$

Nothing tells 01100001 (61h) is an ASCII binary representation of letter 'a'... except the context. In a computer what a sequence of bits such as 01100001 represents depends on where it's found and how the container is structured.

In a file organized in bytes, you'll mostly find alphabetic characters represented in a continuous flow of 8-bit characters in text files, for instance. Now whether 01100001 represents the letter "a" depends on what standard the containing text file conforms to; "a" is represented 61h in ASCII and 81h in EBCDIC, to name only two.

This is a simplistic explanation as there's also page codes, which were invented because 256 positions is not enough to represent international alphabets. For text files, operating systems have character encodings, each of which defines how (and what) characters are translated into what binary representation.

ASCII is one of them and uses only 256 positions for [some of] English alphabetic and non alphabetic, numbers, [a limited set of] punctuation and [non printable] control characters. ISO-8859-1 is a variant of ASCII which accounts for several European accented characters. UTF-8, another one of them defines a variable-length byte representation to account for the representation of most characters in all languages.

On a UNIX system like GNU/Linux, what character encoding a text file follows is shown by its MIME type. See GNU/Linux command file -i

# file -i dead.letter
dead.letter:          text/plain; charset=us-ascii

This shows file dead.letter is a text file that uses ASCII for its content. In such file types 01100001 (61h) represents the letter "a". The MIME type of a text file is determined (read: set) automatically by the editor that saved the file, depending on the locale (aka regional settings) the editor was started. The MIME type can be saved to disk along with the text file or guessed at run-time from the file content when the file is read. The latter is true especially when reading from GNU operating systems files that were saved in Windows as the latter defines no such thing as MIME types.

Again, this is a summarized explanation but that's the base.

\$\endgroup\$
  • \$\begingroup\$ Ok nice thanks, I'm getting the hang of the idea. Do you know a good book that teaches this? Like an introduction to computers book at the low/core level of what they do and how? I ran that file -i command and I get the same result you got. But us-ascii? I save the file in sublime with utf8 encoding, utf8 is encoding unicode code point why is ascii in that result? \$\endgroup\$ – Larry Lawless Sep 5 '15 at 14:20
  • \$\begingroup\$ If your file contains only (US) ASCII characters then there's nothing that distinguishes it from utf-8 or us-ascii, the latter fits then. Try adding some accents or special characters and you'll see. As for books, the internet is the best I can think of ;-) . \$\endgroup\$ – user59864 Sep 5 '15 at 14:24
1
\$\begingroup\$

Some very old computers had a 'data type field' that specfied how the data bits were to be interpreted, for instance as integer value, floating point value, character data, or instruction(s). To my knowledge no modern computer does this: what a bunch of bits encode for is entirely determined by the program that uses the data. And there is no law that such a program needs to be consistent: one time a bunch of bits can represent a character, next time (for instance when the bits are sent over some communication channel) they are just bits without any meaning.

One level deeper, there is an almost general agreement that characters are represented by their ASCII codes. How those codes were choosen is burried in the pre-computer history, and totally irrelevant to the working of a computer.

The ASCII code is limited in that is doesn't have codes for the accented letters of some european countries, and it has nothong resembling the alphabets used in greece, russia, and the far-easern countries that use ideagraphs. To accomdate those 'letters' codes are used that use 16 or 32 bits for each letter.

\$\endgroup\$
0
\$\begingroup\$

There's no one place to store which character code corresponds to which character.

In the olden days of computing, input and display was done on dedicated peripherals, such as teletypes and terminals. They needed to be able to translate between characters pressed on a keyboard and ASCII codes, and back again for display. The computer didn't have to understand the codes at all. It just stored them, before passing them on to somewhere else.

These days, more of that is integrated into the computer. Even now, though, the computer doesn't really need to "know" that 01100001 is an ASCII code for 'a'. Instead, there will be a look-up table that will translate the key-codes produced by a keyboard into ASCII.

For display, the computer looks up the character code in a font file, and follows the drawing instructions given for that character, in order to draw something on the screen. If the font designers got it right, a human looking at the screen will see the resulting symbol as an 'a'.

Unicode works in just the same way, but using 21-bit characters, instead of the 7-bit characters of ASCII.

\$\endgroup\$
  • \$\begingroup\$ Nice answer with about the font file and screen rendering. I don't think Unicode uses 21bit characters though. It depends on the encoding, unicode defines character code points right and then the most used utf8 char encoding encodes the code points with 8 bits for code points 0 to 127 and starts using 2 bytes or more thereafter for code points other than the first 127 ascii characters \$\endgroup\$ – Larry Lawless Sep 5 '15 at 21:52
  • \$\begingroup\$ Were you talking about 21 bits as in the amount of bits needed to represent all unicode characters like this site states? userguide.icu-project.org/unicode More bits are acutally needed today as the set of chars has grown \$\endgroup\$ – Larry Lawless Sep 5 '15 at 22:11
  • \$\begingroup\$ It looks like they may have tacked a few more code points on. The range of character codes is quoted in the latest standard as 0 to 10FFFF (hex). I guess that's now 25 bits. \$\endgroup\$ – Simon B Sep 6 '15 at 22:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.