MarkdownでのWordPress投稿する際のSyntax Highlight環境をどうするか

Web記事にコードを記述する場合、コードのシンタックスハイライトはどうしていますか？

今回は、僕の環境「MarkdownでWordpressへ投稿する」場合にシンタックスハイライトを何で実現するか、今後の快適なブログ投稿のために考察して決めたので、そこまでの経緯を備忘録として残しておきます。

Markdownで記事を記述する　→　HTMLに変換する　→　Wordpress投稿として保存　→　表示リクエストで動的にSyntaxHilight適用

以上の流れで記事を書く場合のお話です。Markdown→HTML変換は、VimrepressというVimのプラグインで行っていますが、中身はpython-markdownというPythonモジュールです。Markdownで記述してHTML変換して投稿しているという人とは特段差はないと思います。

SyntaxHilightの主な手法

2017年8月現在、僕が調べる限り最近の主なSyntaxHilight方法は3つ。

• WordPressプラグイン「Crayon Syntax Highlighter」
• WordPressプラグイン「SyntaxHighlighter Evolved」
• prism.js

WordPressプラグイン「Crayon Syntax Highlighter」

ワードプレスのプラグインCrayon Syntax Highlighterを使う方法。詳しい内容は公式を見るとして、
公式：Crayon Syntax Highlighter

今回で大事な特徴は以下。

• WordPressフレームワークありきになる
• HTML特殊文字の変換が不要。変換はクライアントからリクエストが来たときに行われる
• 若干重いとの報告アリ

WordPress環境がないと意味がなくなるのはあまりよろしくないですね。そしてアルアルの、Wordpressプラグインで表示レスポンスが悪くなる問題。Crayon Syntax Hilighterは、結構重いという情報がでてきます。一時期自分で使いましたが、そのときは重いというほどの影響はありませんでした。

大きな特徴が、HTML特殊文字の変換が不要な点。HTML特殊文字(例えば「<」など)もそのまま変換いらずでWordpress投稿として保存してOK。クライアントから表示リクエストのタイミングでプラグインが変換してくれます。余計な変換の心配をしなくていいので楽チンなはずです。

WordPressプラグイン「SyntaxHighlighter Evolved」

同様にワードプレスのプラグインSyntaxHighlighter Evolvedを使う方法。
公式：SyntaxHighlighter Evolved

使ったことはないので詳細は知りません。Crayonと同じくワードプレスのSyntaxHilightプラグインとしてはかなり有名なようです。そもそも、Wordpressプラグインを使うか自体難色気味な部分はあるので、まずCrayon Syntax Hilighterから考慮してみることにして、こちらは調査不足です。すみません。

Prism.jsの利用

必要なシンタックスハイライトを選択して、専用にカスタマイズされたjs(javascript)とcssを出力して配置して利用するPrism。
公式：Prism

主だった言語は揃っていますし、テーマやカラーリング、行番号表示など、上記のプラグインにも劣らない機能が揃っています。

特徴は以下です。

• WordPressフレームワーク依存なし
• HTML特殊文字の変換が必要

Crayon Syntax Hilighterと比較して、大きいのがHTML特殊文字変換が必要となる点。例えば「<」は「<」と記述して投稿する必要があります。

考慮すべき事項

というわけで、主な選択肢は、プラグイン「Crayon Syntax Hilighter」か「Prism.js」を使うか。どう選択するか、考慮することは以下の4つです。

• HTML特殊文字の置き換えをどのタイミングで行うべきか
• 執筆のしやすさ
• カスタマイズ性
• 負荷

HTML特殊文字の置き換えをどのタイミングで行うべきか

大きな特徴は、HTML特殊文字の変換処理に違いがあることです。これが結構ベースの問題なので真面目に考えるべきです。

考えるポイントは以下。

• 特殊文字変換を手間なく済ませたい
• オフラインでできる変換処理は事前に終わらせておくべき
• HTML記事単体として成り立つ形で保存が望ましい

まずいちいち自分の手で<を<に書き換えて書く、なんてやってられるわけがないので、この変換の短縮は必須です。その点を考えると、Crayonなどのプラグインの方がよさそうに思えます。が、特殊文字変換自体は、他にやりようがあります。変換機能を提供しているサイトもありますし、今回だとMarkdownからHTML変換時に自動で変換できます。ということで、特殊文字変換の手間の点ではどちらでもよいです。

Crayon Syntax HilighterとPrismでは、特殊文字変換をしてくれるかどうかも違いますが、その処理タイミングも大きく異なります。Crayon Syntax Hilighterの場合、クライアントからリクエストがあってはじめてサーバーサイドで処理され変換が行われます。対して、HTML記事として保存する時点で変換が行われている場合、クライアントからリクエストされた時点で既に変換が完了しており処理負荷が減ります。基本的にオフラインでできる処理は事前に済ませておくべきです。ということで、基本は事前変換が望ましいです。

そして、これも同様ですが、Crayon Syntax Hilighterのようにリクエスト時点で解釈する場合、HTML記事単体では、特殊文字変換がなされていないので、HTMLの内容としては記事として成立していない状態です。これはよろしくないです。同様に事前変換の方が望ましいです。

執筆のしやすさ

既に上で述べましたが、特殊文字をいちいち変換などしていられません。その点で、プラグインはいたせりつくせりで、デフォルトで特殊文字など何も気にせず書ける環境が整います。大事なのは、特殊文字を何かしら簡単に変換できるフローが作れることです。今回は上記したとおりどちらでも自動変換フローが組み込めます。

他に書きやすさでいうと、HTMLタグを書くか、Markdown式記述をするかどうか。

Markdownでコードブロック指定で書くと、特殊文字の変換が走るため、Crayon Syntax Hilighterを使う場合、おかしなことになります。MarkdownからHTML変換時に特殊文字変換したコードを、またプラグインが特殊文字変換しようとしてしまうことになるのです。結果<は、クライアントでも<と表示されてしまう結果となります。つまり、Crayon Syntax Hilighterを使う場合、Markdownのコードブロック表記は使えず、HTMLタグ指定で書くことになります。

それを踏まえて、HTML表記とMarkdown表記のしやすさを比較します。

HTMLで書く場合の例

<pre><code>
    int a = 0;
    a++;
</code><pre>

Markdownで書く場合の例

~~~
    int a = 0;
    a++;
~~~

やっぱりMarkdownの方が簡単ですよね。HTMLを書きやすくしてくれているのがMarkdownなので当たり前といえば当たり前ですが笑。まぁHTMLタグでもスニペット等を活用すれば苦なく書けるとは思いますが、Markdownの方が簡単です。

カスタマイズ性

必要なカスタマイズ性は、行番号表示や、テーマ変更、一部行ハイライトなどかと思います。この程度の設定は双方にありますので、どちらでも申し分ありません。細かいカスタマイズが必要な場合しっかり調査しましょう。

負荷

負荷に関しては簡単に触れたとおり、Wordpressプラグインは重くなりがちなことと、Crayon Syntax Hilighter自体機能が豊富なものを全部ロードするため、ただのコードブロック表示にしては負荷は高めなようです(実際に使ってみてるときは気になりませんでしたが)。少なくとも、Prismは必要な言語、機能を自分で選択したミニマイズ版を作成できるので、ロードするサイズ自体小さいです。また、Wordpressプラグインという形ではなく、JavascriptとCSSを追加するだけなので、明快な軽い負荷で済んでいることがわかります。

Prism.js キミに決めた

ということで、ここまで述べてきた内容を総じて、Prism.js、キミに決めた！

一番大きいのは、Crayon Syntax Hilighterは特殊文字変換を気を利かせて？クライアントからのリクエスト時まで行わないようにしているのが、むしろ自分の思想とは合わなかったという点ですね。Crayon Syntax Hilighter自体は、機能豊富ですし、特殊文字変換をこの環境であれば気にしなくていいようにできているので、お手軽にコードブロックをきれいにするには良いと思いますよ。

というわけで、以上、本サイトはPrism.jsを使ったSyntaxHilight、コードブロック表示に切り替わりました。

実はその前はCrayon Syntax Hilighter使っていたので、既存の記事のコードの特殊文字変換を自前ですることになった・・疲れた・・。