Я какое-то время назад очень активно интересовался этой темой, в последнее время появилось много другого любопытного и метаданные документов отошли на второй план, однако в практических целях иногда знание того что и [...]]]> Последний раз про метаданные в офисных документах я писал более года назад в этой заметке «Извлечение скрытых метаданных из документов MS Office«.

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

Всех нюансов, конечно, не расскажешь, но кое что в дополнение и повторение к ранее написанному у меня есть. Единственно — примеров не будет. Те примеры что у меня сейчас на руках, могут оказаться не самые приятными для тех кто документы готовил. Так что примеры как-нибудь в другой раз.

Итак метаданные.

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

Фактически я бы разделил эту идентификационную информацию на 4 типа:

- метаданные документа – свойства (properties)  документа которые обычно забывают удалить при сохранении и пересылке.

- метаданные вложенных объектов — свойства вложенных OLE объектов и изображений.

- маркеры — данные в гипертексте документа идентифицирующие его владельца.

- скрытые данные - информация в участках документа недоступных для визуального просмотра.

Для каждого из типов идентификационной информации имеются свои ограничения доступности и характера содержимого.

1. Метаданные документа

Это свойства документа которые видны если открыть его «Свойства» в Эксплорере Windows или открыв в соответствующей программе MS Office. Про эти свойства, казалось бы, должны знать все и последние версии MS Office включают возможности удаления этих метаданных. Однако на практике это далеко не так. Часто метаданные забывают почистить и удалить и там можно увидеть «чувствительную информацию» о том кто был на самом деле автором документа,

2. Метаданные вложенных объектов

Об этом я писал в прошлой заметке и повторю сейчас. Вложенные объекты — это так называемые OLE объекты или контейнеры StructuredStorage содержащие другие документы/объекты с которыми умеет работать MS Office. Ещё вернее что объекты с которыми вообще умеет работать MS Windows, но в данном случае чуть упростим.

Если описать это ещё проще, то когда Вы готовите таблицу в Excel, а потом вставляете её в презентацию — это вставка OLE объекта. Точно также если вы делаете диаграмму в Visio и потом вставляете её в презентацию или документ — это вставка OLE объекта, если только вы не преобразовали вначале диаграмму в изображение.

Особенность этих вложенных объектов в том что каждый из них несёт свой собственный набор свойств заданных в той программе в которой данный объект создавался. Если Вы вложили таблицу Excel — значит у документа будут свойства которые указаны в Excel. Если объект Visio, то свойства заданные в Visio.

Коварство этой ситуации в том в что, что если Вы создаёте объект не в родной его программе, а через меню другой офисной программы через «Вставить объект», то у Вас не будет возможности отредактировать свойства документа. А также если Вы работаете над документом вместе с кем-то и этот кто-то вставил объект, то в свойствах этого объекта будут метаданные с компьютера того пользователя и они там останутся.

Вложенные объекты можно извлечь несколькими способами, но большая часть из них весьма техническая и требует знаний того как устроены документы MS Office внутри, поэтому самый практичный способ — сохранить документ в одном из форматов OpenXML и распаковать его любимым ZIP распаковщиком. В результате, OLE объекты будут в папке embeddings. Впрочем  я ранее уже это описывал и заметке на которую я сослался вначале этого поста есть подробное описание процесса.

Однако, вложенными объектами могут быть не только OLE объекты. К этой же категории носителей информации можно отнести изображения. В изображениях может сохранятся информация EXIF (в JPEG файлах) и XMP. Подобное встречается гораздо реже, в основном если кто-то необдуманно вставляет в документы необработанные фотографии. Извлечь изображения можно по тому же рецепту — преобразовать в OpenXML, распаковать и заглянуть в папку media.

3. «Маркёры»

Это очень условное название для той информации которая может присутствовать в тексте документа и позволяет узнать более о его авторе. К подобной информации можно отнести:

- обсуждения и комментарии в режим правки. Иногда (в последнее время всё реже) авторы документов забывают про режим правки и публикуют документ со всей историей обсужения, заметками и так далее.

- ссылки. В некоторых случаях, сознательно или по ошибке в документах остаются ссылки на локальные документы того же пользователя или документы в его локальной сети. Чаще всего эти ссылки указывают на файлы на Desktop или же в папке «Мои документы«. Главное что такие ссылки позволяют узнать — локальное имя пользователя извлекаемой из пути к данному документу.

4. Скрытые данные

Кроме вполне очевидных данных (маркёров) в тексте есть некое количество данных которые скрыты в блоках бинарных файлов о предназначении которых можно знать или догадываться. Например, в Excel файлах есть специальный блок PLS содержащий информацию о принтерах.  Он содержит точно название модели принтера и его название и, скорее всего некую дополнительную информацию.

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

А как собственно получить все эти данные?

Инструменты

Существует довольно большое число инструментов по работе с метаданными, но чего-то универсального не нет. Каждый из инструментов имеет свои плюсы и минусы и многие из них (но не все) описаны в статье Document Metadata Extraction в Forensics Wiki -http://www.forensicswiki.org/wiki/Document_Metadata_Extraction здесь много ссылок на инструменты и библиотеки.

Набор инструментов:

- MS Office 2007-2010 для преобразования из бинарных форматов MS Office в OpenXML. В данном случае OpenOffice не подойдёт поскольку он не сохраняет OLE объекты

- Strings - утилитка из пакета Sysinternals позволяющая извлечь строковые переменные.

- OffVis — это такая специальная утилита от Microsoft позволяющая копатся в глубинах офисных документов. При глубоком анализе документов и выковыриванию PLS блоков из файлов Excel — незаменима. Скачать можно здесь http://download.techworld.com/3214034/microsoft-offvis-11/

- Metadata Extraction Tool — бесплатная утилитка по извлечению метаданных из офисных документов, PDF, изображений и так далее. заглядывает неглубоко и находит не всё  http://meta-extractor.sourceforge.net/

- Catalogue — собирает метаданные из разного типа файлов http://peccatte.karefil.com/software/Catalogue/CatalogueENG.htm

- Metadata Analyzer — извлекает метаданные (только базовые) http://smartpctools.com/metadata/

- Document Trace Remover — убирает метаданные http://smartpctools.com/trace_remover/

- Oracle Outside In - инструмент для разработчиков, поддерживает около 500 форматов файлов http://www.oracle.com/us/technologies/embedded/025613.htm

Это, конечно, совсем не предел тем вокруг извлечения информации. Есть также метаданные и способы их выковыривания из документов PDF и OpenOffice, электронных писем и так далее.

Кроме того есть масса нераскрытых возможностей связанных с неполным описанием бинарных проприетарных форматов.

А тем временем, на днях, представители Яндекса выложили в открытый доступ ряд open source проектов — http://clubs.ya.ru/company/replies.xml?item_no=30753

Самый интересный из которых, на мой взгляд — это PIRE, https://github.com/dprokoptsev/pire Perl Incompatible Regular Expressions Library.

Весьма интересная штука для тех кто когда либо прогонял через шаблоны [...]]]> Что-то давно я не писал про технологии и алгоритмы.

А тем временем, на днях, представители Яндекса выложили в открытый доступ ряд open source проектов — http://clubs.ya.ru/company/replies.xml?item_no=30753

Самый интересный из которых, на мой взгляд — это PIRE, https://github.com/dprokoptsev/pire Perl Incompatible Regular Expressions Library.

Весьма интересная штука для тех кто когда либо прогонял через шаблоны большие объёмы текста/файлов/сетевого трафика и прочего файлового счастья.

Как я понимаю авторы обещают производительность до 400MB в секунду на «common hardware», конечно, с кучей ограничений по тому что в регулярных выражениях может быть, но тем не менее — это быстро. Жаль там нет враппера для Питона, я бы попробовал на своих данных, благо их у меня накопилось много и есть с чем сравнивать. Пока поверю авторам на слово и исхожу из того что это так и есть, благо подход описанный у них в документации вполне понятен и должен работать.

Однако, жаль что подобных открытых разработок небыло хотя бы пары лет назад. Когда я разрабатывал Скиур — http://www.skyur.ru (это такой сервис по преобразованию веб-страниц в RSS), то решал задачи для которых как раз были необходимы такие инструменты  поскольку частью алгоритма является большое число тогда ещё регулярных выражений. В совокупности чуть менее 200, точно не скажу поскольку происходит их сборка из некого базового набора.

Но не имея таких инструментов я пошёл другим путём с решением «в лоб», также оказавшего эффективным.

1. Все регулярные выражения были заменены на конечные автоматы

2. Собственно автоматы проанализированы и разбиты на повторяющиеся блоки.

3. Окончательная сборка шаблонов производится из группы базовых автоматов с добавлением к ним дополнительных блоков по набору правил.

4. На основе базовых шаблонов вручную формируется набор базовых правил заменяющих индекс. Фактически это замена для того же esmre для регулярных выражений. Которую, конечно, можно в дальнейшем автоматизировать.

То есть, фактически, это путь эффективен только в случае:

a.  Управляемости входного потока выражений.

б. Возможности разделения регулярные выражения на простые блоки и высокой повторяемости этих блоков.

Лично я нашёл что PyParsing - http://pyparsing.wikispaces.com при соблюдении описанных выше действий обеспечивает ускорение сравнения по сравнению с регулярными выражениями в разы. Собственно он и является весьма удобным конструктором.

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

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

BuiltWith мне нравится чуть больше, но, если говорить начистоту, то оба эти сервиса устроены [...]]]> В последнее время всё больше появляется сервисов по извлечению информации из веб-сайтов. Например, сравнительно давно существует BuiltWith и недавно появился W3Tech.com.

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

BuiltWith мне нравится чуть больше, но, если говорить начистоту, то оба эти сервиса устроены крайне просто. Есть ограниченный пополняемый список правил для идентификации и классификации тех или иных возможностей на сайтах заложенных.

Правда эти сервисы позволяют анализировать тренды в технологиях, их распространённость и так далее.

Однако, поскольку Рунет не так велик, по сравнению с не-русскоязычной частью Интернета, то оказывается что технологии применяемые тут там не отражаются.

Например, данные о сайте Российской Газеты в обоих сервисах — http://w3techs.com/sites/info/rg.ru и http://builtwith.com/rg.ru. BuiltWith подробнее, но вообще Российской специфики маловато.

Или вот посмотрим Roem.ru — http://builtwith.com/roem.ru и http://w3techs.com/sites/info/roem.ru. Тут информации побольше, но, опять же Российской специфики мало.

Я, честно говоря, в своё время тоже интересовался этой же темой. Однако у меня цели были несколько иные — набивка базы массой вспомогательных метрик для улучшения различных алгоритмов обработки веб-страниц. Но промежуточный результат примерно такой же как в сервисах выше — извлечение массы признаков по группе правил, всего этих правил около 500. Этот механизм уже 1.5 года существует как веб-сервис и этот сервис использовался в ГосСети (www.govweb.ru) для сбора технологий на сайтах.

Сейчас у него есть простенький веб-интерфейс, http://data.skyur.ru в котором можно посмотреть как это работает на практике. Тем кому интересно могут посмотреть там те же сайты http://data.skyur.ru/?host=www.rg.ru и http://data.skyur.ru/?host=www.roem.ru или вот http://data.skyur.ru/?host=www.opennet.ru.

Но, в общем-то, это демка. Так что визуально всё без изысков. А вот стоит ли делать доступным веб-сервис пока не решил.

Из особенно интересного там есть метрики применения регулярных выражений — http://shootout.alioth.debian.org/u32q/benchmark.php?test=regexdna&lang=all&box=1 на Intel QuadCore Q6600.

Кстати, там много и других интересных сравнений реализаций алгоритмов.

Ну а для регулярных выражений, судя по тестам, [...]]]> Оказывается на http://shootout.alioth.debian.org/ публикуют метрики большинства современных языков программирования из тех что можно запустить на Ubuntu, а то есть практически всех.

Из особенно интересного там есть метрики применения регулярных выражений — http://shootout.alioth.debian.org/u32q/benchmark.php?test=regexdna&lang=all&box=1 на Intel QuadCore Q6600.

Кстати, там много и других интересных сравнений реализаций алгоритмов.

Ну а для регулярных выражений, судя по тестам, там лидирует V8 JavaScript engine из Chromium. Ещё в феврале этого года они писали про движок Irregexp у себя в блоге и то что там реализовали компиляцию регулярных выражений в промежуточный автомат.  Что и говорить, результаты впечатляющие, обгоняют даже C++ реализацию на Boost, а мой любимый язык разработки Python так вообще отстаёт в 6 раз.

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

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

P.S. Кстати, бегло посмотрев код могу констатировать тот факт что в другие языки irregexp вполне можно перенести и вся реализация там укладывается в 700 строк, и, конечно, важно проверить его работу на живых, а не синтетических примерах дабы понять производительность на не-ASCII символах.

Чтобы решить эту проблему Скиур был довольно серьёзно изменён внутри:
- заменён парсер на более быстрый
[...]]]> Как многие заметили в последнее время Скиур не распознавал многие из новостных страниц.
Основной проблемой этого являлась нарастающая нагрузка на и увеличивающееся число страниц для распознавания что и приводило к таймаутам и т.д. до ненахождения информации.

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

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

Если вкратце, то основной постулат такой — подавляющее число маркирующих кодов и уникальных идентификаторов создаются по ограниченному числу правил и подлежат разложению на ряд признаков позволяющих связывать эти коды с другими информационными [...]]]> Почти год назад я писал на эту  тему в заметке Систематизация расшифровки кодов и управления справочниками, а сейчас продолжу приостановленные тогда размышления.

Если вкратце, то основной постулат такой — подавляющее число маркирующих кодов и уникальных идентификаторов создаются по ограниченному числу правил и подлежат разложению на ряд признаков позволяющих связывать эти коды с другими информационными массивами и справочниками, а также на их основе извлекать больше информации об исследуемых/анализируемых объектах.

Но, вернёмся к кодам — что это такое и как они есть. Буду приводить примеры:

• 049205770 — пример кода БИК — банковского идентификационного кода
• 02.03.1989 — пример записи даты в формате dd.mm.yyyy, где dd — день, mm — месяц, yyyy — год от рождества Христова
• ru.wikipedia.org — пример кодирования адреса в виде домена
• 09808117 — пример кода ОКПО,  общероссийского классификатора предприятий и организаций
• 5460000016 — пример кода ИНН. Идентификационного номера налогоплательщика
• 65.12, 65.22.5 - примеры кодов ОКВЭД
• 30401810701200001022 — пример кода корреспондентского счета банка в ЦБ РФ
• ALMZRU8Y — пример кода S.W.I.F.T используемого банковскими организациями
• ГОСТ Р 52980-2008 — пример кода в виде документа ГОСТ
• 454091 — российский почтовый индекс
• 359 — код по общероссийскому классификатору единиц измерения (ОКЕИ) означающий «сутки».
• NO93 8601 1117 947 — международный номер банковского счета, в примере номер счета в банке Норвегии
• 13001 — код правительства Российской Федерации по справочнику ОКОГУ
• 1021600000256 — пример общероссийского государственного регистрационного номера, ОГРН, присваеваемого юридическим лицам.
• ГС-1-50-02-26-0-7709342342-013097-1 — пример номера лицензии на проектирование зданий и сооружений
• 08050 — код улицы «Зелёный проспект» по общемосковскому классификатору улиц

плюс сюда же можно добавить такие коды как: номера банковских карт, автомобильные коды VIN, телефонные номера, коды ISBN, MAC адреса сетевых карт, IP адреса, коды EAN-8, EAN-13, GS-128, DUNS номера организаций в США и многие и многие другие.

Суть же всегда одна — кодирование информации об объектах, это способ решения следующих задач:

• сопоставление объекта некой информационной записи о нём содержащей подробную информацию о его характеристиках, особенностях и атрибутах
• предоставление людям и программным средствам информацию об атрибутах данного объекта.

При этом я пока затрагиваю только вопросы кодирования информации в текста, но есть и другие способы в виде баркодов, знаков, аудиосигналов.

Анализ примеров

Код ИНН 5460000016

Структурно код ИНН состоит из:

- 4 цифры — код налоговой инспекции по справочнику СОУН: 5460 (Межрайонная инспекция по крупнейшим налогоплательщикам Новосибирской области)

- 5 цифр — порядковый номер регистрации организации в инспекции: 00001

- 1 цифра проверочный код: 6 (код верен)

Что ещё мы знаем об этом коде? Далее по наблюдениям:

1. Коды инспекций в справочнике СОУН состоят из 4-х цифр, две первых из которых — это код региона инспекции или же код 99 для крупнейших налогоплательщиков. Но, при указании кодов, код 99 используется для другого налогового кода КПП — поэтому для ИНН мы можем говорить о 100% привязке кода СОУН к определённому региону что закодировано в первых двух его цифрах. Отсюда код ИНН позволяет всегда определить регион местонахождения организации

2. Код ИНН всегда состоит из 10 символов цифр для юридических лиц и 12 символов цифр для физ. лиц. Что означает что код обладает фиксированной длиной.

3. Присвоение порядкового номера производится инкрементально, отсюда зная даты присвоения нескольких номеров можно с высокой вероятностью предсказывать дату его присвоения. Фактически инспекция — это генератор последовательно прирастающих значений и то же правило работает и со всеми остальными кодами в которых можно отделить прирастающую часть от идентификационной.

4. Все части кода ИНН обладают фиксированной длиной, отсутствуют случаи когда они могут перекрываться.

5. Код не содержит иерархии, а только ссылки на другие справочники.

6. Код является совершенным, а то есть - в нём отсутствуют неидентифицированные части и раскрываемым, а то есть все части кода являющиеся ссылками на внешние справочники (регионы и справочник СОУН) существуют и доступны.

7. Код является идентификатором в реестре юридических лиц ЕГРЮЛ где и содержится более подробная информация об идентифицируемом им объекте — организации.

Итого: код ИНН содержит минимальную базовую информацию и является ссылкой на запись о более подробной информации об организации одновременно.

—

Другой пример код S.W.I.F.T: ALMZRU8Y

Код S.W.I.F.T состоит из следующих частей:

— 4 символа — уникальный код организации: ALMZ (АлмазЭргиЭнБанк)

— 2 символа — код страны по ISO 3166-1 alpha-2: RU (Россия)

- 2 символа — код местонахождения организации: 8Y (г. Якутск)

При наличии филиалов код SWIFT может включать дополнительные 3 символа идентифицирующие его филиал. Например, UBSWUS33CHI, где CHI это признак филиала в городе Чикаго.

Что можно сказать об этом коде?:

1. Код можно рассматривать как один код с переменной длиной в 8 и 11 символов, так и как два кода — полный в 11 символов и короткий в 8 символов.

2. Код является совершенным, но не раскрываемым. Несмотря на то что все части кода предопределены, не все справочники известны. В частности справочники кодов местонахождения свои для каждой страны и неизвестны в открытом доступе, равно как и справочники идентификации филиалов

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

4. Код не содержит кода проверки и допускает опечатки и неточности.

5. Код является ссылкой на идентификатор в базе международной организации SWIFT где содержится более подробная информации об участнике этой системы.

6. Код не содержит признаков иерархии объектов.

Итого: код содержит минимальную базовую информацию и является ссылкой на идентификатор в базе.

—

Рассмотрим далее, код почтового индекса — 454091

- 6 цифр — это идентификатор почтового отделения в базе почтовой службы.

Что можно о нём сказать:

1. Код является несовершенным, поскольку для понимания принципов его кодирования требуется детальный анализ имеющихся

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

3. Код не содержит признаков иерархии объектов.

4. Код и его отдельные части обладают фиксированной длиной.

—

Код ОКЕИ — 359

- 3 цифры — уникальный идентификатор единицы измерений по справочнику ОКЕИ, в нашем случае этот код означает единицу измерений «сутки»

Что можно сказать о коде:

1. Код и его части обладают фиксированной длиной

2. Код является совершенным — он состоит из лишь одной части которая является лишь идентификатором.

3. Код не содержит каких-либо дополнительных признаков и ссылок, являсь лишь ссылкой на запись в реестре справочника.

Итого: это пример предельно простого кода не содержащего информации и лишь являющегося ссылкой.

Подробнее о коде ОКЕИ можно почитать и их посмотреть тут http://www.mosclassific.ru/mClass/okei_view.php

—

Код ОКВЭД — 65.22.1 (предоставление потребительского кредита)

Структура кода ОКВЭД: XX.XX.XX при этом код обладает нефиксированной длиной и может быть записан в формах: XX.X, XX.XX, XX.XX.X и XX.XX.XX

Что можно сказать о кодах ОКВЭД:

1. Справочник ОКВЭД является иерархическим и это вложено в его коды. Первые две цифры определяют группу, следующие остальные иерархии подгрупп.

2. Длина кода ОКВЭД колеблется от 4 до 8 символов разбитых на группы по 2 символа цифры разделённых точками.

3. Коды ОКВЭД являются совершенными и раскрываемыми, но не содержат информации о ссылках на внешние данные. Вместо этого они ссылаются на вышестоящие коды в иерархии.

4. По коду ОКВЭД можно получить дополнительную информацию из общедоступного справочника кодов которая включает его название и категорию.

Итого: код ОКВЭД — это пример кода классификатора, когда основной дополнительной информацией которая извлекается это расшифровка его названия. В то же время, сам код не содержит прямых ссылок на другие справочники и объекты

—

Код IBAN и пример в виде:  NO93 8601 1117 947

Структура кода IBAN является нефиксированной и зависит от первых двух символов после его идентификатора. Например, для NO длина кода составляет 15 символов и обладает следующей структурой:

- 2 символа — идентификатор страны

- 2 символа — два знака контрольного числа

- 4 символа — код банка

- 6 символов — код счета

- 1 символ — дополнительное контрольное число

При этом, для других стран длина и структура кода будет отличаться. Подробнее о IBAN можно почитать тут  http://en.wikipedia.org/wiki/International_Bank_Account_Number

В итоге что можно сказать о коде:

1. Код является совершенным, но не полностью раскрываемым поскольку коды банков в кодах IBAN ведутся центробанками отдельных стран в виде отдельных справочников не все из которых доступны.

2. Код является нечётким — это означает что его длина и/или структура зависит от содержимого и требует дополнительных правил интерпретации и/или ведения справочника структурных схем

3. Код обладает множественными ссылками — на справочник стран, на справочники банков в странах, на справочники типов счетов для некоторых стран и так далее.

4. Учитывая нечёткость кода и наличие множественных ссылок на зависящих от содержимого — можно разделять коды IBAN для стран как независимые справочки наследующие общие подходы от некого мета-класса.

Примечание: в принципе, IBAN — это пример одного из наиболее неприятных видов кодов, поскольку детализация и интерпретация зависят от его содержимого и требуются дополнительные усилия на описания структуры кодов в едином формате.

—

Рассмотрим код даты в виде записи 02.03.1989

Об этом коде немного свободным текстом без тезисов.

Почему вообще дата и почему в таком формате? Этот формат даты  dd.mm.yyyy, является не более чем примеров, разумеется этих форматов множество. Факт же в том что записывая дату мы тем самым кодируем данные о временном отрезке длительностью в 24 часа в виде текста. Формат позволяет определить из описания: день, месяц и год. Все три числа — это ссылки на справочники: дней в месяце, месяцев в году и годов. Одновременно с этим значения дня и месяца вместе являются проверочными для определения корректности написания из-за разницы числа дней в месяце, а комбинация дня, месяца и года — проверочной комбинацией для високосных годов.

Это кодирование даты, по сути, является не кодом, а форматом — главное отличие которого от кода в множественности форм представления эталонной информации. Например, также дату можно представить в видах: 02 марта 1989, 62.1989 (день от начала года плюс год), 1989-03-02 и так далее, всего форматов десятки. Одной из особенностью и отличием форматов от кодов является возможность приведения к эталонному значению которое может быть приведено к одному из форматов и заведомо содержит все те признаки что и любой из его форматов.

Итоги и выводы

Остальные коды я не буду расшифровывать сейчас, там схожие принципы и подходы, сейчас же о сведении всего вышенаписанного воедино:

1. Коды можно делить на совершенные и несовершенные — по наличию неидентифицированных частей

2. Коды могут быть раскрываемым и нераскрываемыми — в зависимости от доступности справочников на которые ссылаются отдельные его части и сам код.

3. Коды бывают четкими и нечёткими — по зависимости их структуры и длины от отдельных признаков в коде.

4. Коды могут содержать перекрывающие друг друга части или части накладывающиеся друг на друга. Например, идентификация местонахождения банков в кодах SWIFT является уникальной с кодом страны.

5. Форматы простых данных — дат и чисел в некоторых случаях могут рассматриваться как коды.

В итоге можно говорить об онтологии кодирования — наборе базовых правил и их формальном описании для интерпретации и сопоставления информации скрытой в кодах.

Зачем это нужно?

Собственно, а зачем всё это нужно помимо простого любопытства?

Причин несколько:

1. Понимание и расшифровка кодов нужны при обогащении баз данных. Довольно часто возникает ситуация когда те или иные коды — о продуктах, об организациях или о документах были накоплены и одновременно необходимо к данным добавить дополнительные срезы для их анализа — в этом случае эта информация извлекается как из кодов, так и из внешних справочников и реестров на которые эти коды ссылаются.

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

3. Конкурентная разведка, следственные мероприятия и так далее. Например, проверка организаций по регистрационным кодам, проверка автомобилей по кодам VIN, определение банка по первым 4-5 цифрам банковской карты и так далее.

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

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

В результате посмотрел на LangId.net и AlchemyAPI и там и там одна и та же [...]]]> На днях искал онлайновые сервисы способные помочь при работе с разного рода информацией, в частности одна из задач в определении кодировок и языка веб-страниц, ибо возможность переложить эту рутинную задачу на какой-либо сервис онлайн часть ресурсов может высвободить.

В результате посмотрел на LangId.net и AlchemyAPI и там и там одна и та же ерунда — до половины всех русскоязычных документов определяются как вьетнамские.

При этом информацию о кодировках они вообще не представляют и, похоже, по кодировкам возвращаемым на сервере и на странице коррекцию определения не производят. Иначе говоря, пользоваться ими нельзя. Разумеется есть разные программные реализации того же и определить язык и кодировку своими силами возможно, но это всегда доп. нагрузка на оборудование.

Понятное дело что сервисных и утилитарных API для Рунета и русского языка в частности практически нет. Разьве что вот Яндекс стал предоставлять http://api.yandex.ru/speller/, но это капля в море.

А кто знает какие-либо полезные онлайн API, применимые к Рунету, русскому языку и распознаванию текста?

Сейчас моя книга «подвисла» посередине — готово 30 страниц, плюс несколько десятков разрозненных заметок и исследований которые надо сводить вместе.

Особенность в том что я не описываю алгоритмы, их нет вообще — я [...]]]> Хотя и может показаться обратное, но я не забыл про эту тему, хотя и она сейчас мне уже менее интересна чем ранее.

Сейчас моя книга «подвисла» посередине — готово 30 страниц, плюс несколько десятков разрозненных заметок и исследований которые надо сводить вместе.

Особенность в том что я не описываю алгоритмы, их нет вообще — я описываю со всеми подробностями правила и классификационные признаки которые по совокупности уже можно классифицировать с помощью SVM, Decision Trees или прочих алгоритмов.

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

По каждому правилу приводятся статистика и примеры, в некоторые случаях подробные, в некоторых случаях как «допущение».

В итоге получается не серебрянная пуля, а систематизация правил антиSEO анализа. Разумеется, не исключено что весьма спорная, учитывая что большинство реально работающих антиSEO алгоритмов совершенно непубличны.

Как бы то ни было, книга будет, в том или ином виде — когда точно я ещё отпишу, пока же с желающими можно будет обсудить эту тему на iCamp Russia.

Плюс появилось интересное чтение  в виде описания алгоритма Яндекса - http://helpcontext.ru/?p=507 по выявлению платных ссылок.

Цифры

Пока же приведу некоторые цифры:

- всего из активно используемых веб страниц имеется 2441 страница [...]]]> Для тех кто может быть не знает, Скиур — мой небольшой экспериментальный проект продолжает жить, правда пока его развитие несколько притормозилось, но не от того что нет идей куда развивать, а поскольку есть другие не менее интересные проекты.

Цифры

Пока же приведу некоторые цифры:

- всего из активно используемых веб страниц имеется 2441 страница в RSS каталоге

- из этих страниц извлечено 123 640 новостных записей (регулярной очистки устаревших) и около 1 миллиона записей если устаревшие записи не вычищать.

- посещаемость у сайта весьма скромная, около 300 уникальных посетителей в сутки что, прямо скажем немного, но для некоммерческого сервиса вполне нормально

- а вот посещаемость RSS лент достигает 2500 уникальных посетителей в сутки.

Текущее состояние

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

Развитие

Проект я изначально задумывал как некоммерческим и он таким продолжает оставаться. Признаться я пока не окончательно решил в какую сторону его развивать — улучшения инструментариев для работы с RSS или сделать частью движка распознавания типовых форм данных (чем он и является внутри).  Пока же буду рад обсудить эту тему на iCamp Russia со всеми желающими. Хотя этот доклад и отсутствует в программе — презентация у меня будет с собой.