国際化されたマルチプラットフォームアプリで入力可能な文字を制限する必要がありますか？
モバイルアプリとウェブサイトをリリースし、英語を話すユーザーと英語を話さないユーザーが利用できるようにするとします。
技術スタック全体ですでにUTF8エンコーディングをサポートしています。しかし、UTF8で表現可能な文字の全範囲をユーザーが入力できるようにすることは、一般的に適切なポリシーですか？そうでなければ、どうやって人々は
特に：
- ユーザー名
- パスワード
- ユーザーが作成したコメント
（タッチスクリーンキーボードを介して）1つのデバイスで入力文字として提供される場合があり、別のデバイスで同じ文字を再入力してレンダリングする必要があります。
例えば、
フォーラム投稿。こちらがスカルとクロスボーンの文字「☠」（UTF 9760）です。一部のサードパーティのAndroidキーボードは、入力するのに簡単な方法を提供しますが、ブラウザで正方形のボックスとしてレンダリングされる場合があります。一般に、異なるデバイスで異なるフォントを使用する場合があります（たとえば、高ppiデバイスと低ppiデバイスでは異なるフォント）。そのため、ユーザーが1つのデバイスで自由にテキストを入力できる（正しく表示される）リスクがあります。その同じ文字は、代替フォントの別のデバイスではレンダリングできません（= UXは失敗します）。そのため、フォーム検証を通じてそのような文字の入力を防止することは賢明なようです。もしそうなら、許容される文字のセットは通常どのように決定されますか？ （たとえば、一般的なWebセーフフォントで使用できる文字の大きなリストがあります）。
新しいパスワードを作成する場合、Androidキーボードは、¥（円）文字を入力するように人々に促します。ただし、これを許可すると、ほとんどの米国のユーザーは、キーボードに¥を入力する明確な手段がないPCで同じサービスにログインするときに行き詰まります。 Oops-UXが失敗しました。
私はASCIIで生活しました。ここでのベストプラクティスは何ですか？
非常に正当な理由がない限り、制限するべきではありません。ユーザーは時々、予期せぬ方法でイノベーションを起こすことができます（テスト用のティーバッグがあり、消費者はそれをそのように求め始めたと言われています）。
- コメント：大きなNOですが、システムで非常に奇妙な使い方をしている場合を除きます。スペイン語（ソクラテス）でギリシャ人（ソクラテス：Σωκράτηςなど）について話すことができます。または、式を記述したい場合もあります：∃n∈ℕP（n、n、25）
- その後、何かが迷惑になった場合（ユーザーが一部のUnicode機能を悪用する場合）は、いくつかの制限を適用できます。
パスワード：想像できる唯一の欠点は、ユーザーがパスワードを繰り返すことができないことです。この場合、メールでパスワードをリセットできます。
または、オンスクリーンキーボードを提供できます。これには次のような利点があります。
- キーの順序をランダムに変更し、一部の キーボードとマウスのロガー を回避できます。
ユーザー名：ここには、十分な理由があります（ユーザーが他の名前を模倣している）。したがって、いくつかの種類の制限を実装できます。
- ラテン語のみ：ユーザーには不向き、簡単にできます。互換性に優れています（ユーザー名をメールアドレスとして使用したり、GoogleやGMailとして使用したりできます）。
- 1つの言語のみ：サポートされているすべての言語で許可されているすべての文字のリストが必要です。
- 類似性による衝突を回避します：これはユーザーにとってもbetterできるためです。サウンドの類似性（ralfとralph）、視覚的な類似性（RALPHとRAL9H）、および文字の並べ替え（ralfとrlaf）を実装します。しかし、それは複雑な作業です。
UTF-8の目的をよく理解していないと思います。これは、あらゆる種類の文字を格納できるようにする単なるエンコーディングです。エンコーディングの選択はより技術的な決定であり、多言語アプリケーションを作成していてUTF-8を選択できるため、必要なエンコーディングのように見えます。
データベースやファイルシステムに関連するエンコーディングではなく、ユーザーに何を表示するか、何を受け入れるかを決定するのはアプリケーションです。ファイルシステムを変更するのは容易ではありませんが、アプリケーションの動作は定期的に変更される可能性があるため、UTF-8は、後で制限や問題を回避するための最良の選択です。
アプリケーションレベルの検証とフィルターを使用して、ユーザーとアプリケーション間のデータを制御します。