Разбираемся в кодировках

← →
DevilDevil © (2014-01-24 16:16) [0]

Совсем скоро понадобится писать потоковый конвертатор кодировок в довесок к функционалу библиотеки CachedBuffers. Это нужно для парсинга и генерации большого объёма текстовых файлов. К примеру если ваш парсер рассчитан на кодировку utf16, а ему подают 2Гб текста в кодировке utf8 - то стандартными средствами Delphi типа TEncoding или UTF8Decode данную задачу не решить. Не говоря уже о том, что будет отожрано немеряно оперативной памяти и работать жутко медленно.

Мне уже довелось иметь дело с конвертацией кодировок. Я подсматривал исходники функций в System.pas, часть кода смотрел в Wine. И добился хороших результатов, но в итоге пришёл к выводу, что мой подход непрофессиональный. К примеру я полагал, что размер символа в кодировке utf16 равен 2м байтам, а оказалось - от 2х до 4х. Я думал, что символ в кодировке utf8 может занимать максимум 3 байта, а оказалось 5. Я думал, что utf16 и UCS2 - это одно и то же.

Конкретно мне такой функционал нужен для быстрого парсинга огромных XML-файлов, где, как известно, должна быть поддержка не только множества Unicode-кодировок, но и множества Ansi-кодировок. И я хочу окончательно в этом разобраться, чтобы последний раз написать, отладить - и больше к этому не возвращаться.

В связи с этим мне хотелось бы получить помощь от форумчан:
1) качественно разжёванная информация
2) конкретный рабочий корректный код конвертации
3) платформозависимые особенности API (Win, Mac, iOs, And, Lin)
4) моральная поддержка
5) помощь в тестировании

Меня часто обвиняют в том, что я слишком далеко отхожу от стандартных простых проверенных решений. И подобная критика была бы очень уместна, если бы передо мной стояли типичные задачи - разработать быстро, без ошибок, с перспективами лёгкой модификации. Но передо мной стоят задачи другого плана - обрабатывать огромные объёмы данных с максимальной скоростью. Поэтому и решения выбираются такие, чтобы добиться максимальной производительности. В частности это означает, что и конвертация будет организована нестандартным некрасивым образом, с чтением например сразу по 4-8 байт за итерацию. Хочется надеяться, что мои навыки и мои бесплатные библиотеки полезны сейчас или будут полезны в будущем вам.

Вот к примеру стал я копать текущие решения TEncoding внутри XE5. И с ужасом обнаружил, что исходники вообще не рассчитаны на 4х байтные кодировки: utf32le и utf32be. Notepad++ тоже не работает с этими кодировками и с utf16 (только ucs2). Поэтому к примеру один из первых моментов, которые хочется уточнить - с помощью какого текстового редактора можно создавать и модифицировать текстовые файлы в настоящих utf16/32 кодировках.

← →
Kerk © (2014-01-24 16:32) [1]

Ну если ты сам говоришь, что делаешь не нечто универсальное, а что-то делающее хорошо одну конкретную работу, то нет ли смысла отказаться от поддержки разных кодировок? Часто ли попадаются тексты в странных кодировках? Нужно ли тебе поддерживать "настоящие" utf16/32, если на данный момент ты даже не знаешь чем такие файлы создать?

Кодировки - штука неисчерпаемая, оттуда живым не вылезешь. Я какое-то время уже занимался проблемами вроде "а почему наше приложение на корейской винде неправильно отображает китайские символы". Никому не пожелаю.

В общем, я не хочу раздувать флейм, о том, что оно тебе не надо. Все равно никто тут кроме тебя не знает, надо ли оно тебе. Просто прими как совет, может быть действительно есть более приоритетные задачи.

← →
DVM © (2014-01-24 16:36) [2]

> Конкретно мне такой функционал нужен для быстрого парсинга
> огромных XML-файлов, где, как известно, должна быть поддержка
> не только множества Unicode-кодировок, но и множества Ansi-
> кодировок.

SAX парсер ты уже написал? Самая, имхо, актуальная кодировка для XML - UTF-8.

> Вот к примеру стал я копать текущие решения TEncoding внутри
> XE5. И с ужасом обнаружил, что исходники вообще не рассчитаны
> на 4х байтные кодировки: utf32le и utf32be. Notepad++ тоже
> не работает с этими кодировками и с utf16 (только ucs2).
> Поэтому к примеру один из первых моментов, которые хочется
> уточнить - с помощью какого текстового редактора можно создавать
> и модифицировать текстовые файлы в настоящих utf16/32 кодировках.
>

Ты хоть раз встречал текст/документ/веб страницу в кодировках utf32le и utf32be? Я - нет. Теоретически, они могут встретиться, но на практике никто даже с реализацией особенно как видишь не заморачивается ибо не целесообразно. Даже UTF-16 редкость. Самые ходовые кодировки - UTF-8, Unicode (два варианта с разным порядком байт) и однобайтовые.

← →
DevilDevil © (2014-01-24 16:51) [3]

> Kerk © (24.01.14 16:32) [1]
> DVM © (24.01.14 16:36) [2]

Вы конечно многое что правильно говорите. Только я предпочитаю прорабатывать конкретный блок прежде, чем переходить на следующий. SAX-парсер это замечательно, но что будет если ему подсунуть другую кодировку? Т.е. в итоге как минимум надо затачиваться на 3 ходовые кодировки: ansi, utf8, utf16. А раз уж подход с переконвертацией одинаковый - почему бы не поднатужиться и не дописать вариации utf32.

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

Ну и третья причина - я периодически сталкиваюсь с задачами парсинга (из разных кодировок). Хочется уже наконец дописать этот момент и забыть как страшный сон :)))

← →
DVM © (2014-01-24 17:37) [4]

> Т.е. в итоге как минимум надо затачиваться на 3 ходовые
> кодировки: ansi, utf8,

Для парсера это практически одно и то же.

> Ну и третья причина - я периодически сталкиваюсь с задачами
> парсинга (из разных кодировок). Хочется уже наконец дописать
> этот момент и забыть как страшный сон :)))

Разные это Utf-8, Unicode и однобайтовые опять же :)

← →
DevilDevil © (2014-01-24 17:42) [5]

> Для парсера это практически одно и то же.

да если название аттрибутов и узлов на латиннице
но к сожалению это бывает не всегда :)

> Разные это Utf-8, Unicode и однобайтовые опять же :)

Да, Ansi, Utf8 и Unicode
Но надоело каждый раз писать велосипед :)

← →
DevilDevil © (2014-01-24 17:42) [6]

* и Utf16

← →
Pavia © (2014-01-24 18:33) [7]

По моему самая распространённая кодировка это GB2312 странно что вы её не поддерживаете.

> Я какое-то время уже занимался проблемами вроде "а почему
> наше приложение на корейской винде неправильно отображает
> китайские символы". Никому не пожелаю.

А вот МС считает что Big5 лучше чем GB2312.

UTF16 по моему никто не поддерживает.
Жил да был UNICODE 2-х байтовый потом консорциум сказал 2-байта мало, что и породило UTF16(новый UNICODE) и UCS16(старый UNICODE)
А так как в программах он обозначался UNICODE то и получилась путаница.

> что размер символа в кодировке utf16 равен 2м байтам, а
> оказалось - от 2х до 4х.

А разве не до 6?

> Самая, имхо, актуальная кодировка для XML - UTF-8.

А по стандарту UNICODE.

← →
Pavia © (2014-01-24 18:34) [8]

← →
BSD_Daemon (2014-01-24 20:35) [9]

Потерпи чуть-чуть.
Все проблемы с кодировками исчезнут при выходе Delphi XE12...

← →
Anatoly Podgoretsky © (2014-01-24 21:27) [10]

> UTF16 по моему никто не поддерживает.Жил да был UNICODE
> 2-х байтовый потом консорциум сказал 2-байта мало, что и
> породило UTF16(новый UNICODE) и UCS16(старый UNICODE)А так
> как в программах он обозначался UNICODE то и получилась
> путаница.

UTF-16 = UCS-2 для первых 64К символов, в больше этого ычтречается только в экзотических случаев, типа иероглифов. Не знаю как сейчас в Дельфи, но ранее была только декларация. Насчет UTF-32 тут вообще смех, Микрософт изначально разрабатывал именно 32 бита, но Юникод корсоциум их обсмеял, он в то время поддерживал 16 бит, когда же Микрософт перешел на 16 бит, то снова подвергся остракизму. Но тут уж Микрософт отыгрался и придумал UTF-16 с поддержкой до 1 миллиона символов. А консорциум остался с 32 битами, но только на Линуксе.

← →
DVM © (2014-01-24 22:07) [11]

> Pavia © (24.01.14 18:34) [8]

> А по стандарту UNICODE

Ни в спецификации XML1.0 ни в XML1.1 не указано, что использовать надо какую либо определенную кодировку. Зато там указано, что все парсеры ДОЛЖНЫ поддерживать UTF-8 и UTF-16.

XML - в первую очередь формат для обмена данными и логичнее всего использовать транспортные кодировки, данные в которых представлены наиболее компактно.
9 из 10 XML файлов используют UTF-8.

← →
DVM © (2014-01-24 22:33) [12]

>
> DevilDevil © (24.01.14 16:16)

http://www.gnu.org/software/libiconv/

Тут смотри реализацию готовую. В принципе можно сделать обертку для этой dll и все. Она почти на всех платформах работает. Ну или портировать, но это долго и муторно.

← →
Rouse_ © (2014-01-24 22:34) [13]

> Вот к примеру стал я копать текущие решения TEncoding внутри
> XE5. И с ужасом обнаружил, что исходники вообще не рассчитаны
> на 4х байтные кодировки: utf32le и utf32be. Notepad++ тоже
> не работает с этими кодировками и с utf16 (только ucs2).
> Поэтому к примеру один из первых моментов, которые хочется
> уточнить - с помощью какого текстового редактора можно создавать
> и модифицировать текстовые файлы в настоящих utf16/32 кодировках.

К вопросу про: "а нафига?"
Ты хоть раз в жизни видел файлы в этих кодировках?
Вот и я нет :)

← →
Rouse_ © (2014-01-24 22:35) [14]

> 9 из 10 XML файлов используют UTF-8.

+1
Причем последний из десяти используется Win1251

← →
Rouse_ © (2014-01-24 22:42) [15]

ЗЫ: ну и к вопросу о спецификациях, откуда ты эти все кодировки вычитал. В свое время я занимался реализацией ZIP в виде набора классов FWZip и конечно хотел реализовать спецуху по полной, но вот проблема... А ее никто не поддерживает на все 100, даже сама PKWARE, у них там даже камент есть, мол это все будет юзаться только тогда когда появится реальная необходимость. Нет ни одного архиватора в мире поддерживающего полный функционал по самой последней спецификации ZIP (да даже по пятой) - это наверное тоже звоночек? :)

← →
картман © (2014-01-25 00:34) [16]

ща договоритесь - через триста постов ветку закроют))

← →
DevilDevil © (2014-01-25 02:18) [17]

Такой вопрос, на засыпку
В начале файла стоит FF первый байт и FE второй байт
Файл представлен в кодировке utf-16 или ucs2 ?

> Rouse_ © (24.01.14 22:42) [15]
> это наверное тоже звоночек? :)

Розыч, я предлагаю сначала разобраться что можно сделать, а потом думать, чем можно пренебречь

← →
Германн © (2014-01-25 02:21) [18]

> я предлагаю сначала разобраться что можно сделать

Во многих случаях для этого приходится сначала сделать, а уж потом разбираться.

← →
DevilDevil © (2014-01-25 02:37) [19]

> DVM © (24.01.14 22:33) [12]
> http://www.gnu.org/software/libiconv/

ты сам оттуда что-нибудь пробовал?

← →
DVM © (2014-01-25 10:38) [20]

> DevilDevil © (25.01.14 02:37) [19]

> ты сам оттуда что-нибудь пробовал?

Конечно, под системами отличными от Windows это практически единственный вариант для работы с различными кодировками с минимумом усилий. В том же FreePascal она используется. Вот обертка например под FreePascal
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/iconvenc/src/

← →
DVM © (2014-01-25 10:48) [21]

> DevilDevil © (25.01.14 02:18) [17]
> Такой вопрос, на засыпку
> В начале файла стоит FF первый байт и FE второй байт
> Файл представлен в кодировке utf-16 или ucs2 ?

Это одно и то же практически.

http://www.unicode.org/faq/basic_q.html#14

Q: What is the difference between UCS-2 and UTF-16? A: UCS-2 is obsolete terminology which refers to a Unicode implementation up to Unicode 1.1, before surrogate code points and UTF-16 were added to Version 2.0 of the standard. This term should now be avoided. UCS-2 does not define a distinct data format, because UTF-16 and UCS-2 are identical for purposes of data exchange. Both are 16-bit, and have exactly the same code unit representation. Sometimes in the past an implementation has been labeled "UCS-2" to indicate that it does not support supplementary characters and doesn"t interpret pairs of surrogate code points as characters. Such an implementation would not handle processing of character properties, code point boundaries, collation, etc. for supplementary characters. [AF]

← →
DVM © (2014-01-25 10:57) [22]

> DevilDevil ©

Касательно SAX XML парсера. Я делал такой для одной своей задачи (разумеется частичную реализацию), где надо было обрабатывать поток XML тегов неопределенного размера с максимальной скоростью. В результате пришел к выводу, что SAX XML парсер НЕ ДОЛЖЕН заниматься каким либо перекодированием поступащих данных. Его задача определить кодировку и правильно читать данные. Далее он просто должен выплевывать элементы как RawByteString ничего не трогая. Иначе будет потеря скорости. Кто захочет сам перекодирует.

← →
DevilDevil © (2014-01-25 13:25) [23]

> DVM © (25.01.14 10:57) [22]

> В результате пришел к выводу, что SAX XML парсер НЕ ДОЛЖЕН
> заниматься каким либо перекодированием поступащих данных.
> Его задача определить кодировку и правильно читать данные.

Скажешь тоже
Допустим парсер ориентирован на кодировку Utf-8
Но пользователь получил XML в формате Utf-16 размером 3Гб

CachedBuffers спроектирована таким образом, чтобы подтягивать новые куски данных по мере надобности. В эту концепцию прекрасно ложатся "промежуточные буферы" или "конверторы". Собственно библиотека на то и рассчитана. В случае если поступающие данные не соответствуют нужной кодировке - просто инициализируем требуемый "конвертор".

Мой SAX-парсер будет принимать Utf8 и Ansi (если все узлы и аттрибуты на латиннице). Но и Utf32be он не должен бояться :)

← →
DevilDevil © (2014-01-25 14:21) [24]

>> В начале файла стоит FF первый байт и FE второй байт
>> Файл представлен в кодировке utf-16 или ucs2 ?

> Это одно и то же практически.

В том то и дело. Что в случае Utf16 символ может быть представлен 4 байтами, а в Ucs2 только 2мя. Поэтому например код преобразования в Utf8 для каждой из этих кодировок должен отличаться. Вот я и спрашиваю. Если BOM равно FF FE - то это Utf16 или UCS2 ?

← →
й (2014-01-25 14:54) [25]

> UCS-2 is obsolete terminology which refers to a Unicode implementation up to Unicode 1.1

← →
clickmaker © (2014-01-25 15:21) [26]

> Если BOM равно FF FE - то это

UTF16 LE

← →
DVM © (2014-01-25 15:59) [27]

> Скажешь тоже
> Допустим парсер ориентирован на кодировку Utf-8
> Но пользователь получил XML в формате Utf-16 размером 3Гб

Я не вижу тут никаких проблем ни с какой кодировкой с хоть 100 тыщ мильонов гигабайт размером файла.

> CachedBuffers спроектирована таким образом, чтобы подтягивать
> новые куски данных по мере надобности. В эту концепцию прекрасно
> ложатся "промежуточные буферы" или "конверторы". Собственно
> библиотека на то и рассчитана. В случае если поступающие
> данные не соответствуют нужной кодировке - просто инициализируем
> требуемый "конвертор".

Фильтры это по умному называется обычно. Ну флаг тебе в руки.

> Если BOM равно FF FE - то это Utf16 или UCS2 ?

если bom не указана вообще что думаешь делать? плюс для некоторых кодировок bom совпадает.

← →
DevilDevil © (2014-01-25 16:53) [28]

> DVM © (25.01.14 15:59) [27]
> Я не вижу тут никаких проблем ни с какой кодировкой с хоть
> 100 тыщ мильонов гигабайт размером файла.

Нет, я тоже не вижу проблем. Просто не понимаю, почему ты советуешь отказаться от подхода переконвертации в случае если кодировка отличается от ожидаемой

> Фильтры это по умному называется обычно. Ну флаг тебе в руки.

фильтры...
может быть
я ещё не придумал итоговое название

> если bom не указана вообще что думаешь делать? плюс для
> некоторых кодировок bom совпадает.

Я тут смотрю как принято устанавливать кодировку. Если BOM нет то смотрится символ "<"... уже на этом этапе теоретически можно понять, какая кодировка.

Если кодировка однобайтовая и не Utf-8 - тогда уже нужно смотреть encoding :)

Оффтоп:
Смотрю исходники NativeXml и хочется плакать. 32битные кодировки не поддерживаются, хоть и определяется BOM на перспективу... но не это самое страшное. Оптимизации... там поле непаханое для оптимизаций....

> DevilDevil © (25.01.14 16:53) [28]

> Просто не понимаю, почему ты советуешь отказаться от подхода
> переконвертации в случае если кодировка отличается от ожидаемой

Скорость обработки выше будет и SAX парсер будет более универсальным. Иногда перекодировка не только не требуется, но и вредна. Перекодировать то всегда можно по месту, если известно какая кодировка и дан буфер с данными. Ну вот, например, SAX парсер генерирует события для тегов и аттрибутов, нам нужны только теги, их мы и будем перекодировать по месту, аттрибуты нам не нужны и перекодировать их не надо - не тратим на них ресурсы.

> Скорость обработки выше будет и SAX парсер будет более универсальным.

Дак а за счёт чего?
Я это и пытаюсь понять :)

Исходя из того, что я вижу - парсер в любом случае получает CachedBuffer в нужной кодировке
Какой там путь преобразований проделает буфер - парсеру всё равно

> Какой там путь преобразований проделает буфер - парсеру
> всё равно
Ну при таком подходе, да, все равно. Грузить преобразованиями процессор будет буфер.

Ты реши, что для тебя важнее - универсальность и красота использования или скорость. Универсальный подход при котором строится некий граф фильтров, выдающий на выходе на блюдечке обработанные и преобразованные данные (все без разбору, нужные и ненужные) будет уступать коду, который необходимые преобразования делает по месту и только при необходимости.
Я уж не знаю как еще объяснить. Первый подход хорош в обычных приложениях, второй в highload и big data приложениях. Все это имхо, из опыта моего.

> DVM © (25.01.14 19:32) [31]

При всём уважении - не понял :)
Парсер понимает кодировки Utf8 и Ansi. Т.е. самые распространённые
Парсинг осуществляется путём просматривания буфера и тестированием, сколько байт в буфере осталось. Когда буфер заканчивается - вызывается "виртуальная" функция докачки следующего куска памяти в буфер.

Давай задам тогда вопрос по другому. Как модель парсинга спроектировать ещё эффективнее?

А пока актуален следующий вопрос
На данный момент я копаю iconv и пока честно говоря не очень разобрался :)
Но каким образом я выполнял преобразования кодировок раньше.

Я вызывал MultiByteToWideChar для символов от 128 до 255 - таким образом получал таблицу Ansi-->UCS-2. А как такого же результата я могу достичь на других ОС?

Хм...
Смотрю в Delphi7 функцию в модуле Systems
function WCharFromChar(WCharDest: PWideChar; DestChars: Integer; const CharSource: PChar; SrcBytes: Integer): Integer; {$IFDEF LINUX} var IconvContext: Integer; {$ENDIF} begin {$IFDEF LINUX} if (DestChars <> 0) and (SrcBytes <> 0) then begin IconvContext := iconv_open("UNICODELITTLE", nl_langinfo(_NL_CTYPE_CODESET_NAME)); if IconvContext = -1 then LocaleConversionError; try Result := BufConvert(WCharDest, DestChars * SizeOf(WideChar), CharSource, SrcBytes, IconvContext, 2, CharacterSizeLocaleChar); finally iconv_close(IconvContext); end; if Result <> -1 then Result := Result div SizeOf(WideChar); end else Result := 0; {$ENDIF} {$IFDEF MSWINDOWS} Result := MultiByteToWideChar(DefaultUserCodePage, 0, CharSource, SrcBytes, WCharDest, DestChars); {$ENDIF} end;

Как так? )))

А что удивляет? Линукс? Так то во время Кайликса было. Первый заход на кроссплатформенность.

> DevilDevil © (25.01.14 20:50) [32]
> > DVM © (25.01.14 19:32) [31]
>
> При всём уважении - не понял :)
> Парсер понимает кодировки Utf8 и Ansi. Т.е. самые распространённые

Фактически парсеру в таком случае надо понимать только где начинаются и где заканчиваются теги XML, а они как правило содержат символы которые что в UTF-8, что в Ansi имеют одни и те же коды и эти символы однобайтные. Т.е для простоты можно полагать, что парсер работает с текстом в котором все символы - однобайтные. Двух и более байтными могут быть только значения узлов или аттрибутов, разные там CDATA и пр, но их парсеру вовсе не надо перекодировать, он их может выдавать в том виде, в котором они были в исходных данных, если это были данные в UTF-8 значит выдает UTF-8. Кому надо прекодирует значения нужных ему узлов и аттрибутов в ту кодировку, которая ему нужна. Исходная ведь известна.

Другое дело, если кодировка исходного документа, например, Unicode и все символы имеют размер по 2 байта. Я так понимаю, что ты собираешься перекодировать такие данные перед тем как передавать их парсеру? Так?

> Kerk © (25.01.14 22:19) [35]
> А что удивляет? Линукс? Так то во время Кайликса было. Первый
> заход на кроссплатформенность.

А там какого-нибудь АПИ из юникода в анси разве нет?
И это... как дело обстоит в маке, иос и ведроде ?

У меня сейчас под рукой только Delphi7

> DevilDevil © (25.01.14 21:29) [33]
> А пока актуален следующий вопрос
> На данный момент я копаю iconv и пока честно говоря не очень
> разобрался :)
> Но каким образом я выполнял преобразования кодировок раньше.
>
>
> Я вызывал MultiByteToWideChar для символов от 128 до 255
> - таким образом получал таблицу Ansi-->UCS-2. А как такого
> же результата я могу достичь на других ОС?

Точно так же, можно сэмулировать функцию MultiByteToWideChar как в том же NativeXML сделано, через ICONV или через вот это, например:

https://code.google.com/p/notepas/source/browse/components/tslib/core/CodecUtilsWin32.pas?spec=svn141&r=141

> DevilDevil © (25.01.14 22:40) [37]

> А там какого-нибудь АПИ из юникода в анси разве нет?
> И это... как дело обстоит в маке, иос и ведроде ?

Есть там соответствующие функции, но в каждом разные и проще использовать ICONV которая работает везде. Или свой вариант писать нативный.

> И это... как дело обстоит в маке, иос и ведроде ?

Если верить моему беглому взгляду (мог что-то упустить), то на винде все по-старому, на андроиде используется библиотека ICU (поиск по имени функции ucnv_open вывел на http://site.icu-project.org/), на маке и айосе - iconv.

Разбираемся в кодировках Найти похожие ветки