З 5-бітовими кодами бодо було зроблено багато справді ранньої роботи, але вони швидко стали досить обмежуючими (лише 32 можливі символи, в основному лише великі літери та кілька розділових знаків, але недостатньо «місця» для цифр) .
Звідти досить багато машин пішло на 6-бітні символи. Це все ще було досить неадекватно - якщо ви хотіли великих та малих (англійських) букв та цифр, то залишилися лише два символи для пунктуації, тож у більшості залишився лише один регістр букв у наборі символів.
ASCII визначив 7-бітний набір символів. Це було "досить добре" для багатьох застосувань протягом тривалого часу, а також лягло в основу більшості нових наборів символів (ISO 646, ISO 8859, Unicode, ISO 10646 тощо).
Двійкові комп’ютери мотивують дизайнерів на створення розмірів у два. Оскільки "стандартний" набір символів так чи інакше вимагав 7 біт, не було великого розтягування, щоб додати ще один біт, щоб отримати потужність 2 (і до того часу зберігання стало досить дешевшим, що "витрачало" трохи на більшість символів було і більш прийнятним).
Відтоді набір символів перемістився до 16 та 32 біт, але більшість основних комп'ютерів багато в чому базуються на оригінальному комп'ютері IBM. Знову ж таки, на ринку достатньо задовольнити 8-бітові символи, що навіть якби ПК не досяг свого нинішнього рівня домінування, я не впевнений, що кожен би все-таки зробив би все з більшими символами.
Слід також додати, що ринок досить змінився. На сучасному ринку розмір символів апаратно визначається менше, ніж програмне забезпечення. Windows, Java та ін. Давно перейшли до 16-бітних символів.
Тепер перешкода у підтримці 16- або 32-бітових символів лише мінімальна від труднощів, властивих самим 16- або 32-бітовим символам, і значною мірою від труднощів підтримки i18n в цілому. У ASCII (наприклад) виявлення того, чи є літера великої або малої літери, або перетворення між ними, неймовірно тривіально. У повному обсязі Unicode / ISO 10646 він в основному невимовно складний (до того, що стандарти навіть не намагаються - вони дають таблиці, а не описи). Потім ви додаєте, що для деяких мов / символьних наборів навіть основна ідея верхнього / нижнього регістру не застосовується. Потім ви додаєте до того, що навіть відображення символів у деяких із них є набагато складнішим.
Це все досить складно, що переважна більшість програмного забезпечення навіть не намагається. Ситуація повільно покращується, але повільно - оперативне слово.