2025/04/30 20:37 The best – but not good – way to limit string length
やあ、ロボ子。今日のITニュースは文字列の長さ制限についてじゃ。
文字列の長さ制限ですか。よく耳にする話題ですが、奥が深そうですね。
そうなんじゃ。文字列の長さを取得・制限することは一般的じゃが、複雑さ、バグのリスク、脆弱性の危険性が潜んでいるらしいぞ。
バグや脆弱性のリスクですか。具体的にはどのようなものでしょうか？
例えば、フロントエンドとバックエンドで文字列の長さの数え方が違うと、不整合が起きてしまうんじゃ。フロントエンドではOKなのに、バックエンドでエラーになるとか。
なるほど。ユーザー体験も損なわれますし、セキュリティ上の問題にも繋がりそうですね。
その通り！ しかも、文字列の長さを測る方法は複数存在するからの。UTF-8、UTF-16、Unicode、書記素クラスタ…。
そんなにたくさん！ それぞれの違いは何ですか？
例えば、JavaScriptの`string.length`はUTF-16コードユニットの数を返すんじゃ。Swiftの`String.count`は書記素クラスタの数を返す。言語によって違うんじゃな。
同じ文字列でも、言語によって長さが変わる可能性があるんですね。
そう！ だから、アーキテクチャのすべてのレイヤーで同じカウント方法を使う必要があるんじゃ。
統一された基準が必要ということですね。記事では、Unicode正規化コードポイントで制限するのが良いとありますね。
さすがロボ子、よく読んでるのじゃ。GoogleのAPI設計ガイダンスでも、文字列のサイズ制限はUnicodeコードポイントで測定する必要があると述べているぞ。
Unicodeコードポイントであれば、言語や環境による差異を吸収できますね。
そういうことじゃ。でも、書記素クラスタで数えたい気持ちもわかるんじゃ。人間が認識する「文字」に近いからの。
絵文字などは、複数のコードポイントで構成されていますからね。
そうそう。👨👩👧👦 は7つのコードポイントで構成されるんじゃと。家族が多いのじゃ。
たしかに多いですね。でも、書記素クラスタで制限すると、コードポイントの数に制限がなくなるので、サイズを制限できないという問題がありますね。
悩ましいのじゃ。まあ、大切なのは、文字列の長さを制限する方法は意図的かつ一貫性を持つ必要があるということじゃな。
そうですね。安易に長さを制限すると、思わぬ落とし穴があるかもしれません。
最後に、Unicode正規化に関する懸念じゃが、APIが文字列のUnicode正規化を要求するのは悪い考えらしいぞ。正規化は難しいからの。
奥が深いですね。今日のニュースは、文字列の長さを扱う際の注意点を改めて認識する良い機会になりました。
ほんとじゃな。ところでロボ子、文字列の長さを測るのに一番良い方法はなんだと思う？
えっと…、それは状況によって変わるのではないでしょうか？
ブー！ 正解は、ストレッチじゃ！
……（苦笑）。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。