markdown-it — парсер markdown / CommonMark на стероидах

    Не так давно было много шума об инициатике CommonMark по унификации маркдауна. Казалось бы, наконец-то в этой замечательной разметке наступит порядок. Но на практике не все так просто. Сейчас ведется работа над базовым синтаксисом, и до расширений дело дойдет не скоро. Ждать год с лишним могут не все. Но разработки спецификаций — это скорее научная работа. Нас же интересует практика — как приворачивать маркдаун к конкретным проектам.

    Что же может потребоваться программисту от хорошего парсера маркдауна? Ну конечно же не скорость :). А нужна на самом деле возможность добавлять свои расширения синтаксиса. К сожалению, во всех реализациях парсеров, что я до этого встречал, логика разбора разметки приколочена намертво. Все что остается — ковырять гвоздиком конечный результат и надеяться что конфликтов не случится. Конечно, гарантировать при этом надежный выхлоп невозможно. Можно пойти другим путем — попробовать заслать патч в апстрим. Но тут нет ни каких гарантий, что синтаксис вашего расширения будет нужен кому-то еще кроме вас, и что ваш код будет принят.

    Как же быть? К счастью, теперь у нас есть markdown-it!



    Чем же markdown-it отличается от других парсеров?

    1. Возможность менять правила парсинга. От мнения авторов проекта вы теперь не зависите — делайте свой плагин и будьте счастливы.
    2. Строгое следование CommonMark.
    3. Поддержка таблиц и перечеркнутого текста, как на гитхабе. В ближайшее время авторы планируют добавить остальные популярные расширения.
    4. Всякие бонусные плюшки вроде типографа, правила которого тоже можно дополнять.

    Демо

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

    Что еще полезного в парсере с практической точки зрения? Полностью отпадает необходимость в использовании встроенного HTML (ведь можно добавить все нужное через плагины). Соответственно, отпадает необходимость в валидаторах для защиты от XSS. Это очень удобно, особенно для браузеров, куда не затащить развесистые серверные пакеты вроде OWASP.

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

    Адрес проекта на гитхабе — github.com/markdown-it/markdown-it

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 29

      +2
      Жаль, что пока не написано, как же делать свои расширения…
        0
        Обещают скоро задокументировать
        –6
        Я до сих пор не понимаю зачем изобретать велосипед. Есть HTML, со всеми обязанностями справляется.
          +1
          Хотя бы потому, что чисто визуально MD более понятен. Для сравнения:
          <ul>
              <li>Item 1</li>
              <li>Item 2</li>
          </ul>
          

          и
          * Item 1
          * Item 2
          

          Да и писать с MD-метками быстрее чем с тегами (если вы только не в IDE текст набираете)
            –2
            Мне понятнее <LIst>, нежели *. Я пользовался пару недель марком, если бы понравилось, я бы не писал первый коммент. Привожу доводы.

            meta.stackexchange.com/questions/126382/markdown-does-not-allow-for-bold-italic-then-bold-then-bold-italic
            Мое любимое занятие, сидеть и считать звездочки…
            image
              +3
              А как часто Вам приходится писать такие конструкции? И как по мне, то такой вариант выглядит не особо лучше:
              <strong><em>bold italic</em> bold <em>bold italic</em></strong>
              
                +1
                Что понятнее, хорошо видно по тому, что на самом деле <li> — это list item.
                  0
                  Открою секрет. Читать буквы проще, чем спецсимволы. Конечно, LI является элементом списка, по запарке написал list.
                    0
                    Как насчëт < и >?
                      0
                      Надеюсь это сарказм, иначе плохо.
              +2
              Всё просто — markdown безопасный формат, где можно использовать только определённые шаблоном теги, во-вторых нет проблемы с незакрытыми тегами или неправильно вложенными. Это особенно актуально для UGC, когда пользователи сами применяют разметку к своему тексту и если им дать полноценный html, то результат может быть непредсказуем, да и html-парсер выйдет дороже в ресурсах. Раньше особенно на форумах использовали для этого bbcode.

              Кстати, в приведённом выше примере нет синхронизации позиции обоих окон, а было бы удобно.
                0
                … И я честно говоря не понял, почему нужно было уходить от bbcode и придумывать этот самый Markdown.
                  0
                  В bbcode тоже парные теги, единственный плюс перед html — можно ограничить количество этих тегов
                    0
                    Так парные теги это ж хорошо. Чётко видно где начало, и где конец.
                      0
                      Это повышает уровень ответственности пользователя и риск допустить ошибку. MD же наоборот снижает вероятность ошибки со стороны пользователя.
                        0
                        Ну не знаю. Меня все эти маркдауновские закорючки только сбивают с толку. Риск ошибки гораздо выше для меня.
                  0
                  пользователи сами применяют разметку к своему тексту и если им дать полноценный html

                  Я вставил цитату, на хабре, через HTML, полноценный. Или вы думаете, что не будет XSS под MD? Будут. Просто пока искать способы обмана парсера мало кому нужно.
                  да и html-парсер выйдет дороже в ресурсах

                  Может сразу сделаем рендеринг MD в браузерах? Хотел бы услышать про разницу в парсинге html и md. За счет чего уменьшается потребление ресурсов?

                  Более того, во что парсится MD? Правильно, в HTML, так что же за парадокс такой получается, HTML в HTML превратить тяжелее, чем MD в HTML?
                    0
                    На Хабре не полноценный html, а ограниченное количество тегов и проблема неправильно вложенных тегов не решена (попробуйте перепутать открывающие и закрывающие теги). MD же создавался как легкочитаемый текстовый формат без преобразования, посмотрите выше комментарий SazereS (http://habrahabr.ru/post/241766/#comment_8096248). Не представляю о чём спор — область применения и целесообразность есть у каждого формата, холивар ради холивара? Обманывать же парсер нет смысла, если он пропускает только предустановленные форматы.
                      0
                      На Хабре не полноценный html, а ограниченное количество тегов

                      Тогда весь MD является такой штукой, которая может перевести несколько закорючек в обычные HTML теги.
                      Люди изобретают проблемы.
                      Ладно, давайте останемся при своих мнениях.
                        +1
                        А компилятор переводит несколько закорючек в обычные машинные коды.
                  +3
                  HTML очень плохо читается человеком, имеет множество способов выстрелить себе в ногу, чрезвычайно сильно многословен, многозначен и избыточен, плохо подходит для diff и merge.
                  +1
                  Мне кажется, в пользу markdown есть только один серьёзный довод — он хорошо воспринимается системами контроля версий, изменения в файле markdown видны гораздо лучше, чем изменения в html. Но писать на нём документацию трудно — стандартов многовато, и Remarkable ничем не помогает, да и непонятно как множество markdown файлов объединять в книгу. Может быть, стоит wiki вспомнить.
                    0
                    Для тех, кто делает документацию при помощи Doxygen, MD не должен вызывать проблем.
                    Для книг возможно нужны какие то расширения.
                    0
                    Звучит конечно здорово, но вы посмотрите на их плагины. Вот, например, github.com/jonschlinkert/remarkable/blob/dev/lib/rules_inline/del.js и все это для того, чтобы ~~text~~ в text

                    Как вам?
                      0
                      В чем проблема-то? Вроде понятно что делается и зачем.
                        0
                        Да больно кода много для такого простого действия.
                          0
                          Посмотрите исходники любого полноценного парсера с качественной поддержкой вложенных тегов. Везде так или еще сложнее. У тех кто патается делать проще, потом пачки репортов в трекере о кривой работе.
                            0
                            Может быть, я в парсерах не копался, но желание делать свой плагин пропало. Хотел добавить аналог хабровского спойлера.
                              0
                              В другие парсеры без костылей подобные вещи плагинами вообще не реально добавить. Про спойлеры лучше тут почитать talk.commonmark.org/t/what-could-a-spoiler-tag-extension-look-like/767. Все там и так будет, как только спецификацию утрясут.

                    Only users with full accounts can post comments. Log in, please.