Как бы вы спроектировали 8-битную кодировку?

Question

Как бы вы разработали 8-битную кодировку набора из 256 символов западных языков (скажем, с теми же символами, что и ISO 8859-1), если бы она не была обратно совместимой с ASCII?

Я думаю, что эмпирические правила таковы: если бы ABC...XYZabc...xyz0123...89 были, в этом порядке, первыми символами набора (коды от 0 до 61), тогда isalpha(c) просто потребовалось бы сравнение c < 52 isalnum(c) будет c < 62 и т. Д. В противном случае 0123...89 были бы первыми символами, возможно, atoi() и тому подобное было бы проще реализовать.

Другая идея: если бы буквы были отсортированы как AaBbCcDdEeFf... или aàáâãbcdeèéêëfgh..., я думаю, что словарная сортировка строк была бы более эффективной.

Наконец: есть ли обоснование 0 в том, что он является терминатором строк C вместо, скажем, 255?

Answer 1

Вы не можете реально разработать набор символов без учета обратной совместимости.

Чтобы отказаться от обратной совместимости, у вас должна быть удивительная причина, а обратная совместимость фактически означает ASCII-совместимость . Такую причину будет чрезвычайно трудно сформулировать в сегодняшнем взаимосвязанном мире, где ее поддерживает так много кодировок (взвешенных по использованию или нет). Это ограничит вас узкоспециализированными встроенными средами.

Давайте представим одну из таких сред: микроволновая печь. Он должен отображать цифры и буквы; такие вещи, как «попкорн», «1 унция», «1,2 унции» (размеры мешков для попкорна) и так далее. Это не делает абсолютно никакой связи с любым другим устройством. Он не нуждается ни в каких управляющих кодах (представьте себе однострочный ЖК-дисплей: даже перевод строки не имеет смысла). Мы можем даже сказать, что вы продаете эту микроволновую печь только в тех районах, где говорят по-английски, и выбор другого языка пользовательского интерфейса - совершенно не проблема.

Даже тогда, совместимость с ASCII имеет очень хорошие преимущества с минимальными недостатками. Например, вы можете протестировать производственный код на программно-эмулированном оборудовании и по-прежнему использовать обычные отладчики.

Отбросьте много букв, которые вы никогда не используете, и используйте только верхний регистр (или только нижний регистр), цифры и минимальную пунктуацию (пробел, точка). Это оставляет вам менее 5 бит, необходимых в минимальной схеме. Может быть, меньше, если вы начнете выбрасывать отдельные буквы алфавита, но будет трудно набрать только 4 буквы, чтобы остаться в пределах 4 битов - 4 бита = 16 и 16 - 10 цифр - 2 пунктуации = 4.

Но это не то же самое, что обычное аппаратное обеспечение, которое вы будете использовать, в сегодняшней реальности заметит разницу между 40-битными (8-кратными 5-битными) и 64-битными (8-кратными 8-битными), и это предполагает, что вы можно даже найти стандартное аппаратное обеспечение , которое позволяет вам брить как это.

Answer 2

Если бы я делал это с нуля, у меня была бы следующая схема: -

x00 -- x10  -- Control characters such as end of file, end of line, end of string.

x10 -- x30  -- Alphabetic characters using the following pattern:-
    x10  -> A Upper case A.
    x11  -> a Lower case A.
    x12  -> a with local accent e.g a acute.
    x13  -> a with second local accent e.g. a grave
    .....................
x40 -- x50  -- Local "extra" characters
    Thing like the Scandanavian AE or Danish /O which are regarded as separate 
    characters with thier own position in the collating scheme.

x50 -- x60 -- Punctuation .,:; etc.
x70 -- x80 -- Other special character {}/\ etc.

xF0 -- xFF -- 0 to 9

У этой схемы был бы ряд преимуществ (ни одно из которых не стоило бы боли имплантации и обращения!).

Во-первых, можно использовать числовую исальфу и т. Д. С помощью простой битовой маски.

Во-вторых, сортировка автоматически попадет в естественную последовательность.

Ale, alchohol, ОСТРАЯ, áccentgrave, Пиво Ol

Однако вписать сложный мультикультурный мир в восьмибитную схему просто невозможно, и любая предложенная схема будет каким-то образом скомпрометирована. Реальное решение состоит в том, чтобы выслушать хороших людей из консорциума UNICODE, у которых все базы покрыты простым использованием 16 ботов (или больше!).

Answer 3

255 не является допустимым значением символа в 7-битной системе или может быть где-то посередине собственного набора символов на 9-битной машине. Представьте, что нативное 'e' - это ваш терминатор строки.

Так что это исторически: «Может ли он работать на чипе тостера» был фундаментальным (если модернизирован) принципом проектирования для C. Ширины типов довольно слабо определены в C, поэтому реализации могут использовать «native» elements - char является «наименьшим индивидуально адресуемым элементом», и это не было и не является 8-битным для всех машин. 0 все равно широко не использовался.

Для остальной части вашего вопроса: полностью субъективно, в зависимости от того, для чего оптимизировать. Это имеет смысл только в очень строго определенных средах, где очень мало ресурсов. Например. на немецком языке существуют разные правила сортировки «телефонная книга» и «словарь». Что вы выбираете?

---

В свете ваших примеров я бы поставил сначала цифры, а затем буквы (проще для строк dec / hex). Я бы держал прописные и строчные буквы отдельно - но, как в ascii, одним битом. Вместо того, чтобы наполнять его забавными персонажами, я бы предпочел оставить некоторые символы неопределенными, чтобы некоторые из этих трюков работали лучше. Оптимизация для сортировки не имеет смысла, если вы предварительно не определите алгоритм сортировки.

Answer 4

Я бы не стал проектировать 8-битную кодировку. Это глупо. Существует гораздо больше, чем 255 человеческих персонажей.

Однако, если бы я мог просто переделать набор символов ANSI, я бы удалил все ныне несуществующие управляющие символы, кроме диапазона от 1 до 31. Остальное, по моему мнению, вполне нормально. Вы должны учитывать, как строки сортируются (например, как строка, начинающаяся с подчеркивания, должна быть отсортирована перед строкой, начинающейся с числового символа).

При этом обоснование для установки 0 в качестве ограничителя строки, вероятно, заключается в том, что 0 означает false в условии, поэтому вы можете выполнить итерацию по строке, просто проверив, является ли символ ненулевым, например, if(*string) if(*string != 0xFF).

Также сообщество вики.

Answer 5

Какие проблемы вы видите с существующими наборами символов, которые вы надеетесь решить с помощью нового?

Экономия эффективности, когда требуется только c < 52, а не c > M && c < N, в лучшем случае незначительна, учитывая, что это редко является узким местом. Более того, isalpha () и isalnum () зависят от локали и должны заботиться об акцентированных символах, поэтому в локалях, отличных от той, для которой вы разрабатываете кодировку, вы вообще не получаете никакой экономии.

Ваша вторая идея aàáâãbcdeèéêëfgh... удобна для упорядочения отдельных символов в соответствии с конкретной локалью, но это не помогает упорядочить строки из нескольких символов в языках, где некоторые символы эквивалентны порядку. Например, в немецких словарях умлауты игнорируются для упорядочивания (abc <äbd <abe), поэтому вы все еще не можете выполнить простой лексикографический порядок значений символов. </p>