WordPressでダブルクォートなどの文字が自動変換?原因と対処方法
2017/03/11
ダブルクォート、シングルクォート、HTMLタグが自動変換される?
文字が自動変換されるパターンを分類
WordPressには自動的に変換される文字が存在します。
具体的には下記のような感じです。
"ダブルクォート"
と入力しているにもかかわらず、
“ダブルクォート”
となってしまいます。
上記の文字列をテキストエディタなどにコピペしていただくと全角の文字に変わっていることが分かると思います。
これくらいであればまだかわいい方だと思いますが、このような形で、入力した形式とは違う形に自動で変換され、入力した際の想定と違う表示のされ方をすることもあり、思わぬトラブルになってしまうこともあります。
例えば、このダブルクォートは見た目は大した違いはありませんので普通に文章を読むのには全く問題はありませんが、全角に変換されているため、WordPressに編集されている PHPのソースなどをコピペしてそのまま使おうとするとエラーになります。
プログラムソースの中に全角文字が入っているわけですので、動くはずがありません。
でも、ブログで紹介しているわけですから、デバッグしている、そのままで動くと思ってコピペするわけですので、エラーの原因がなかなか見つけられない....
そして、「なんだよ、このブログのソース、役に立たないじゃないか!」「このサイト役に立たないじゃないか!」と思われてしまう原因になったりするのです。
今回は、このような WordPressの自動変換機能についての説明と、その解決方法を解説していきます。
今回の記事で解説する WordPressの自動文字変換機能は下記の 2つのパターンです。
パターン1:見やすくするために勝手に変換されるもの
パターン2:XHTMLに準拠するために変換されるもの
それ以外にもいくつかパターンがありまして、全てのまとめ記事として「WordPressの記事編集で文字が自動変換される要注意な文字列」という記事を書いています。
また、「¥」円マークが「\」バックスラッシュに変わることに関しては「WordPressで ¥円マークが \バックスラッシュになる原因と対処方法」にもそれ専用の詳細解説記事を書いていますので参考にしてください。
見やすくするために勝手に変換されるもの
パターン1としては、先に書いたダブルクォート(")の様に変換されるもので、下記のようなものが自動的に変換されます。
下記の文字列をテキストエディタなどにコピペしていただくと全角の文字に変わっていることが分かると思います。
& アンパサンド(&)
— ダッシュ(-)3連続
… ピリオド(.)3連続
“” ダブルクォート("")
” シングルクォート(′′)
Let’s シングルクォート(′)
123×456 掛け算・エックス(123 x 456)
タイトルに「見やすくするために」と書きましたが、本当のところはなぜこのような自動変換の処理が入っているのかは分かりません。
考えられることとしては、WordPressの開発者の方々はこれらを自動的に変換してあげる方が親切だと思っているのではないか、思います。
XHTMLに準拠するために変換されるもの
パターン2として、特定の HTMLタグは入力しても受け入れない、もしくは、自動的に変換するという WordPressの仕様に基づいて処理が実行されるものがあります。
具体的には
「<br>」 は 「<br />」に
「<hr>」 は 「<hr />」に
自動変換されます。
また、
「<title>~</title>」
「<category>~</category>」
は削除されます。
これらは、WordPressが XHTMLに準拠した HTMLソースを生成することを前提に作成されていますので、それに基づいて処理されています。
また、数値文字参照も下記の様に変換されています。
「€(€)」 は 「€」 に
「‚(‚)」 は 「‚」 に
「ƒ(ƒ)」 は 「ƒ」 に
「„(„)」 は 「„」 に
「…(…)」 は 「…」 に
「†(†)」 は 「†」 に
こちらは、Unicodeの文字を有効範囲内のものにするために自動変換されているものですが、上記はほんの一部で大量にありますので、詳しく知りたい方はプログラムのソースを確認してみてください。
自動変換される処理について
自動変換される理由は、WordPressの関数の中で自動変換される処理が組み込まれているからです。
これらの変換する処理は、「/wp-includes/formatting.php」のファイルの中にあり、前者の「見やすくするために勝手に変換されるもの」を「wptexturize」関数で、後者の「XHTMLに準拠するために変換されるもの」を「convert_chars」関数で実施しています。
そして、これらの処理は、入力された情報に対して保存をする際に何かの処理が実施されているわけではなく、画面表示の際に実行されていますので、入力しているテキストを更新しようとしたら別のテキストに自動変換されていた、ということはありませんのでご安心ください。
自動変換されることへの対処方法
その1・文字参照を使う
変換される文字をテキストとして入力せずに文字参照として入力することで、自動変換されることを防ぐという方法があります。
文字参照(数値文字参照、文字実体参照)に付いては「数値文字参照コード変換ツール(HTML特殊文字コード変換ツール)」に記事を書いていますのでそちらを参照してください。
具体的には、下記の様に文字を置き換えます。
アンパサンド(&) は 「&」と入力します。
ダブルクォート(") は 「"」と入力します。
シングルクォート(′) は 「′」と入力します。
タグの部分は、タグとして表現したい場合は、下記の様に置き換えます。
不等号(より小)(<) は 「<」と入力します。
不等号(より大)(>) は 「>」と入力します。
※タグとして使う場合は「<」の方だけ「<」に置き換えれば、「>」の方は変換しなくても問題ありません。
その他、下記の様にあらゆる文字を文字参照として入力することで変換されないようにすることが可能です。
エックス(x) は 「x」と入力します。
ハイフン(-) は 「-」と入力します。
ピリオド(.) は 「.」と入力します。
また、文字参照のコードは、 http://e-words.jp/p/r-htmlentity.html などに文字参照(特殊文字)のコード一覧を見ると確認できます。
ただ、ここに載っていない文字も多数あります。
というか、そもそもすべての文字にこの数値文字参照は割り当てられていますので、載っていない文字や探すのが面倒な方用に数値文字参照の変換ツールを用意しましたので、下記のページも参考にしてください。
数値文字参照コード変換ツール(HTML特殊文字コード変換ツール)
数値文字参照全コード表
この方法のメリットは、WordPress自体に特に何か修正を加える必要がなく、投稿する記事の文字を変換するだけで想定通りの表示をさせることができる点です。
また、「<」を「<」と入力する方法は、一般的な HTMLファイルを作成する際も利用する方法ですのでなじみもある方もあるでしょう。
この方法のデメリットは、文字ごとに文字参照のコードを調べる必要がある点です。
また、どの文字が変換されているかを理解していないと、記事の投稿が終わった後、自動変換された文字がないか、一文字ずつチェックをする必要がある点です。
※「文字参照」には「数値音字参照」と「文字実体参照」がありますが、どちらでも問題ありません。
また、このブログではこの文字参照を利用する方法を使っています。
その2・<pre>タグ、<code>タグを利用する
入力したものをそのまま表示する HTMLのタグとして、<pre>タグ、<code>タグがありますが、WordPressもその機能が有効に働きますので、<pre>タグ、<code>タグを利用するという方法があります。
【<code>タグを使った場合】
--- ダッシュ連続
... ピリオド連続
"aa" ダブルクォート
'bb' シングルクォート
Let's シングルクォート
123x456 掛け算
【<code>タグを使わない場合】
— ダッシュ連続
… ピリオド連続
“aa” ダブルクォート
‘bb’ シングルクォート
Let’s シングルクォート
123×456 掛け算
非常に分かりにくいですが、表示されている文字列をテキストエディタなどにコピペしていただくと、半角が全角に変換されていることが分かると思います。
このように <code>タグ、<code>タグで囲むだけで入力された文字は置換されずにそのまま表示されます。
ちなみに、<pre>タグは、入力した通りに表示するためのタグで、<code>タグはプログラムソースなどのコードを編集するためのタグです。
微妙な違いはあるものの、見た目は同じになることも多いですので、好みで選んでも問題ない場面は多いでしょう。
この方法のメリットは、タグで囲うだけで入力した文字をそのまま表示しますので、文字参照のコードを調べる必要もない点です。
この方法のデメリットは、<code>タグで囲んだとしても「<br>タグ」「<title>タグ」は自動変換されてしまう点です。
そもそもそれらのタグはそのまま利用できないようになっていますので仕方がないことですが、タグを表示させたい場合は「<」を文字参照で置き換える必要があります。
また、テーマによっては <pre>タグ、<code>タグに対して文字色や背景を変えるといった編集がされる場合もありますので確認が必要です。
ちなみに、私がこの方法を選択しなかった理由は、この記事を書くまでこの方法に思いが至らなかったからです。
また、このブログの様に HTMLファイルや PHPのプログラムソースを提供する場合は、プラグイン「Crayon Syntax Highlighter」を利用することをおススメします。
このプラグインはこのページでも使っていますが、ソースを見やすく編集してくれますので非常に便利です。
ただ、「Crayon Syntax Highlighter」で HTMLや PHPのソースをキレイに編集する際に使われるタグも <pre>タグですので確認が必要です。
「Crayon Syntax Highlighter」については「WordPressのCrayon Syntax Highlighterの使い方」に記事を書いていますので、そちらを参考にしてください。
その3・自動変換している関数を止める
WordPressの関数で自動変換していることが分かっているので、その自動変換処理を根本的に止めてしまおう、という方法です。
先にも書きましたが、この自動変換する処理は「/wp-includes/formatting.php」のファイルの中にある、「wptexturize」関数、「convert_chars」関数で行われています。
これを止めればいいわけです。
ただ、「/wp-includes/」フォルダは WordPressのコアファイルが入ってフォルダですので、このフォルダの中のファイルを直接編集してはいけません。
このフォルダの中は WordPressのバージョンアップのたびに上書きされてしまいますので。
ではどうするかというと「functions.php」に処理を止めるプログラムを記述します。
functions.phpがある場所は下記になります。
/{WordPress}/wp-content/themes/{テーマ名}/functions.php
詳しくは、「WordPressの functions.phpがある場所」に書いていますので合わせて参照してください。
具体的に記述する内容は、下記の内容です。
これを functions.phpの一番下あたりに追記してください。
1 2 |
remove_filter ( 'the_content', 'wptexturize' ); // wptexturizeによる文字列変換を止める remove_filter ( 'the_content', 'convert_chars' ); // convert_charsによる文字列変換を止める |
この記述では、記事本文の自動変換だけを止める設定になります。
その他は、以下の記述を参考にしてください。
1 2 3 4 5 6 7 8 9 |
remove_filter ( 'the_content', 'wpautop' ); // すべての文字変換を止める remove_filter ( 'the_content', 'wptexturize' ); // wptexturizeによる文字列変換を止める remove_filter ( 'the_title' , 'wptexturize' ); // タイトルの文字変換を止める remove_filter ( 'the_excerpt', 'wptexturize' ); // 抜粋部分の文字変換を止める remove_filter ( 'comment_text', 'wptexturize' ); // コメントの文字変換を止める remove_filter ( 'the_content', 'convert_chars' ); // convert_charsによる文字列変換をしない remove_filter ( 'the_title' , 'convert_chars' ); // タイトルの文字変換を止める remove_filter ( 'the_excerpt', 'convert_chars' ); // 抜粋部分の文字変換を止める remove_filter ( 'comment_text', 'convert_chars' ); // コメントの文字変換を止める |
この方法のメリットは、どのような文字変換が行われているかを知る必要がなく、一度設定するとそれ以降自動変換のことを気にせず投稿することができる点です。
この方法のデメリットは、functions.phpファイルを編集しますので、プログラムの編集をしたことがない方にとっては、心理的なハードルが高い作業であることは否めません。
また、個人的には、「wptexturize」の関数の自動変換は見た目をよくするために変換されているのだと考えていますが、違う何か特別な理由でこの自動変換処理が実装されている場合は、その恩恵を受けることができなくなるというリスクがありますので、関数を止めることは避ける方がいいのではないか、と考えています。
今のところ、そのリスクは思いつきませんが...
また、「convert_chars」は、XHTMLに準拠する HTMLを生成するための変換が行われている関数ですので、こちらは止めない方がいいでしょう。
WordPressで入力文字が自動変換される原因と対処方法のまとめ
WordPressが自動変換する文字を自動変換されないようにする対処方法ですが、今回紹介した 3つの対処方法以外にもいくつか対処方法が存在します。
例えば、この自動変換を止めるプラグインが提供されていますので、そのプラグインを利用するという方法。他には、一度変換された文字列を再び元に変換し直す関数を作成するという方法。などです。
ですが、いずれも今回紹介した対処方法以上のメリットを見出すことはできないため、紹介しても意味がないと判断しました。
最後の 3番目の方法は一度設定してしまえばそれ以降気にする必要がありませんので、プログラムの編集を苦にしない方は一番楽な方法だと思います。
ただ、個人的には、なんでこんな変換を実施しないといけないのかが分からないため、果たして止めていいのだろうか?という疑問を感じてしまいます。
自動変換する機能があるならば、それを「On/Off」で切り替えられる設定を「一般設定」などに追加してもらえればもっといいのにな、と思うわけで、なんでそれをしないのだろう、と不思議に思っているわけです。
なんでなんでしょうね?ご存知の方、教えてください!
GoogleAdwords
GoogleAdwords
この記事が参考になったと思いましたらソーシャルメディアで共有していただけると嬉しいです!
関連記事
-
Theme My Loginでメール認証、管理者承認付の会員管理・基本編
会員管理をするプラグインTheme My Loginの解説。メール認証、管理者認証、reCAPTCHAによるいたずら登録を防止し、ログイン攻撃対応のセキュリティも備わっている。
-
タクソノミーの一覧をショートコードで編集・ソート機能付き・wp_list_categories
カスタムタクソノミーのターム一覧をショートコードで編集する方法の解説です。Category Order and Taxonomy Terms Orderを利用してソート機能を追加したバージョンです。
-
WordPressの投稿データ(記事データ)の管理方法
投稿の登録の方法、投稿データの管理方法の解説。MetaManagerなどのプラグインを入れた場合の入力ボックスを表示させる方法についても解説します。
-
Advanced custom Fieldsのフィールドグループを簡単に複製する方法
Advanced custom Fieldsのフィールドグループの複製の方法の解説。XMLのExport、インポートする機能を利用して複製します。
-
FC2からWordPressに引越でcanonicalとmeta refreshで転送設定
FC2からWordPressに引越する際の転送設定はcanonicalとmeta refreshの設定でユーザへもGoogle検索エンジンにも引越し情報を伝えられます。
-
WordPress データベースを管理するための強い味方のプラグイン WP-DBMANAGER
データベースを管理するための強い見方のプラグイン「WP-DBMANAGER」の使い方の説明です。
-
WP Multibyte PatchでWordPressの管理画面のイタリック体を解消
管理画面の一部の文字がイタリック(斜体)になっているのはプラグイン「WP Multibyte Patch」が有効になっていないためです。日本語を使うには必ず有効化しましょう。
-
DuplicatorでWordPressを簡単引越し!インストーラー付のバックアップにも
WordPressの引越しや開発環境から本番環境への移行など他の環境に移す作業を簡単にしてくれるプラグインの紹介。インストーラー付のバックアップツールとしても使る。
-
Export to Textで WordPressを csv出力
WordPressのデータを csv出力する Export to Textの使い方を解説しています。
-
自サイト内のリンクをショートコードで指定する・アンカーリンク対応版
自サイト内の記事にショートコードで自動リンクを設定する関数のソースコードを提供。Post ID、slugで指定でき、アンカーリンクを設定する場合も対応。