Все немного сложнее, чем простые ответы, данные до сих пор.
Есть 2 аспекта: машина и хранилище.
На машине:
Это зависит от аппаратной архитектуры.
На ПК адресация является байтовой, и вы можете получить доступ к байту (8 битов), слову (16 битов), двойному слову (32 бита) и четырем словам (64 бита).
На других архитектурах у вас может быть доступ только к некоторому "большому размеру" "блоба" для машинного типа данных. Например, на TMS320C40 вы можете получить доступ к 32-битным словам, и 8-битные байты упакованы в эти слова. Вы можете упаковать байты в и из, но это довольно медленный процесс, требующий нескольких машинных инструкций.
Итак, на этом TMS320C40 компилятор C имеет собственный тип char, который является 32-битным!
(при программировании на C никогда не предполагайте, что char равен 8 битам. Прочитайте руководство по компилятору, особенно если вы занимаетесь встроенным программированием).
Ситуация становится еще более сложной, когда в игру вступает порядок байтов, есть 2 общих порядка: байты с младшим и старшим порядком, это описывает, как байты располагаются так, чтобы вписываться в большее количество (обычно это машинный размер слова). Так, например, на 32-битной машине вы можете найти байты, расположенные так:
Адрес X: Байт 0, Байт 1, Байт 2, Байт 3
Адрес X+4: Байт 4, Байт 5, Байт 6, Байт 7
ИЛИ ЖЕ
Адрес X: Байт 3, Байт 2, Байт 1, Байт 0
Адрес X+4: Байт 7, Байт 6, Байт 5, Байт 4
(И это становится еще более сложным, потому что биты в байте также имеют порядок байтов).
Чаще всего такого рода вещи вызывают беспокойство у разработчиков аппаратного обеспечения. Но если вам приходится писать драйверы устройств и другие вещи, которые взаимодействуют с аппаратным обеспечением через регистры с отображением памяти, это становится большой проблемой.
Простого примера может быть достаточно:
Дамп блока памяти по адресу X может представлять поток байтов:
01 02 03 04 05 06 07 08
НО дамп того же блока с того же адреса и представленный как 16-битные (шестнадцатеричные) целые числа может выглядеть как:
0201 0403 0605 0807
И дамп снова с того же адреса, что и 32-битные целые числа в шестнадцатеричном формате, может выглядеть как
04030201 08070605
Это вызывает огромную путаницу у непосвященных, потому что все зависит от порядка байтов и метода (порядка байтов), используемого для создания больших количеств из меньших.
Обычно языки высокого уровня скрывают этот уровень ужасности, но это может быть важно для таких вещей, как наложение структур данных и, опять же, регистры управления отображенного в памяти устройства.
Массовое хранение.
К счастью, здесь жизнь становится легче.
Просто представьте, что ваше хранилище данных - это огромная куча байтов, к которым можно получить доступ, и машина волшебным образом позаботится обо всем этом. Общий термин, используемый для обозначения файлов, - это "поток", где вы начинаете с самого начала, и поток начинает действовать. (Это удобно игнорирует произвольный доступ.) Наименьшая часть, на которую можно разбить поток файла, - это байт.
Если машина хочет хранить большие объемы (16-битные слова и т.д.), То она может или не может выполнить какой-либо уровень преобразования, чтобы передать его в байты, которые поступают в хранилище.
Предостережения.
Все вышеперечисленное относится к базовым вещам низкого уровня - байты, слова и так далее.
Программы используют это разными способами. Так, например, вы получите CHARACTERS, представленные байтами, если они удачно вписываются в простой ASCII (или даже EBCDIC для тех, у кого длинные воспоминания). Современные системы символов Unicode могут использовать широкие символы (обычно это 16 бит), но существует множество систем кодирования для Unicode. Страница Wikipedia на Unicode довольно поучительна.
В эти дни принято считать, что CHARACTER = BYTE вводит в заблуждение и вводит в заблуждение. Лучше всего использовать слово "char" как синоним "byte" - если только ваш компьютер / компилятор не скажет иначе (см. Выше). Программы GOOD C обычно определяют набор предпочтительных типов, таких как "UINT8" - 8-разрядное целое число без знака, "SINT8" - 8-разрядное целое число со знаком и т.д., Так что написанная программа становится настолько независимой, насколько это разумно возможно, от особенностей конкретный компилятор и базовое оборудование.
На конкретный вопрос: как хранятся символы? Ответ: это зависит. Часто символы ascii, которые помещаются в байт, сохраняются как байт. Широкие символы часто хранятся в виде 16-битных слов. Но Юникод может реализовывать широкие символы или одну из любого числа систем кодирования, и в этом случае символы могут занимать от 1 до 4 байтов, в зависимости от символа.
