Как люди внедряют UTF-8 в Smalltalk?

Я предпринимал некоторые предварительные усилия по реализации UTF8String, для которых мне приходилось решать проблемы, связанные с сообщениями, такими как #size, #at:, #do: и т. Д. Среди них есть некоторые, для которых я не мог найти подходящего решения. Примеры включают #new: (класс) и #at:put: (экземпляр), потому что количество байтов, которое им потребуется (или использование), зависит от фактических символов, которые в конце концов будет содержать строка.Как люди внедряют UTF-8 в Smalltalk?

Одной из идей, которую можно было бы рассмотреть, является выделение дополнительных (неиспользуемых) нулевых байтов в хвосте, которые на самом деле не были бы частью строки, и использовать #become: только в тех случаях, когда один из них заканчивается из нулевых позиций. Это хорошая (или плохая) идея? Как должна работать надлежащая реализация?

источник

2016-09-22 Leandro Caniglia

Одним из решений является сохранение последовательности байтов в переменной экземпляра (ByteArray) anf, поэтому используйте подкласс с обычным указателем вместо использования переменнойByteSubclass.

Тогда стратегия предварительного выделения дополнительных байтов может быть легко реализована, так как вы храните эффективный размер в другую переменную экземпляра. До вас настраивать сложность/эффективность кода, баланс памяти/скорости.

Преимущество состоит в том, чтобы избежать взаимодействия с другими примитивами VM, такими как copyReplaceFrom: to: with: StartingAt: который может передавать необработанную кодировку из одного байтового ориентированного класса в другой, потенциально создавая ошибочную интерпретацию кодировок.

Другим преимуществом является то, что вам не нужно ссылаться на стать: супермощью.

источник

2016-09-23 07:47:03

Спасибо aka.nice. Я рассмотрел это, но не пробовал (пока), потому что новый класс не наследовал бы от String, и это могло бы создать некоторые проблемы синхронизации (оба класса развиваются вместе) плюс то, что кажется значительным дубликатом кода (не так уверен это все же). –

@LeandroCaniglia ok, может быть проблемой в Cuis, в этой схеме String должен быть абстрактный (указательный) класс, UTF8String переменнойByteSubclass и ByteString другой (с некоторым известным соглашением кодировки), как в Squeak. –

О да. Ты прав! Я не рассматривал эту возможность. Я не использую Cuis, но в моей системе абстрактный класс 'String' равен байтам. Ваша идея для рефакторинга теперь имеет для меня большой смысл. –

IMHO лучше использовать UTF8 только для импорта и экспорта. Внутри используйте 32 бита для символов.

источник

2016-09-22 22:42:48

Согласен. Причина, по которой я работаю над этим, - предоставить некоторые базовые возможности для проверки и отладки последовательностей UTF-8, которые используются для целей импорта/экспорта. –

В Python они решили эту проблему, используя внутреннюю UTF-32 (в основном, как утверждает Берт), которая является кодировкой с фиксированной шириной (хотя они оптимизируются путем сброса неиспользуемых байтов). См. Раздел legacy.python.org/dev/peps/pep-0393. –

Пока я согласен с Бертом, будьте осторожны. Даже использование 32-битной точки кода не гарантирует, что одна 32-разрядная кодовая точка всегда будет одним символом. :) – Tobias

Если вы можете позволить себе потратить усилия, вы можете сделать гораздо лучше, чем 32 бит для всех персонажей. Фактические тексты являются либо all-ascii (английский язык, программы), имеют некоторые символы не ascii (немецкий, французский), либо почти завершены многобайтовые. Для тех, у кого есть несколько не-ascii, вы можете сохранить вспомогательную структуру данных, чтобы помочь с #at: и т.д.

источник

2016-09-23 13:08:55

Любое предложение о том, где вы сохраните структуру данных? Единственное, о чем я могу думать, это свойство (в байтовых объектах нет переменных экземпляра.) Это то, что вы предлагаете? –

Что-то, используя первый байт (ы) специальным образом, я бы сказал. –

ответ

Смежные вопросы