『～』という文字が入った日本語のタクソノミーをget_term_by()関数で”name”検索してもヒットしなくて小一時間悩みました。
『～』という文字は機種依存文字でも環境依存文字でもないので、なんで？？と思ったのですが、実は同じ見た目の文字が他にもあることがわかりました。
『～』という文字は2種類あった。
こちらのサイト でUnicode(UTF-8) へ変換してみると
波ダッシュ：U+E3809C
全角チルダ：U+EFBD9E
となっているので見た目はほとんど同じでも違う文字であるらしいです(そりゃそうだって感じかもしれませんが…)。
波ダッシュ（〜）と全角チルダ（～）は違う文字 | レコチョクのエンジニアブログ
大久保です。 今回はウェブフロントの技術とかではないけど結構な時間ハマっていた「〜」事件について。 書くことになったきっかけ APIに値を送る際に「〜」が入っている値だけエラーになってしまっていました...
techblog.recochoku.jp
今回の問題はなぜ起きた？
もともと、波ダッシュだったものが、DBに書き込まれるときに全角チルダに置き換わって書き込まれているようでした。
タームを作った時と同じ文字列（波ダッシュ）でプログラム内でクエリを作っているのですが、自動的に（全角チルダ）変換されたのでクエリに引っかからないという過酷状況になっていました。
見た目では区別がつかないので、urlencode()して初めて違いに気が付きます。
スクレイピングしてきた文字列でタームを作ったり、記事を作ったりしている時にその文字列でnameなどで検索しても引っかからなくなるので、結構困る問題かなと思います。
対処方法としては、文字コードを置き換えて対処するしかないので、以下のスクリプトをいじって対処する感じだと思います。
//WindowsのにょろをMacのにょろに置き換える
$str = str_replace(hex2bin("EFBD9E"), hex2bin("E3809C"), $str);あとは、日本語でクエリを発行せずに、逃げる方法があればそれを使った方が安定しますね。
まとめ
タームを自動的に登録していくような運用だと、どうしても日本語のまま登録することになります。そういう時に今回のような問題が起きやすいです。
slugでもnameでもそもそも文字数制限もあるので、結構悩ましい問題だと思います。
