Представление символов, таблицы кодировок
В вычислительных машинах символы не могут храниться иначе, как в виде последовательностей бит (как и числа). Для передачи символа и его корректного отображения ему должна соответствовать уникальная последовательность нулей и единиц. Для этого были разработаны таблицы кодировок.
Количество символов, которые можно задать последовательностью бит длины [math]n[/math] , задается простой формулой [math]C(n) = 2^n[/math] . Таким образом, от нужного количества символов напрямую зависит количество используемой памяти.
Таблицы кодировок
На заре компьютерной эры на каждый символ было отведено по пять бит. Это было связано с малым количеством оперативной памяти на компьютерах тех лет. В эти [math]32[/math] символа входили только управляющие символы и строчные буквы английского алфавита.
С ростом производительности компьютеров стали появляться таблицы кодировок с большим количеством символов. Первой семибитной кодировкой стала ASCII7. В нее уже вошли прописные буквы английского алфавита, арабские цифры, знаки препинания. Затем на ее базе была разработана ASCII8, в которым уже стало возможным хранение [math]256[/math] символов: [math]128[/math] основных и еще столько же расширенных. Первая часть таблицы осталась без изменений, а вторая может иметь различные варианты (каждый имеет свой номер). Эта часть таблицы стала заполняться символами национальных алфавитов.
Но для многих языков (например, арабского, японского, китайского) [math]256[/math] символов недостаточно, поэтому развитие кодировок продолжалось, что привело к появлению UNICODE.
Кодировки стандарта ASCII
| Определение: |
| ASCII — таблицы кодировок, в которых содержатся основные символы (английский алфавит, цифры, знаки препинания, символы национальных алфавитов(свои для каждого региона), служебные символы) и длина кода каждого символа [math]n = 8[/math] бит. |
- ASCII7 — первая кодировка, пригодная для работы с текстом. Помимо маленьких букв английского алфавита и служебных символов, содержит большие буквы английского языка, цифры, знаки препинания и другие символы.
Кодировки стандарта ASCII ( [math]8[/math] бит):
- ASCII — первая кодировка, в которой стало возможно использовать символы национальных алфавитов.
- КОИ8-R — первая русская кодировка. Символы кириллицы расположены не в алфавитном порядке. Их разместили в верхнюю половину таблицы так, чтобы позиции кириллических символов соответствовали их фонетическим аналогам в английском алфавите. Это значит, что даже при потере старшего бита каждого символа, например, при проходе через устаревший семибитный модем, текст остается «читаемым».
- CP866 — русская кодировка, использовавшаяся на компьютерах IBM в системе DOS.
- Windows-1251 — русская кодировка, использовавшаяся в русскоязычных версиях операционной системы Windows в начале 90-х годов. Кириллические символы идут в алфавитном порядке. Содержит все символы, встречающиеся в типографике обычного текста (кроме знака ударения).
Структурные свойства таблицы
Кодировки стандарта UNICODE
Юникод или Уникод (англ. Unicode) — это промышленный стандарт обеспечивающий цифровое представление символов всех письменностей мира, и специальных символов.
Стандарт предложен в 1991 году некоммерческой организацией «Консорциум Юникода» (англ. Unicode Consortium, Unicode Inc.). Применение этого стандарта позволяет закодировать очень большое число символов из разных письменностей. Стандарт состоит из двух основных разделов: универсальный набор символов (англ. UCS, universal character set) и семейство кодировок (англ. UTF, Unicode transformation format). Универсальный набор символов задаёт однозначное соответствие символов кодам — элементам кодового пространства, представляющим неотрицательные целые числа.Семейство кодировок определяет машинное представление последовательности кодов UCS.
Коды в стандарте Unicode разделены на несколько областей. Область с кодами от U+0000 до U+007F содержит символы набора ASCII с соответствующими кодами. Далее расположены области знаков различных письменностей, знаки пунктуации и технические символы. Под символы кириллицы выделены области знаков с кодами от U+0400 до U+052F, от U+2DE0 до U+2DFF, от U+A640 до U+A69F. Часть кодов зарезервирована для использования в будущем.
Кодовое пространство
Хотя формы записи UTF-8 и UTF-32 позволяют кодировать до [math]2^[/math] [math](2\ 147\ 483\ 648)[/math] кодовых позиций, было принято решение использовать лишь [math]1\ 112\ 064[/math] для совместимости с UTF-16. Впрочем, даже и этого на текущий момент более чем достаточно — в версии 6.0 используется чуть менее [math]110\ 000[/math] кодовых позиций ( [math]109\ 242[/math] графических и [math]273[/math] прочих символов).
Кодовое пространство разбито на [math]17[/math] плоскостей (англ. planes) по [math]2^[/math] [math](65\ 536)[/math] символов. Нулевая плоскость называется базовой, в ней расположены символы наиболее употребительных письменностей. Первая плоскость используется, в основном, для исторических письменностей, вторая — для для редко используемых иероглифов китайского письма, третья зарезервирована для архаичных китайских иероглифов. Плоскости [math]15[/math] и [math]16[/math] выделены для частного употребления.
Для обозначения символов Unicode используется запись вида «U+xxxx» (для кодов [math]0000_..FFFF_[/math] ) или «U+xxxxx» (для кодов [math]10000_..FFFFF_[/math] ) или «U+xxxxxx» (для кодов [math]100000_..10FFFF_[/math] ), где xxx — шестнадцатеричные цифры. Например, символ «я» (U+044F) имеет код [math]044F_ = 1103_[/math] .
| Плоскости Юникода | ||
|---|---|---|
| Плоскость | Название | Диапазон символов |
| Plane 0 | Basic multilingual plane (BMP) | U+0000…U+FFFF |
| Plane 1 | Supplementary multilingual plane (SMP) | U+10000…U+1FFFF |
| Plane 2 | Supplementary ideographic plane (SIP) | U+20000…U+2FFFF |
| Planes 3-13 | Unassigned | U+30000…U+DFFFF |
| Plane 14 | Supplementary special-purpose plane (SSP) | U+E0000…U+EFFFF |
| Planes 15-16 | Supplementary private use area (S PUA A/B) | U+F0000…U+10FFFF |
Модифицирующие символы
Графические символы в Юникоде делятся на протяжённые и непротяжённые. Непротяжённые символы при отображении не занимают дополнительного места в строке. К примеру, к ним относятся знак ударения. Протяжённые и непротяжённые символы имеют собственные коды, но последние не могут встречаться самостоятельно. Протяжённые символы называются базовыми (англ. base characters), а непротяженные — модифицирующими (англ. combining characters). Например символ «Й» (U+0419) может быть представлен в виде базового символа «И» (U+0418) и модифицирующего символа « ̆» (U+0306).
Способы представления
Юникод имеет несколько форм представления (англ. Unicode Transformation Format, UTF): UTF-8, UTF-16 (UTF-16BE, UTF-16LE) и UTF-32 (UTF-32BE, UTF-32LE). Была разработана также форма представления UTF-7 для передачи по семибитным каналам, но из-за несовместимости с ASCII она не получила распространения и не включена в стандарт.
UTF-8
UTF-8 — представление Юникода, обеспечивающее наилучшую совместимость со старыми системами, использовавшими [math]8[/math] -битные символы. Текст, состоящий только из символов с номером меньше [math]128[/math] , при записи в UTF-8 превращается в обычный текст ASCII. И наоборот, в тексте UTF-8 любой байт со значением меньше [math]128[/math] изображает символ ASCII с тем же кодом. Остальные символы Юникода изображаются последовательностями длиной от двух до шести байт (на деле, только до четырех байт, поскольку в Юникоде нет символов с кодом больше [math]10FFFF_[/math] , и вводить их в будущем не планируется), в которых первый байт всегда имеет вид [math]11xxxxxx[/math] , а остальные — [math]10xxxxxx[/math] .
Символы UTF-8 получаются из Unicode cледующим образом:
| Unicode | UTF-8 | Представленные символы |
|---|---|---|
| 0x00000000 — 0x0000007F | 0xxxxxxx | ASCII, в том числе английский алфавит, простейшие знаки препинания и арабские цифры |
| 0x00000080 — 0x000007FF | 110xxxxx 10xxxxxx | кириллица, расширенная латиница, арабский алфавит, армянский алфавит, греческий алфавит, еврейский алфавит и коптский алфавит; сирийское письмо, тана, нко; Международный фонетический алфавит; некоторые знаки препинания |
| 0x00000800 — 0x0000FFFF | 1110xxxx 10xxxxxx 10xxxxxx | все другие современные формы письменности, в том числе грузинский алфавит, индийское, китайское, корейское и японское письмо; сложные знаки препинания; математические и другие специальные символы |
| 0x00010000 — 0x001FFFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx | музыкальные символы, редкие китайские иероглифы, вымершие формы письменности |
| 111111xx | служебные символы c, d, e, f |
Несмотря на то, что UTF-8 позволяет указать один и тот же символ несколькими способами, только наиболее короткий из них правильный. Остальные формы, называемые overlong sequence, отвергаются по соображениям безопасности.
Принцип кодирования
Правила записи кода одного символа в UTF-8
1. Если размер символа в кодировке UTF-8 = [math]1[/math] байт
Код имеет вид (0aaa aaaa), где «0» — просто ноль, остальные биты «a» — это код символа в кодировке ASCII;
2. Если размер символа в кодировке в UTF-8 [math]\gt 1[/math] байт (то есть от [math]2[/math] до [math]6[/math] ):
2.1 Первый байт содержит количество байт символа, закодированное в единичной системе счисления;
2 — 11 3 — 111 4 — 1111 5 — 1111 1 6 — 1111 11
2.2 «0» — бит терминатор, означающий завершение кода размера 2.3 далее идут значащие байты кода, которые имеют вид (10xx xxxx), где «10» — биты признака продолжения, а «x» — значащие биты.
В общем случае варианты представления одного символа в кодировке UTF-8 выглядят так:
(1 байт) 0aaa aaaa (2 байта) 110x xxxx 10xx xxxx (3 байта) 1110 xxxx 10xx xxxx 10xx xxxx (4 байта) 1111 0xxx 10xx xxxx 10xx xxxx 10xx xxxx (5 байт) 1111 10xx 10xx xxxx 10xx xxxx 10xx xxxx 10xx xxxx (6 байт) 1111 110x 10xx xxxx 10xx xxxx 10xx xxxx 10xx xxxx 10xx xxxx
Определение длины кода в UTF-8
| Количество байт UTF-8 | Количество значащих бит |
|---|---|
| [math]1[/math] | [math]7[/math] |
| [math]2[/math] | [math]11[/math] |
| [math]3[/math] | [math]16[/math] |
| [math]4[/math] | [math]21[/math] |
| [math]5[/math] | [math]26[/math] |
| [math]6[/math] | [math]31[/math] |
В общем случае количество значащих бит [math]C[/math] , кодируемых [math]n[/math] байтами UTF-8, определяется по формуле:
[math]C = 7[/math] при [math]n=1[/math]
[math]C = n\cdot5+1[/math] при [math]n\gt 1[/math]
UTF-16
UTF-16 — один из способов кодирования символов (англ. code point) из Unicode в виде последовательности [math]16[/math] -битных слов (англ. code unit). Данная кодировка позволяет записывать символы Юникода в диапазонах U+0000..U+D7FF и U+E000..U+10FFFF (общим количеством [math]1\ 112\ 064[/math] ), причем [math]2[/math] -байтные символы представляются как есть, а более длинные — с помощью суррогатных пар (англ. surrogate pair), для которых и вырезан диапазон [math]D800_..DFFF_[/math] .
В UTF-16 символы кодируются двухбайтовыми словами с использованием всех возможных диапазонов значений (от [math]0000_[/math] до [math]FFFF_[/math] ). При этом можно кодировать символы Unicode в диапазонах [math]0000_..D7FF_[/math] и [math]E000_..10FFFF_[/math] . Исключенный отсюда диапазон [math]D800_..DFFF_[/math] используется как раз для кодирования так называемых суррогатных пар — символов, которые кодируются двумя [math]16[/math] -битными словами. Символы Unicode до [math]FFFF_[/math] включительно (исключая диапазон для суррогатов) записываются как есть [math]16[/math] -битным словом. Символы же в диапазоне [math]10000_..10FFFF_[/math] (больше [math]16[/math] бит) уже кодируются парой [math]16[/math] -битных слов. Для этого их код арифметически сдвигается до нуля (из него вычитается минимальное число [math]10000_[/math] ). В результате получится значение от нуля до [math]FFFFF_[/math] , которое занимает до [math]20[/math] бит. Старшие [math]10[/math] бит этого значения идут в лидирующее (первое) слово, а младшие [math]10[/math] бит — в последующее (второе). При этом в обоих словах старшие [math]6[/math] бит используются для обозначения суррогата. Биты с [math]11[/math] по [math]15[/math] имеют значения [math]11011_2[/math] , а [math]10[/math] -й бит содержит [math]0[/math] у лидирующего слова и [math]1[/math] — у последующего. В связи с этим можно легко определить к чему относится каждое слово.
UTF-16LE и UTF-16BE
Один символ кодировки UTF-16 представлен последовательностью двух байт или двух пар байт. Который из двух байт в словах идёт впереди, старший или младший, зависит от порядка байт. Подробнее об этом будет сказано ниже.
UTF-32
UTF-32 — один из способов кодирования символов из Юникод, использующий для кодирования любого символа ровно [math]32[/math] бита. Остальные кодировки, UTF-8 и UTF-16, используют для представления символов переменное число байт. Символ UTF-32 является прямым представлением его кодовой позиции (англ. code point).
Главное преимущество UTF-32 перед кодировками переменной длины заключается в том, что символы Юникод непосредственно индексируемы. Получение [math]n[/math] -ой кодовой позиции является операцией, занимающей одинаковое время. Напротив, коды с переменной длиной требует последовательного доступа к [math]n[/math] -ой кодовой позиции. Это делает замену символов в строках UTF-32 простой, для этого используется целое число в качестве индекса, как обычно делается для строк ASCII.
Главный недостаток UTF-32 — это неэффективное использование пространства, так как для хранения символа используется четыре байта. Символы, лежащие за пределами нулевой (базовой) плоскости кодового пространства редко используются в большинстве текстов. Поэтому удвоение, в сравнении с UTF-16, занимаемого строками в UTF-32 пространства не оправдано.
Хотя использование неменяющегося числа байт на символ удобно, но не настолько, как кажется. Операция усечения строк реализуется легче в сравнении с UTF-8 и UTF-16. Но это не делает более быстрым нахождение конкретного смещения в строке, так как смещение может вычисляться и для кодировок фиксированного размера. Это не облегчает вычисление отображаемой ширины строки, за исключением ограниченного числа случаев, так как даже символ «фиксированной ширины» может быть получен комбинированием обычного символа с модифицирующим, который не имеет ширины. Например, буква «й» может быть получена из буквы «и» и диакритического знака «крючок над буквой». Сочетание таких знаков означает, что текстовые редакторы не могут рассматривать [math]32[/math] -битный код как единицу редактирования. Редакторы, которые ограничиваются работой с языками с письмом слева направо и составными символами (англ. Precomposed character), могут использовать символы фиксированного размера. Но такие редакторы вряд ли поддержат символы, лежащие за пределами нулевой (базовой) плоскости кодового пространства и вряд ли смогут работать одинаково хорошо с символами UTF-16.
Порядок байт
В современной вычислительной технике и цифровых системах связи информация обычно представлена в виде последовательности байт. В том случае, если число не может быть представлено одним байтом, имеет значение в каком порядке байты записываются в памяти компьютера или передаются по линиям связи. Часто выбор порядка записи байт произволен и определяется только соглашениями.
В общем случае, для представления числа [math]M[/math] , большего [math]255[/math] (здесь [math]255=2^8-1[/math] — максимальное целое число, записываемое одним байтом), приходится использовать несколько байт. При этом число [math]M[/math] записывается в позиционной системе счисления по основанию [math]256[/math] :
[math]M = \sum_^A_i\cdot 256^i=A_0\cdot 256^0+A_1\cdot 256^1+A_2\cdot 256^2+\dots+A_n\cdot 256^n.[/math]
Набор целых чисел [math]A_0,\dots,A_n[/math] , каждое из которых лежит в интервале от [math]0[/math] до [math]255[/math] , является последовательностью байт, составляющих [math]M[/math] . При этом [math]A_0[/math] называется младшим байтом, а [math]A_n[/math] — старшим байтом числа [math]M[/math] .
Варианты записи
Порядок от старшего к младшему
Порядок от старшего к младшему (англ. big-endian): [math]A_n,\dots,A_0[/math] , запись начинается со старшего и заканчивается младшим. Этот порядок является стандартным для протоколов TCP/IP, он используется в заголовках пакетов данных и во многих протоколах более высокого уровня, разработанных для использования поверх TCP/IP. Поэтому, порядок байт от старшего к младшему часто называют сетевым порядком байт (англ. network byte order). Этот порядок байт используется процессорами IBM 360/370/390, Motorola 68000, SPARC (отсюда третье название — порядок байт Motorola, Motorola byte order).
В этом же виде (используя представление в десятичной системе счисления) записываются числа индийско-арабскими цифрами в письменностях с порядком знаков слева направо (латиница, кириллица). Для письменностей с обратным порядком (арабская) та же запись числа воспринимается как «от младшего к старшему».
Порядок байт от старшего к младшему применяется во многих форматах файлов — например, PNG, FLV, EBML.
Порядок от младшего к старшему
Порядок от младшего к старшему (англ. little-endian): [math]A_0,\dots,A_n[/math] , запись начинается с младшего и заканчивается старшим. Этот порядок записи принят в памяти персональных компьютеров с x86-процессорами, в связи с чем иногда его называют интеловский порядок байт (по названию фирмы-создателя архитектуры x86).
В противоположность порядку big-endian, соглашение little-endian поддерживают меньше кросс-платформенных протоколов и форматов данных; существенные исключения: USB, конфигурация PCI, таблица разделов GUID, рекомендации FidoNet.
Переключаемый порядок
Многие процессоры могут работать и в порядке от младшего к старшему, и в обратном, например, ARM, PowerPC (но не PowerPC 970), DEC Alpha, MIPS, PA-RISC и IA-64. Обычно порядок байт выбирается программно во время инициализации операционной системы, но может быть выбран и аппаратно перемычками на материнской плате. В этом случае правильнее говорить о порядке байт операционной системы. Переключаемый порядок байт иногда называют англ. bi-endian.
Смешанный порядок
Смешанный порядок байт (англ. middle-endian) иногда используется при работе с числами, длина которых превышает машинное слово. Число представляется последовательностью машинных слов, которые записываются в формате, естественном для данной архитектуры, но сами слова следуют в обратном порядке.
Классический пример middle-endian — представление [math]4[/math] -байтных целых чисел на [math]16[/math] -битных процессорах семейства PDP-11 (известен как PDP-endian). Для представления двухбайтных значений (слов) использовался порядок little-endian, но [math]4[/math] -хбайтное двойное слово записывалось от старшего слова к младшему.
В процессорах VAX и ARM используется смешанное представление для длинных вещественных чисел.
Различия
Существенным достоинством little-endian по сравнению с big-endian порядком записи считается возможность «неявной типизации» целых чисел при чтении меньшего объёма байт (при условии, что читаемое число помещается в диапазон). Так, если в ячейке памяти содержится число [math]00000022_[/math] , то прочитав его как int16 (два байта) мы получим число [math]0022_[/math] , прочитав один байт — число [math]22_[/math] . Однако, это же может считаться и недостатком, потому что провоцирует ошибки потери данных.
Обратно, считается что у little-endian, по сравнению с big-endian есть «неочевидность» значения байт памяти при отладке (последовательность байт (A1, B2, C3, D4) на самом деле значит [math]D4C3B2A1_[/math] , для big-endian эта последовательность (A1, B2, C3, D4) читалась бы «естественным» для арабской записи чисел образом: [math]A1B2C3D4_[/math] ). Наименее удобным в работе считается middle-endian формат записи; он сохранился только на старых платформах.
Для записи длинных чисел (чисел, длина которых существенно превышает разрядность машины) обычно предпочтительнее порядок слов в числе little-endian (поскольку арифметические операции над длинными числами производятся от младших разрядов к старшим). Порядок байт в слове — обычный для данной архитектуры.
Маркер последовательности байт
Для определения формата представления Юникода в начало текстового файла записывается сигнатура — символ U+FEFF (неразрывный пробел с нулевой шириной), также именуемый маркером последовательности байт (англ. byte order mark (BOM)). Это позволяет различать UTF-16LE и UTF-16BE, поскольку символа U+FFFE не существует.
| Кодирование | Представление (Шестнадцатеричное) |
|---|---|
| UTF-8 | EF BB BF |
| UTF-16 (BE) | FE FF |
| UTF-16 (LE) | FF FE |
| UTF-32 (BE) | 00 00 FE FF |
| UTF-32 (LE) | FF FE 00 00 |
В кодировке UTF-8, наличие BOM не является существенным, поскольку, нет альтернативной последовательности байт. Когда BOM используется на страницах или редакторах для контента закодированного в UTF-8, иногда он может представить пробелы или короткие последовательности символов, имеющие странный вид (такие как ). Именно поэтому, при наличии выбора, для совместимости, как правило, лучше упустить BOM в UTF-8 контенте.Однако BOM могут еще встречаться в тексте закодированном в UTF-8, как побочный продукт перекодирования или потому, что он был добавлен редактором. В этом случае BOM часто называют подписью UTF-8.
Когда символ закодирован в UTF-16, его [math]2[/math] или [math]4[/math] байта можно упорядочить двумя разными способами (little-endian или big-endian). Изображение справа показывает это. Byte order mark указывает, какой порядок используется, так что приложения могут немедленно расшифровать контент. UTF-16 контент должен всегда начинатся с BOM.
BOM также используется для текста обозначенного как UTF-32. Аналогично UTF-16 существует два варианта четырёхбайтной кодировки — UTF-32BE и UTF-32LE. К сожалению, этот способ не позволяет надёжно различать UTF-16LE и UTF-32LE, поскольку символ U+0000 допускается Юникодом
Проблемы Юникода
В Юникоде английское «a» и польское «a» — один и тот же символ. Точно так же одним символом (но отличающимся от «a» латинского) считаются русское «а» и сербское «а». Такой принцип кодирования не универсален; по-видимому, решения «на все случаи жизни» вообще не может существовать.
Примеры
Если записать строку ‘hello мир’ в файл exampleBOM, а затем сделать его hex-дамп, то можно убедиться в том, что разные символы кодируются разным количеством байт. Например, английские буквы,пробел, знаки препинания и пр. кодируются одним байтом, а русские буквы — двумя
Код на python
#!/usr/bin/env python #coding:utf-8 import codecs f = open('exampleBOM','w') b = u'hello мир' f.write(codecs.BOM_UTF8) f.write(b.encode('utf-8')) f.close()
hex-дамп файла exampleBOM
| Символ | BOM | h | e | l | l | o | Пробел | м | и | р | |||||
| Код в UNICODE | EF | BB | BF | 68 | 65 | 6C | 6C | 6F | 20 | D0 | BC | D0 | B8 | D1 | 80 |
| Код в UTF-8 | 11101111 | 10111011 | 10111111 | 01101000 | 01100101 | 01101100 | 01101100 | 01101111 | 00100000 | 11010000 | 10111100 | 11010000 | 10111000 | 11010001 | 10000000 |
См. также
- Представление целых чисел: прямой код, код со сдвигом, дополнительный код
- Представление вещественных чисел
Источники информации
- Wikipedia — таблица ASCII
- Wikipedia — стандарт UNICODE
- Wikipedia — Byte order mark
- Wikipedia — Порядок байтов
- Wikipedia — Юникод
- Wikipedia — Windows-1251
- Wikipedia — UTF-8
- Wikipedia — UTF-16
- Wikipedia — UTF-32
Размер файла — штука вовсе не однозначная. Давайте посмотрим, как он может меняться.
Прежде всего скажем, что речь здесь пойдет о файловых системах FAT и NTFS, как наиболее распространенных, и ничего не будет сказано о файловых системах, используемых в не-Windows системах, поскольку такие системы лежат вне сферы интересов автора. А теперь – к делу.
Казалось бы, какая неоднозначность может быть, если говорить о размере файла. Сколько в него данных записали, такой и размер (или длина). Сколько в нем есть байтов от начала до конца (и это число записано в файловой системе в качестве размера файла), такой и размер, не так ли? Как говорил Шельменко-денщик, так то оно так, да только трошечки не так.
Проведите эксперимент. Возьмите любой исполняемый файл и выполните его копирование командой
copy что-то.exe что-то-другое.exe
Если вы раньше с этим сталкивались, то уже знаете, что результирующий файл получится намного короче исходного и не будет копией. Причина простая: программа copy, запущенная без параметра /b, копирует файл до тех пор, пока не встретит байт с кодом 27h, этот символ называется «конец файла».
Итак, у нас уже есть два разных признака конца файла – по числу, записанному в файловой системе, и по специальному байту в теле файла. Правда, стоит отметить, что второй признак остался с тех времен, когда файлы были преимущественно текстовыми и сейчас практически не применяется.
В файловых системах, использующих кластеры, а FAT и NTFS относятся именно к таким ФС, есть еще третий размер – размер файла на диске, то есть суммарный размер кластеров, отведенных этому файлу. В файловых системах FAT этот размер больше размера собственно файла или равен ему. Разница между размерами, если она есть, – так называемый хвост файла – это напрасно пропадающее место на диске, плата за размещение файлов по кластерам, а не встык друг за другом, хотя файловые системы с таким размещением файлов тоже существуют.
Впрочем, иногда это место используется. В частности, во времена дискет существовали программы, которые позволяли записывать данные в хвосты файлов, чтобы скрытно передать на таких дискетах информацию. Ведь стандартными средствами получить доступ к хвостам файлов нельзя.
Если включить в рассмотрение NTFS, то картина дополнится новыми штрихами.
Прежде всего, размер файла на диске может оказаться меньше собственно размера файла.
Если тело файла помещается в свободную область файловой записи MFT, то этот файл не занимает на диске ни одного кластера.
Максимальный размер такого файла зависит от размера записи и составляет примерно 600 байтов для записи мелкого размера (1 Кб) и 3600 – для записи крупного размера (4 Кб). Следует, впрочем, отметить, что до недавнего времени Windows показывала размер такого файла на диске равным одному кластеру, хотя фактически ни одного кластера файлу не выделено.
Если файл сжат, то его размер на диске может быть заметно меньше собственно длины файла (количества данных в нем). 
Дополнительно усложняют картину так называемые разреженные файлы. В них полезные данные содержаться только в определенных участках файла, а остальная часть файла не используется вовсе. Возьмем в качестве примера файл журнала изменений \$Extend\$UsnJrnl, имеющийся почти на каждом компьютере (не пытайтесь увидеть его в проводнике или других диспетчерах файлов, не получится). 
Он может иметь длину несколько гигабайт, но значимых данных содержит при этом обычно только 32 мегабайта в самом конце. А остальная часть вообще никаких данных не содержит, места на диске не занимает, и при попытке прочитать данные из этой части система выдаст набор нулей, даже не обращаясь к диску.
Если у читателя возникнет желание поэкспериментировать с разреженными файлами, такой файл можно создать с помощью команды fsutil sparse. А на досуге можно обдумать, какова же настоящая длина файла, если система записала в соответствующую графу число 4 Гб, а реальных данных в файле только 32 Мб и на диске он занимает тоже 32 Мб.
И, наконец, расскажем еще об одной длине: длине действительных данных (valid data). Эта длина и устанавливающие ее функции представляют интерес почти исключительно для программистов, тем не менее изредка с ней могут столкнуться и обычные пользователи.
В файловых системах FAT такого понятия не существует, и функции, которые используют эту величину, записывают в тело файла на соответствующих местах нули. В NTFS эта длина является характеристикой файла.
Попробуем пояснить, о чем идет речь, на примере. Возьмите флешку (флешка используется для наглядности, поскольку она медленнее жесткого диска работает с большими объемами данных) размером от гигабайта, отформатированную в FAT32, и создайте на ней большой файл командой
fsutil file createnew k:\пробный.txt 900000000
Если буква, присвоенная флешке, отличается от К, то исправьте команду соответствующим образом.
Вы увидите, что процедура создания файла окажется довольно продолжительной, полминуты или даже больше (хотя сообщение «файл создан» появится сразу же, появления приглашения командной строки придется подождать). Это совсем не удивительно, ведь в описании команды (https://technet.microsoft.com/en-us/library/cc788058.aspx) сказано, что создаваемый файл состоит из нулей. А файл у нас получился 858 мегабайт, так что его запись и должна занять не такое уж малое время.
Теперь отформатируйте флешку в NTFS, для чистоты эксперимента лучше взять ту же самую, и повторите создание файла. На этот раз операция пройдет практически моментально. Записывать нули в тело файла уже не надо, достаточно распределить место под файл и установить для него длину действительных данных равной нулю. В теле файла останется «мусор», который был записан в этих секторах, но при чтении данных обращения к этим данным не произойдет – обнаружив, что длина действительных данных равна нулю, все, что дальше этого нуля, система читать не станет – ведь эти данные недействительны. Их можно сделать действительными, если изменить значение длины действительных данных.
Рассмотрим это на примере. Создайте новый файл на одном из рабочих дисков, отформатированном в NTFS. Сотни мегабайт совершенно не обязательны, десятка-другого килобайт будет вполне достаточно:
fsutil file createnew C:\пробный.txt 10000
Теперь откройте его с помощью любого просмотрщика файлов, например FAR.
Как видим, в файле действительно нули. Но если посмотреть на этот файл с помощью какого-либо редактора дисков, обращающегося к секторам напрямую, например dmde, то картина будет другая.
Если мы откроем том С как логическое устройство и посмотрим на содержимое файла, то увидим те же самые нули. 
Но если открыть диск как физическое устройство, то в том же самом секторе (обратите внимание на номера LBA – разница в 63 возникла из-за того, что начало раздела сдвинуто относительно начала диска) увидим данные, которые ранее были записаны в какой-то позже удаленный файл. 
И если мы увеличим длину действительных данных, то увидим эти данные в файле. Установим эту длину равной 300 байт:
fsutil file setvaliddata C:\пробный.txt 300
Обратите внимание что параметр в этой команде нельзя задавать произвольно, но должен быть не меньше текущего значения длины действительных данных и не больше размера файла. Уменьшить длину действительных данных этой командой нельзя.
Теперь снова посмотри на содержимое файла. Заметьте, что никаких данных мы в него не записывали!
Чисто случайно получилось, что в этом файле довольно много осмысленного текста, что делает картину более наглядной. 300 десятичных байтов – это 12c шестнадцатиричных, и как раз на этом байте обрывается текст и начинаются нули. Если сдвинуть границу действительных данных еще дальше, то «проявятся» и следующие строки.
Подведем итоги
Имеется две физических длины файла – это размер файла, записанный в файловой системе и место, занимаемое на диске. Также имеется две логических длины файла – это признак конца файла (байт EOF – 27h) и длина действительных данных. Как составную часть логической длины можно рассматривать и пустые области в разреженных файлах – вспомните \$Extend\$UsnJrnl, где большой массив отсутствующих данных завершается тридцатью двумя мегабайтами действительных.
Итак, обычно, когда говорят о длине файла, имеют в виду число, хранящееся в файловой системе. Но, как видите, возможны варианты!
Двоичная система счисления. Бит и байт. Сегментация памяти.
Вообще, как компьютер может хранить, например, слово «диск»? Главный принцип — намагничивание и размагничивание одной дорожки (назовем ее так). Одна микросхема памяти — это, грубо говоря, огромное количество дорожек. Сейчас попробуем разобраться. Например:
нуль будет обозначаться как 0000 (четыре нуля),
один 0001, два 0010,
(т.е. правую единицу заменяем на 0 и вторую устанавливаем в 1).
три 0011 четыре 0100 пять 0101 шесть 0110 семь 0111 восемь 1000 девять 1001
Уловили принцип? «0» и «1» — это т.н. биты. Один бит, как вы уже заметили, может быть нулем или единицей, т.е. размагничена или намагничена та или иная дорожка («0» и «1» это условное обозначение). Если еще присмотреться, то можно заметить, что каждый следующий установленный бит (начиная справа) увеличивает число в два раза: 0001 в нашем примере = 1; 0010 два; 0100 четыре; 1000 восемь и т.д. Это и есть т.н. двоичная форма представления данных.
Т.о. чтобы обозначить числа от 0 до 9 нам нужно четыре бита (хоть они и не до конца использованы. Можно было бы продолжить: десять 1010, одиннадцать 1011 , пятнадцать 1111).
Компьютер хранит данные в памяти именно так. Для обозначения какого-нибудь символа (цифры, буквы, запятой, точки. ) в компьютере используется определенное количество бит. Компьютер «распознает» 256 (от 0 до 255) различных символов по их коду. Этого достаточно, чтобы вместить все цифры (0 — 9), буквы латинского алфавита (a — z, A — Z), русского (а — я, А — Я), а также другие символы. Для представления символа с максимально возможным кодом (255) нужно 8 бит. Эти 8 бит называются байтом. Т.о. один любой символ — это всегда 1 байт (см. рис. 1).
| 0 | 1 | 0 | 1 | 1 | 0 | 1 | 0 |
| р | н | р | н | н | р | н | р |
Рис. 1. Один байт с кодом буквы Z
(буквы н и р обозначают: намагничено или размагничено соответственно)
Можно элементарно проверить. Создайте в текстовом редакторе файл с любым именем и запишите в нем один символ, например, «М» (но не нажимайте Enter!). Если вы посмотрите его размер, то файл будет равен 1 байту. Если ваш редактор позволяет смотреть файлы в шестнадцатеричном формате, то вы сможете узнать и код сохраненного вами символа. В данном случае буква «М» имеет код 4Dh в шестнадцатеричной системе, которую мы уже знаем или 1001101 в двоичной.
Т.о. слово «диск» будет занимать 4 байта или 4*8 = 32 бита. Как вы уже поняли, компьютер хранит в памяти не сами буквы этого слова, а последовательность «единичек» и «ноликов». «Почему же тогда на экране мы видим текст, а не «единички-нолики»? — спросите вы. Чтобы удовлетворить ваше любопытство, я забегу немного вперед и скажу, что всю работу по выводу самого символа на экран (а не битов) выполняет видеокарта (видеоадаптер), которая находится в вашем компьютере. И если бы ее не было, то мы, естественно, ничего бы не видели, что у нас творится на экране.
В Ассемблере после двоичного числа всегда должна стоять буква «b». Это нужно для того, чтобы при ассемблировании нашей программы Ассемблер смог отличать десятичные, шестнадцатеричные и двоичные числа. Например: 10 — это «десять», 10h — это «шестнадцать» а 10b — это «два» в десятичной системе.
Т.о. в регистры можно загружать двоичные, десятичные и шестнадцатеричные числа.
mov ax,20 mov bh,10100b mov cl,14h
В результате в регистрах AX, BH и CL будет находится одно и тоже число, только загружаем мы его в разных системах. Компьютер же будет хранить его в двоичном формате (как в регистре BH).
Итак, подведем итог. В компьютере вся информация хранится в двоичном формате (двоичной системе) примерно в таком виде: 10101110 10010010 01111010 11100101 (естественно, без пробелов. Для удобства я разделили биты по группам). Восемь бит — это один байт. Один символ занимает один байт, т.е. восемь бит. По-моему, ничего сложного. Очень важно уяснить данную тему, так как мы будем постоянно пользоваться двоичной системой, и вам необходимо знать ее на «отлично».
Как перевести двоичное число в десятичное:
Надо сложить двойки в степенях, соответствующих позициям, где в двоичном стоят единицы. Например:
Возьмем число 20. В двоичной системе оно имеет следующий вид: 10100b
Итак (начнем слева направо, считая от 4 до 0; число в нулевой степени всегда равно единице (вспоминаем школьную программу по математике)):
10100b = 1*24 + 0*23 + 1*22 + 0*21 + 0*20 = 20 --------------------------------------------- 16+0+4+0+0 = 20
Как перевести десятичное число в двоичное:
Можно делить его на два, записывая остаток справа налево:
20/2 = 10, остаток 0 10/2=5, остаток 0 5/2=2, остаток 1 2/2=1, остаток 0 1/2=0, остаток 1
В результате получаем: 10100b = 20
Как перевести шестнадцатеричное число в десятичное:
В шестнадцатеричной системе номер позиции цифры в числе соответствует степени, в которую надо возвести число 16:
8Ah = 8*16 + 10 (0Ah) = 138
В настоящий момент есть множество калькуляторов, которые могут считать и переводить числа в разных системах счисления. Например, калькулятор Windows, который должен быть в инженерном виде. Очень удобен калькулятор и в DOS Navigator’е. Если у вас есть он, то отпадает необходимость в ручном переводе одной системы в другую, что, естественно, упростит вам работу. Однако, знать этот принцип крайне важно!
Сегментация памяти в DOS.
Возьмем следующее предложение: «Изучаем сегменты памяти». Теперь давайте посчитаем, на каком месте стоит буква «ы» в слове «сегменты» от начала предложения включая пробелы. На шестнадцатом. Подчеркну, что мы считали слово от начала предложения.
Теперь немного усложним задачу и разобьем предложение следующим образом (символом «_» обозначен пробел):
Пример N 1: 0000: Изучаем_ 0010: сегменты_ 0020: памяти 0030:
В слове «Изучаем» символ «И» стоит на нулевом месте; символ «з» на первом, «у» на втором и т.д. В данном случае мы считаем буквы начиная с нулевой позиции, используя два числа. Назовем их сегмент и смещение. Тогда, символ «ч» будет иметь следующий адрес: 0000:0003, т.е. сегмент 0000, смещение 0003. Проверьте.
В слове «сегменты» будем считать буквы начиная с десятой позиции, но с нулевого смещения. Тогда символ «н» будет иметь следующий адрес: 0010:0005, т.е. пятый символ начиная с десятой позиции. 0010 — сегмент, 0005 смещение. Тоже проверьте.
В слове «память» считаем буквы начиная с 0020 сегмента и также с нулевой позиции. Т.о. символ «а» будет иметь аодрес 0020:0001, т.е. сегмент 0020, смещение 0001. Опять проверим.
Итак, мы выяснили, что для того, чтобы найти адрес нужного символа необходимо два числа: сегмент и смещение внутри этого сегмента. В Ассемблере сегменты хранятся в сегментных регистрах: CS, DS, ES, SS (см. предыдущий выпуск ), а смещения могут храниться в других (но не во всех).
Регистр CS служит для хранения сегмента кода программы (Code Segment — сегмент кода);
Регистр DS для хранения сегмента данных (Data Segment — сегмент данных);
Регистр SS для хранения сегмента стека (Stack Segment — сегмент стека);
Регистр ES дополнительный сегментный регистр, который может хранить любой другой сегмент (например, сегмент видеобуфера).
Пример N 2:
Давайте попробуем загрузить в пару регистров ES:DI сегмент и смещение буквы «м» в слове «памяти» из примера N 1 (см. выше). Вот как это запишется на Ассемблере:
(1) mov ax,0020 (2) mov es,ax (3) mov di,2
Теперь в регистре ES находится сегмент с номером 20, а регистре DI смещение к букве «м» в слове «памяти». Проверьте, пожалуйста.
Здесь стоит отметить, что загрузка числа (т.е. какого-нибудь сегмента) напрямую в сегментый регистр запрещена. Поэтому мы в строке (1) загрузили сегмент в AX, а в строке (2) загрузили в регистр ES число 20, которое находилось в регистре AX:
mov ds,15---> ошибка!mov ss,34h---> ошибка!
Когда мы загружаем программу в память, она автоматически располагается в первом свободном сегменте. В файлах типа *.com все сегментные регистры автоматически инициализируются для этого сегмента (устанавливаются значения равные тому сегменту, в который загружена программа). Это можно проверить при помощи отладчика. Если, например, мы загружаем программу типа *.com в память, и компьютер находит первый свободный сегмент с номером 5674h, то сегментные регистры будут иметь следующие значения:
CS = 5674h DS = 5674h SS = 5674h ES = 5674h
Код программы типа *.com должны начинаться со смещения 100h. Для этого мы, собственно, и ставили в наших прошлых примерах программ оператор org 100h, указывая Ассемблеру при ассемблировании использовать смещение 100h от начала сегмента, в который загружена наша программа (позже мы рассмотрим для чего это нужно). Сегментные же регистры, как я уже говорил, автоматически принимают значение того сегмента, в который загрузилась наша программа.
Пара регистров CS:IP задает текущий адрес кода. Теперь рассмотрим, как все это происходит на конкретном примере:
Пример N 3.
(1) CSEG segment (2) org 100h (3) _start: (4) mov ah,9 (5) mov dx,offset My_name (6) int 21h (7) int 20h (8) My_name db 'Oleg$' (9) CSEG ends (10) end _start
Итак, строки (1) и (8) описывают сегмент: CSEG (даем имя сегменту) segment (оператор Ассемблера, указывающий, что имя CSEG — это название сегмента); CSEG ends (end segment — конец сегмента) указывает Ассемблеру на конец сегмента.
Строка (2) сообщает, что код программы (как и смещения внутри сегмента CSEG) необходимо отсчитывать с 100h. По этому адресу в память всегда загружаются программы типа *.com.
Запускаем программу из Примера N 3 в отладчике. Допустим, она загрузилась в свободный сегмент 1234h. Первая команда в строке (4) будет располагаться по такому адресу:
1234h:0100h (т.е. CS = 1234h, а IP = 0100h) (посмотрите в отладчике на регистры CS и IP).
Перейдем к следующей команде (в отладчике CodeView нажмите клавишу F8, в другом посмотрите какая клавиша нужна; будет написано что-то вроде «F8-Step»). Теперь вы видите, что изменились следующие регистры:
AX = 0900h (точнее, AH = 09h, а AL = 0, т.к. мы загрузили командой mov ah,9 число 9 в регистр AH, при этом не трогая AL. Если бы AL был равен, скажем, 15h, то после выполнения данной команды AX бы равнялся 0915h)
IP = 102h (т.е. указывает на адрес следующей команды. Из этого можно сделать вывод, что команда mov ah,9 занимает 2 байта: 102h — 100h = 2).
Следующая команда (нажимаем клавишу F8) изменяет регистры DX и IP. Теперь DX указывает на смещение нашей строки («Oleg$») относительно начала сегмента, т.е. 109h, а IP равняется 105h, т.е. адрес следующей команды. Нетрудно посчитать, что команда mov dx,offset My_name занимает 3 байта (105h — 102h = 3).
Обратите внимание, что в Ассемблере мы пишем:
mov dx,offset My_name
а в отладчике видим следующее:
mov dx,109 (109 — шестнадцатеричное число, но CodeView символ ‘h’ не ставит. Это надо иметь в виду).
Почему так происходит? Дело в том, что при ассемблировании программы, Ассемблер подставляет вместо offset My_name реальный адрес строки с именем My_name в памяти. Можно, конечно, записать сразу
mov dx,109h
Программа будет работать нормально. Но для этого нам нужно высчитать самим этот адрес. Попробуйте вставить следующие команды, начиная со строки (7) в примере N 3:
(7) int 20h (8) int 20h (9) My_name db 'Oleg$' (10) CSEG ends (11) end _start
Просто продублируем команду int 20h (хотя, как вы уже знаете, до строки (8) программа не дойдет).
Теперь ассемблируйте программу заново. Запускайте ее под отладчиком. Вы увидите, что в DX загружается не 109h, а другое число. Подумайте, почему так происходит. Это просто!
В окне «Memory» («Память») вы должны увидеть примерно такое:
1234:0000 CD 20 00 A0 00 9A F0 FE = .a. |N1_|_N2_| |_________N3__________| |N4_|
Позиция N1 (1234) — сегмент, в который загрузилась наша программа (может быть любым).
Позиция N2 (0000) — смещение в данном сегменте (сегмент и смещение отделяются двоеточием (:)).
Позиция N3 (CD 20 00 . F0 FE) — код в шестнадцатеричной системе, который располагается с адреса 1234:0000.
Позиция N4 (= .a.) — код в ASCII (ниже рассмотрим), соответствующий шестнадцатеричным числам с правой стороны.
В Позиции N2 (смещение) введите значение, которое находится в регистре DX после выполнения строки (5). После этого в Позиции N4 вы увидите строку «Oleg$», а в Позиции N3 — код символов «Oleg$» в шестнадцатеричной системе. Вот что загружается в DX! Это не что иное, как АДРЕС (смещенеие) нашей строки в сегменте!
Но вернемся. Итак, мы загрузили в DX адрес строки в сегменте, который мы назвали CSEG (строки (1) и (9) в Прмере N 3). Теперь переходим к следующей команде: int 21h. Вызываем прерывание DOS с функцией 9 (mov ah,9) и адресом строки в DX (mov dx,offset My_name).
Как я уже говорил раньше, для использования прерываний в программах, в AH заносится номер функции. Номера функций нужно запоминать.
Наше первое прерывание.
Функция 09h прерывания 21h выводит строку на экран, адрес которой указан в регистре DX.
Вообще, любая строка, состоящая из ASCII символов, называется ASCII-строка. ASCII символы — это символы от 0 до 255 в DOS, куда входят буквы русского и латинского алфавитов, цифры, знаки препинания и пр.
Изобразим это в таблице (так всегда теперь будем делать):
Функция 09h прерывания 21h — вывод строки символов на экран в текущую позицию курсора:
Вход: AH = 09h, DX = адрес ASCII-строки символов, заканчивающийся ‘$’
Выход: ничего
В поле «Вход» мы указываем, в какие регистры что загружать, а в поле «Выход» — что возвращает функция. Сравните эту таблицу с Примером N 3.
Вот мы и рассмотрели сегментацию памяти. Если я что-то упустил, то это рассмотрим в последующих выпусках. Очень надеюсь на то, что вы разобрались в данной теме.
Теперь интересная программка для практики, которая выводит в верхний левый угол экрана веселую рожицу на синем фоне:
(1) CSEG segment (2) org 100h (3) _beg: (4) mov ax,0B800h (5) mov es,ax (6) mov di,0 (7) (8) mov ah,31 (9) mov al,1 (10) mov es:[di],ax (11) (12) mov ah,10h (13) int 16h (14) (15) int 20h (16) (17) CSEG ends (18) end _beg
Многие операторы вы уже знаете. Поэтому я буду объяснять только новые.
В данном примере мы используем вывод символа прямым отображением в видеобуфер.
В строках (4) и (5) загружаем в сегментный регистр ES число 0B800h, которое соответствует сегменту дисплея в текстовом режиме (запомните его!). В строке (6) загружаем в регистр DI нуль. Это будет смещение относительно сегмента 0B800h. В строках (8) и (9) в регистр AH заносится атрибут символа (31 — ярко-белый символ на синем фоне) и в AL — ASCII-код символа (01 — это рожица) соответственно.
В строке (10) заносим по адресу 0B800:0000h (т.е. первый символ в первой строке дисплея — верхний левый угол) атрибут и ASCII-код символа (31 и 01 соответственно) (сможете разобраться?).
Обратите внимание на запись регистров в строке (10). Скобки ( [ ] ) указывают на то, что надо загрузить число не в регистр, а по адресу, который содержится в регистре (в данном случае, как уже отмечалось, — это 0B800:0000h).
Можете поэксперементировать с данным примером. Только не меняйте строки (4) и (5). Сегментный регистр должен быть ES (можно, конечно, и DS, но тогда надо быть осторожным). Более подробно данный метод рассмотрим позже. Сейчас нам из него нужно понять принцип сегментации на практике.
Следует отметить, что вывод символа прямым отображением в видеобуфер является самым быстрым. Выполнение команды в строке (10) занимает 3 — 5 тактов. Т.о. на Pentium-100Mhz можно за секунду вывести 20 миллионов(!) символов или чуть меньше точек на экран! Если бы все программисты (а особенно Microsoft) выводили бы символы или точки на экран методом прямого отображения в видеобуфер на Ассемблере, то программы бы работали чрезвычайно быстро. Я думаю, вы представляете.
Почему char занимает 1 байт, а строка с одним символом — 2 байта?
Слышал что-то про добавление в конце строк » \0 «, но не вдавался в подробности. Кто знает, ответьте пожалуйста!
- Вопрос задан более трёх лет назад
- 12792 просмотра
Комментировать
Решения вопроса 3
Сеньор-помидор
Все правильно, этот 1 байт занимает символ конца строки ‘\0’
Ответ написан более трёх лет назад
Комментировать
Нравится 9 Комментировать
Существует 2 типа строк:
Типа С.
Тип Паскаль.
К языкам это не имеет отношения: язык Паскаль может использовать строки типа С, язык С может использовать строки типа Паскаль. Название просто исторически возникло, т.к. изначально в С и Паскале были только одного вида строки (разные, такие как описано ниже).
Строка типа С — это массив байтов, заканчивающийся нулем. То есть строка не может содержать символ с кодом 0 (не числом 0, а символ с кодом 0, нулевой байт). Длина строки всегда = количество символов + 1 байт (с нулевым кодом) в конце строки.
Строка типа Паскаль в начале хранит 1 байт, указывающий длину строки, затем идет массив символов. Строка может содержать внутри себя символы с кодом 0. Но не может быть длиннее 255 байт. В памяти такая строка занимает те же что и С = число символов в строке + 1 байт в начале, хранящий её длину.
А еще есть строки UNICODE, UTF8, строки типа Паскаль, где длина указана 2-мя байтами (т.е. максимальная длина 65535 символов в строке).
Длина таких строк в байтах может быть очень и очень разной. Совсем не соответствующей числу символов. Разница будет не на 1 байт (как в простых строках типа С и типа Паскаль). Более того, например, в UTF8 длина строки в байтах будет зависеть от того, что именно написано. )))
В наше время я настоятельно рекомендую изучать не простые char, а обратить внимание именно на UNICODE.
А там вовсе не один байт на один символ. )))))
Ответ написан более трёх лет назад
Нравится 9 41 комментарий
В памяти такая строка занимает те же что и С = число символов в строке + 1 байт в начале, хранящий её длину.
Максимальная длина — 255 символов.
А в C максимальная длина — 4294967295 символов (вместимость size_t).
К тому же, благодаря такому устройству, в C-строках можно гулять туда-сюда с помощью указателя.
У вас совершенно не внятное замечание. Ну включим «зануда-mode»:
1. С помощью указателя можно гулять по ЛЮБОЙ строке. Более того, зная сразу, где конец строки без того, что проверять все байты на 0, гулять по строке типа Паскаль проще, чем по строке типа С.
2. Зачем вам на практике 4204067. ? Если речь идет о текстовом редакторе, то там совсем по другому организовано хранение. Не в одной строке.
3. Разве что в примитивных текстовых редакторах можно все запихнуть в одну строку. Но при попытке редактировать в таком редакторе большой файл вы стазу же столкнетесь с большими задержками при самых обычных операциях вставки-удаления символов в/из середину.
4. Если тебе нужно работать со строками такой длины 4204067. то для строки типа Паскаль никто не мешает использовать не 1 (ограничение на максимальную длину 255), а 4 байта для хранения длины. Что? На 3 байта больше приходится тратить оперативной памяти? И это-то при общей длине строки 4 гигабайта? Ты серьезно считаешь это недостатком?
5. Что? В строка типа Паскаль можно хранить на 3 полезных байта меньше? При длине строки 4204067. ты считаешь это важным? Хорошо. Храним строку в структуре — отдельно размер, отдельно указатель на саму строку. В этом случае строка, размер которой определяется не наличием 0 в конце, а длина которой храниться отдельно позволяет хранить строки более длинные на 1 байт. Кому только это надо.
5. То, что ты сразу знаешь длину, а тебе не нужно бегать и считать, ища ноль — преимущество по скорости для многих типовых операций. А если действительно используются возможности по максимуму, то есть работаем с гигантскими строками 4204067. то искать конец строки в такой строке — просто глупо. Лучше знать заранее.
6. В строке нельзя хранить 0. Как показывает практика, если уж речь идет о строках такой длины как 4295967. то это скорее всего уже не обычный текст, а какие-то данные не текстовые, просто хранимые в виде строкоподобного массива, а там запросто и 0 может встречаться внутри строки, что делает невозможно использование обычной строки для хранения таких длинных строк с данными.
7. Вывод: число 4204067. хорошо попонтоваться, что «я знаю такую штуку как size_t», а фактически практической пользы от этого мало.
1. С помощью указателя можно гулять по ЛЮБОЙ строке.
С помощью указателя можно гулять по нескольким строкам, сложенным друг за другом.
В Паскале это всё будет снова молиться на размер одной строки.
2. Зачем вам на практике 4204067. ? Если речь идет о текстовом редакторе, то там совсем по другому организовано хранение. Не в одной строке.
Да базу данных можно хранить так, файловую систему, много чего.
3. Разве что в примитивных текстовых редакторах можно все запихнуть в одну строку.
Я бы не стал так делать, потому что оно не пройдёт тест на огромный файл.
4. Если тебе нужно работать со строками такой длины 4204067. то для строки типа Паскаль никто не мешает использовать не 1 (ограничение на максимальную длину 255), а 4 байта для хранения длины.
Предлагаешь заморачиваться с подбиранием размера, а я вот просто сохраню строку с нуль-символом.
Пока ты будешь размеры подбирать, я уже полпрограммы напишу и буду чаёк попивать.
5. Что? В строка типа Паскаль можно хранить на 3 полезных байта меньше? При длине строки 4204067. ты считаешь это важным?
Да я могу хоть каталог файлов так сохранить один за другим. Маркерная система — это обычная система, которую придумали ещё до C. В данном случае маркер конца данных — нуль-символ. У тебя нет таких навыков, поэтому все мысли только через размер данных идут.
А если действительно используются возможности по максимуму, то есть работаем с гигантскими строками 4204067. то искать конец строки в такой строке — просто глупо.
Конечно, проходить по всей строке с проверками на нуль-символ, — способ неправильный. Зато можно работать с данными напрямую, без заморочек с размером. Можно нарезать их прямо с середины. В любом месте можно встать и поставить начало внутренней строки (подстроки). Вот там есть пример в библиотеке — strtok() — когда строку можно нарезать на слова, сохраняя указатели на них. Можно и интереснее операции делать — ограничений нет. С размером этой возможности нет, там всё тупо и ограничено.