-
Так же кому не жалко и кто переводил на кол адекватный xml-парсер и какие-либо протоколы к im-сетям (irc, jаbbеr и тому подобное) прошу поделиться, дабы не изобретать велосипед. На данный момент перевожу jabbеr. Достаточно трудоемко, в части отсутствия нормального парсера. Возможно даже библиотеки с интерфейсом к ним. Заранее thx.
-
А что значит "нормальный парсер"? в коллекции дополнительных библиотек для КОЛ был вполне себе работоспособный XMLParser.
-
Что есть в коллекции kolxml - нашел только функции генерирования xml-структуры, но не её парсирования. Возможно плохо разобрался, есть ли примеры? Или не тот компонент имею ввиду?
-
надо смотреть большую коллекцию разных модулей... там я именно парсер находил. к сожалению, архива под рукой нет, только сам паскалевский модуль лежит (Я использовал его в одной программке). Обзывался он именно XMLParser и содержал несколько объявлений объектов
-
-
благодарю, вроде как раз то что нужно было
-
парсер оказался неоконченным. Проблемы с парсированием, отказ работы с CDATA и прочее. Естественно ни о какой работе с жабопротоколом и речи быть не может. Вообщем править его трудоемко было, запутан токенайзер какбы, легче было свой собрать. Взял за основу этот и джановский из vcl. Как дотестирую и пару фичей внесу - могу выложить. Может пригодиться.
-
> Как дотестирую и пару фичей внесу - могу выложить. Может
> пригодиться.
>
Ждем.
-
прошу простить) на работе ужос и мракобесие было. Не забил на обещание, нехватка времени. Вернулся к парсеру и вдруг столкнулся с работой в юникоде. Пользуюсь седьмыми дельфями, проработал условия на unicode_ctrls всё отлично. Но так же есть замечательная кодировка utf8, с которой в никсах намучался и тут покоя не дает xD Вообщем есть системная функция, utf8tostring, возвращающая String как AnsiString (d7 же). Но как эта функция пашет в новых дельфях? Как упоминалось string там уже стал жирным стрингом) В самом коле не предусмотрено функций для работы с кодировками, использовать multibytetowidechar и обратно - некрасиво. С другой стороны у меня есть свои кодеки для конвертирования кодировок (для всех возможных карт, кроме карт языков восточной азии). Но только использование модуля с ними прибавит ~50-60 кб в виде таблиц кодировок, а сама функция кодирования-декодирования у о utf8 у меня медленная, с текстом в 5мб задержка секунд в 20 уже при приведении в widechar. Так же не представляю как работать с UCS2-BE. Привел его к little endian, не представляю даже что из этого выйдет.
-
нет ответа) Ладно, пока сырая версия тут. Буду постепенно исправлять. Работает с ucs, utf8, ansi как в юникодном приложении, так и в ansi (принудительно переводит через cp1251). WinXP D7. http://btdompost.hop.ru/tmp/KOLXMLParser.7z
-
-
-
-
последний архив не открывается
-
-
я думаю, у меня тот же самый файлик
-
похоже хостер неправильно отдает 7z архивы. Но у меня этим архиватором прекрасно распаковалось. Вечером перезалью.
-
-
по сути дела убил три недели чтобы собрать парсер с рекомендациями w3.org. Получился медленный процессор))) Только уже не знаю, имеет ли смысл использовать его в приложениях kol, так как добавляет к весу порядка 80 кб, и это только начало. Основная проблема - поддерживаемые кодировки. Для однобайтовых кодировок существуют таблицы в виде массивов. Есть два решения - все таблицы вбить в одну и сжать, например, по хаффману(соответственно при инициализации распаковывать, что повлияет на озу), или же включать поддерживаемые кодировки символами условной компиляции. Как было бы адекватней? Есть еще более насущные проблемы, но и так радует обработка doctypedecl и enity. И да, процессор невалидирущий, и предопределен как standalone. То есть обработки внешних деклараций нет. Если есть сочувствующие - могу выложить сорцы позже.
-
Люди!
У кого есть парсер с демкой. Слезно прошу поделиться.
-
|
Есть новые 
Нет новых [134427 +34][b:0][p:0.001]