LINUX.ORG.RU

Кодировочки или utf-8 и все все все...

 , , ,


0

2

Открываю gedit

1) сохраняю пустой файл, 0 байт

2) ставлю одну цифру 1 в текстовом редакторе, сохранюю в utf-8. Открываю в hex редакторе

31 0A

два байта...

3) добавляю перевод строки

31 0A 0A

Почему один 'лишний' байт 0A?

★★★★★

gedit перед сохранением файла добавляет символ перевода строки (0x0A) ему в конец. Вне зависимости от того, есть он уже в конце или нет.

endeneu13 ()

0A

Это '\n' - перевод строка.

Точно не знаю почему (видимо во избежание всяческих осложнений при обработке вроде diff'а) в текстовых файлах рекомендуется всегда ставить \n на конце. Git, например, даже предупреждает при коммите, если у файла нет \n на конце.

Редакторы считают себя самыми умными и добавляют к файлу \n

Kosyak ★★★★ ()

Да, что этот идиотизм делает в /development/?

Deleted ()
Ответ на: комментарий от Deleted

а development тут притом, что прилетел вот такой вот файл без конечного 0A, а библиотека xml (pugixml) на него матерится...

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 1)

Почему один 'лишний' байт 0A?

Потому что ты любишь переводить строки в конце файла.

Unicode4all ★★★★★ ()
Ответ на: комментарий от fornlr

pugixml

Лол, опенсорсная рабочая XML библиотека - это libxml. XML на C++ нет открытого некопилефтного рабочего, либо глючный Ксеркс, либо наколенные «пуги» различной степени кривости. И libxml везде есть из-коробки, лицензия правильная, используй его же.

anonymous ()
Ответ на: комментарий от i-rinat

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

anonymous ()
Ответ на: комментарий от i-rinat

Даже если там под капотом ад. Какая тебе разница, если оно работает, не падает и дает удобный апи?

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

Какая тебе разница, если оно работает, не падает и дает удобный апи?

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

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от endeneu13

Вне зависимости от того, есть он уже в конце или нет.

Говнище этот gedit. Оно хоть отключается или надо жрать как обычно в гноме?

h578b1bde ★☆ ()
Последнее исправление: h578b1bde (всего исправлений: 1)
Ответ на: комментарий от i-rinat

А, так ты тоже видел? В валгридне? Было, было у меня, я ще удивился с какого хера стабильная (на сквезе было, вновых то могли и исправить) либа подтекает.

deep-purple ★★★★★ ()
Ответ на: комментарий от h578b1bde

Открыть с помощью, один раз поставишь свой любимый редактор вместо гедита и будет тебе счастье.

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

IIRC следующий сниппет помогает супротив валгринда:

    xmlCleanupCharEncodingHandlers();
    xmlDictCleanup();
    xmlCleanupParser();

anonymous ()
Ответ на: комментарий от deep-purple

Я видел «утечки» в Valgrind, но они ушли после того как я в прикладном коде добавил пропущенные xmlFreeDoc(). Не знаю, как так получилось, но автор кода как-то хитро создал SAX2-подобный парсер, инициализировав его колбеками от DOM парсера libxml2, а нужные ему колбеки заменил. (Почему такой изврат вообще можно было сотворить?!).

Но те проблемы, про которые я говорил, они в другом. У меня специфичная задача, надо парсить XML в разных контекстах, в каждом свой аллокатор. Процесс однопоточный, так что сработала передача контекста через глобальную переменную. Но оказалось, что libxml2 любит кешировать некоторые вещи, поэтому возникают ситации, когда он хочет использовать уже освобождённую память. Один раз словил, после чего дальше сидеть на пороховой бочке и ждать пока рванёт опять стало как-то неудобно. И вот тогда захотелось поглядеть на код, а он страшноват.

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

Я тебе уже подробностей не скажу. У меня примерно как у рината было, что-то я там несколько хмл последовательно расколбашивал.

deep-purple ★★★★★ ()
Ответ на: комментарий от i-rinat

А чому не почистить было уже после прохода по всем контекстам?

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

Потому что контекстов неограниченное количество, они начинаются и заканчиваются в непредсказуемое время. Вот как начали приходить данные по каналу, контекст создался. Когда другая сторона закончила передавать данные, контекст разрушается.

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

Лол, опенсорсная рабочая XML библиотека - это libxml. XML на C++ нет открытого некопилефтного рабочего, либо глючный Ксеркс, либо наколенные «пуги» различной степени кривости.

А про rapidxml что скажешь?

Stil ★★★★★ ()
Ответ на: комментарий от Stil

А про rapidxml

ctrl+f SAX : Phrase not found

что скажешь?

промолчу :)

Недопарсеры - это худшее из двух зол же. Если нужно парсить «настоящий» XML (в смысле с неймспейсами, поточно, с валидацией) - то надо брать настоящий парсер (т.е. libxml в С/С++). Если же на другом конце провода сидят дебилы, не могущие в JSON и пуляют Key->Value сообщения в виде плоского XML (в котором из фич XML используются только треугольные скобки) - то можно и руками/регулярками вытащить что-нужно, по крайней мере в таком случае можно ошибки входных данных предсказуемо обработать. А недопарсеры - это «ни два ни полтора».

anonymous ()
Ответ на: комментарий от deep-purple

Открыть с помощью, один раз поставишь свой любимый редактор вместо гедита и будет тебе счастье.

Имелось в виду отключение добавлялки пустых строк конечно, хотя я и не удивлюсь если в гноме „открыть с помощью” выпилят.

h578b1bde ★☆ ()
Ответ на: комментарий от h578b1bde

Ну так это ж не бинарные данные, одна строка, пусть и пустая, быть должна, а строка отделяется переводом строки. Все вполне разумно. А насчет выпилят открыть с помощью — там же есть типа реестр gconf-editor и все доступно оттуда. Но даже если выпилят и конф-эдитор, то это xml-конфиги, и их вполне можно руками.

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

одна строка, пусть и пустая, быть должна

Но ведь таки не одна:

gedit перед сохранением файла добавляет символ перевода строки (0x0A) ему в конец. Вне зависимости от того, есть он уже в конце или нет.


А насчет выпилят открыть с помощью — там же есть типа реестр gconf-editor и все доступно оттуда. Но даже если выпилят и конф-эдитор, то это xml-конфиги, и их вполне можно руками.

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

h578b1bde ★☆ ()
Ответ на: комментарий от anonymous

Вот libxml, кстати, тоже недопарсер. Единственный парсер с полноценной поддержкой стандарта Xerces. Отвратный API у него из-за полного соответствия DOM/SAX API, а они в С++ выглядят дико, так создавались для Java макак. Ну и вообще такая ситуация связана с общей убогостью XML, имхо.

anonymous ()

Кстати, офтоп но все же. Сначала в gnome-builder, а теперь и в gedit, появилась возможность фона в клеточку. Я так понимаю это реализовано в gktsourceview. Как бы пнуть гномеров, чтобы они в vte такое же запилили. Или им самим это дойдет.

APPLE_OS_XX_OS_XY ()
Ответ на: комментарий от anonymous

Xerces C++ - мертвый проект. Там в JIRA ошибки приводящие к сегфолтам не фиксят по 5+ лет. А libxml - живой, ошибки (уязвимости в первую очередь) там активно фиксят.

anonymous ()
Ответ на: комментарий от anonymous

Что не отрицает того факта, что Xerces имеет более полную реализацию стандарта, что только еще 1 гвоздь в гроб XML. Ну и там где я работал - форкнули Xerces, и исправляли его баги, это, наверно, проще чем пилить полноценную поддержку всего, что он поддерживает.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.