標準の AZ、az 文字だけでなく、ハイフン、全角ダッシュ、引用符などもあります。
さらに、ウムラウトなどのすべての国際文字があります。
では、英語ベースのシステムの場合、完全なセットは何でしょうか? 他の言語のセットはどうですか? UTF8、UTF16などはどうですか？
おまけの質問: 必要な名前フィールドの数と、それらの最大長はどれくらいですか?
編集:人の名前には、文脈の一部として存在するものと、構造上の理由から存在するものの 2 種類の文字が含まれていることは間違いありません。コンテキスト文字を制限したり干渉したりしたくありませんが、構造的な文字を処理する必要があります。
たとえば、全角ダッシュで区切られた名前が入ってきましたが、マイナス記号と区別するのが困難でした。システムを検索しやすくするために、5 つの異なるタイプのダッシュをすべて取得し、それらを 1 つの一意の文字 (マイナス) にマッピングします。これにより、検索者は最初にどの記号が入力されたかを具体的に知る必要がなくなります。
問題はダッシュ、おそらく引用符にも存在しますが、他の記号はいくつありますか?
Personal names around the worldと呼ばれる W3C による優れた記事があり 、問題 (および考えられる解決策) をかなりよく説明しています (これはもともと、Richard Ishida による 2 部構成のブログ投稿でした:パート 1とパート 2 ) 。
個人的には、印刷可能なすべての Unicode 文字をサポートし、安全のために、完全なフォーマットされた名前を含む単一のフィールド「名前」のみを提供すると言います。このようにして、ほぼすべての形式の名前を保存できます。より構造化されたストレージが必要になるかもしれませんが、すべての組み合わせを構造化された形式で保存できるとは思わないでください。単にさまざまな組み合わせが多すぎるためです。
私に言わせれば、人の名前に現れる可能性のある文字をホワイトリストに登録するのは間違った方法です。確かに、[A-Za-z] は公正な出発点ですが、あなたが言ったように、「ヨーロッパ」の名前には問題があります。したがって、すべてのウムラウト、サーカムフレックスなどをマップします。中国人の名前はどうですか？日本？インド人？ヘブライ語？あなたは風力タービンとの戦いに突入しています。
誰かの名前の有効性を絶対に確認する必要がある場合は、特定の文字の控えめなブラックリストを作成することをお勧めします. 中括弧、数学記号、句読点などは無視しても安全です。しかし、私があなただったら、用心するでしょう。
入ってくるものは何でもそのまま受け入れるのが最善かもしれません.UTF-16は今日の過剰な文字セットであり、今後数年間は十分なはずです.
編集：名前の長さと名前の量についての質問について。本当に人々に本名と完全な名前を書いてもらいたいのなら、これらの両方の質問に対する唯一の絶対確実な答えは「無限」だと思います。人間の実際の例を特定することはできませんが、バンコクの都市のネイティブ名として、人間の類似例が確かに存在します。
決定的な答えはないと思います。結局、UTF-16でも表現できない名前を持っている人がいます...
変な句読点や母国語にはないアクセントなどを入れて、自分の子供にとんでもない名前を付ける人もいます。
ただし、データベースに任意の制限を加えることができます。必要に応じて、7 ビット ASCII 名を主張できます。ユーザーには少し失礼ですが、ユーザーはそれを受け入れます。確かに検索はしやすいです。
同僚の娘の名前はアメリです。しかし、一部の (すべてではない!) 英国政府の公式 Web サイト (「出生証明書に記載されている名前を正確に入力してください」) でさえ、Unicode を受け入れないため、代わりに「Amelie」を使用する必要があります。
私は米国の自動車教習所向けのソフトウェアを作成しているので、私にとって最も重要なことは、州の DMV が運転免許証の正式名称として何を認めているかということです。私の場合、同じ名前を後で運転免許証に使用する必要があるため、そのような名前が合法であっても、DMV が許可する範囲を超える名前を許可すると問題が発生します。
StackOverflow から、必要な答えをまだ確認していませんでした。そして、私の州 (カリフォルニア) では、おそらく COBOL で書かれたソフトウェアで AS400 を使用していることをたまたま知っています。私の知る限りでは、それらは 8 ビット文字セットしかサポートしていません。(EBCDIC ですか?) とにかく... うーん。
それで、私はカリフォルニアの DMV に電話しました... 案の定、彼らのシステムでは AZ とスペースだけが許可され、それ以外はまったく許可されていません。ハイフンも使用できません。ハイフンはスペースに置き換えられます。実際、どうやら難しいようですが、大文字しか使用していません。また、「O'Malley」などの名前は OMALLEY に置き換える必要があります。
政府に任せましょう。DMV で働く開発者ではないことに興奮していると言わざるを得ません。（その程度の給料なら本当に使えますが。）
8 ビットの任意の倍数 (0 より大きい) で表すことができる任意の文字は、人の名前の可能な文字です。名前とエンコーディングの両方の長さは任意であるため、上限を考慮する必要はありません。
ボビードロップテーブルがほとんど取得されないように、データベース入力を必ずサニタイズしてください。
名前フィールドの問題については、さまざまな理由から、間違った答えはファースト ネーム、ミドル ネームのイニシャル、ラスト ネームなどです。
多くの人はミドル ネームで知られており、正式には名のイニシャル、ミドル ネーム、姓の形式を使用します。
一部の文化では、姓が名で、名が姓です。
複数のファースト ネームやミドル ネームが一般的になっています。@Dour High Arch が指摘しているように、もう一方の極端な例は、名前に単語が 1 つしかない人です。
オブジェクト指向データベースでは、ディレクトリ スタイルまたはシグネチャ スタイルの名前を返すメソッドを使用して Name オブジェクトを格納します。バッキング ストアには、これらのメソッドをサポートするために必要なあらゆるデータが含まれます。
ディレクトリ形式の名前と署名形式の名前の 2 つの可変長文字列のモデルを改良したリレーショナル データベース モデルはまだ見たことがありません。
それは本当にアプリが何のために使われることになっているのかに依存します。
確かに、理論的には、神の緑の地球上のすべてのスクリプトを使用できるようにすると素晴らしいのですが、DBがサポートスタッフによっても使用されている場合、日本語、ヘブライ語、タイ語のスクリプトで名前を処理できるようになりますか？郵便料金ラベルの印刷に使用されている場合、印刷できますか？
「ラテン文字起こし」というフィールドを追加することもできますが、IMOではISO-8859-1文字に制限してもかまいません。ラテン文字を使用しない人は、今では文字起こしを使用しなければならないことに慣れています。彼らが筋金入りの民族主義者でない限り、もう気にしないでください。
名前フィールドに関しては、UTF-8 で十分です。少なくとも名前と姓が必要です。
「かつて王子様だったアーティスト」を持っているとき、あなたは何をしますか。彼が使用したその記号は、Unicode セット (AFAIK) の文字ではありません。
それはいくらか妥当ではありますが、同時に、名前はかなり広い概念であり、構造化された形式には適していません。この場合、自由形式のものが最も適切かもしれません。
名前構造の複雑さに応じて、次のことがわかります。