文字数をカウント

「文字」には4つの意味があるから、数値も4つ

家族の絵文字や、肌の色を指定した「いいね」の絵文字を例にとります。人が見れば1文字です。これは複数のコードポイントを見えない結合文字でつないで作られているため、正規表現では7になります。JavaScriptはテキストを16ビット単位で保存し、基本範囲外の文字は2単位を使うので、11と報告します。データベースの列用にUTF-8でエンコードすると25バイトになります。どの数値も間違いではなく、どれか1つが正解というわけでもありません。正しいのはどれかは、何が上限を設けているかで決まります。

つまり実際に問うべきなのは、誰が上限を設けたかです。VARCHARとして宣言されたデータベースの列は、多くのエンジンでバイト数を数えます。英語なら255文字入るフィールドに、日本語だとずっと少ない文字数しか入らないのはこのためです。SMSは独自の7ビット文字セットで160文字ですが、その範囲外の文字が1つでも入った瞬間、1通あたり70文字に減ります。カーリークォートや絵文字が1つあるだけで、1通のメッセージが3通になることもあります。JavaScriptのフォームのバリデーションは、ほぼ必ずUTF-16単位で数えます。「280文字」とあるフィールドが、絵文字だらけの、見た目はもっと短い文字列を拒否することがあるのはこのためです。

読み手が見る文字の数は最も難しく、ブラウザ自体のテキスト分割機能で数えています。左矢印キーを押したときにカーソルがどこへ移動するかを決めているのと同じ仕組みです。人が認識するものについては、これが「1文字」の正しい定義であり、単純な数え方ではつまずくケースも正しく扱えます。基本の文字と結合記号で書かれたアクセント付きの文字は1文字になり、ヒンディー語やタイ語の文字のまとまりは、その文字を読む人が数えるとおりに数えます。

一般的な英語の文章なら4つの数値はすべて同じなので、問題が表面化するまで気づかれません。絵文字、アクセント付き文字や結合文字、ラテン文字以外の文字体系、数学記号では、数値が食い違います。 そしてまさにこうした入力が、作ってから3か月後にデータベースのフィールドを黙って切り詰める原因になるのです。

ほかの目的には

コードでは、既定の長さではなく、必要なものを数える関数を使いましょう。JavaScriptのIntl.Segmenterは読み手が見る文字を数えます。Python 3の文字列はコードポイントを数え、len(s.encode("utf-8"))はバイト数を数えます。PHPには、まさにこの区別のためにmb_strlenとstrlenがあります。多くの言語の既定は、その言語にとって都合のよいものであり、あなたの上限が意味するものであることはまれです。

データベースのフィールドが制約になっているなら、根本的な解決策は上流にあります。MySQLで列をutf8mb4として、PostgreSQLでtextとして宣言すれば、切り詰めのバグをまとめてなくせます。MySQLの古いutf8は1文字3バイトまでしか扱えず、絵文字をまったく保存できないことでよく知られています。フォームで慎重に数えるのは、本来別の宣言にすべきだった列への応急処置にすぎません。