Q&A
「問題・課題」どっちの文言も質問文にいれてるんで、年末だし許してください。
マルチバイト文字列をログイン ID にする時の課題を調査しています。
ざっくりと調べたところ
・🍣🍺とかハハパパの異なる文字列を同値判定する問題
・波ダッシュとかの異 OS での Unicode ちがうぜ問題
・文字数カウント問題
あたりがクリアできれば実装できそうだとあたりをつけましたが、他に考慮すべき事項はありますか？
波ダッシュ問題は、以下の文字列を想定しています。
文字 SJIS Unicode(Unix) Unicode(Windows)
～（ウェーブダッシュ） 8160 U+301C U+FF5E
－（全角マイナス） 817C U+2212 U+FF0D
￠（セント） 8191 U+00A2 U+FFE0
￡（ポンド） 8192 U+00A3 U+FFE1
￢（ノット） 81CA U+00AC U+FFE2
―（全角マイナスより少し幅のある文字） 815D U+2014 U+2015
∥（半角パイプが2つ並んだような文字） 816B U+2016 U+2225
昔、マルチバイト文字でもIDやパスワードを登録できるしていた会社で登録したユーザーさんが外字で登録したことを忘れていて、PCが変わったか、自宅からログインしようとしたがログインできず。サポート担当が何時間も付き合わされて大変だった、って聞いたことがあります。
同じような立場に立つことも考えましょう。
前提条件が不明です。
専用アプリなのかWebアプリなのか、一般公開なのか否か、実装できれば良いのか、実運用の検討まで必要なのか、ご提示をお願いします。
> Orlofsky さん
実事例、ありがとうございます。非常に興味深い。
多分この辺の話ですかね。。。
https://qiita.com/y-ken/items/d08eb7f66c8fb2fa7d21
> YT0014 さん
質問文を修正してみました。
オープンアクセスな Web システムのログインを想定しています。
運用課題まで現時点では踏み込むつもりは無かったのですが、実事例であれば興味深いので、お持ちであればぜひ教えてください。
Webでオープンの場合、日本語以外のマルチバイト文字の検討、実運用まで見据えるのなら簡体字圏などでの、漢字の識別の習慣まで検討の必要があるかと思われます。また、シングルバイト文字の許容の可否、シングルバイトを許容する場合、バックスラッシュなどの同コード異字への対応やウムラウト関連の文字化けなど、範囲を限定しないのならば、無数の課題があるかと。
入力に IME などが必要になるので、そのあたりにセキュリティー上の問題が出てきそうです。
> YT0014 さん
サービス提供は日本語圏向けなので、絞った方が良さそうですね。
日本語関連の unicode block と絵文字とか記号あたりを許可する感じでしょうか。。。利用可能範囲を絞るのが大変そうですね^^;
> Zuishin さん
IME の利用による問題がイメージできませんでした。
どのような脅威を想定する必要がありますか？
「問題」を3つ挙げてらっしゃいますが、そのような性質がマルチバイト文字にあるのはよいとして、ログインIDに使うに当たって具体的にそれらがどのような問題を起こすと考えていますか?
また、ログインIDは他人から見えますか? より具体的は、ユーザーが他ユーザーをログインIDを頼りに同定する場面は想定されますか?
> ikadzuchi さん
調査の方向性として、一意であることをどう担保するか？を中心に調べました。1,2 番目はそれで拾えた問題点です。別 ID なのに登録できないケースの発生等を問題視してます。あと、 Orlofsky さんの指摘にあるような同じ ID と思って入力しても、実際は違うというのも発生しそうです。
次にバリデーション観点で調べたのが 3 番目です。ID の文字数は適当なサイズで制限しておきたいのですが、その際、目視される文字数と異なる数で制限してしまうヤツを危惧してます。
今回の調査トリガーの案件では ID は他人からは見えない想定なのですが、質問自体は一般論としての回答を期待しています。「ユーザーが他ユーザーをログインIDを頼りに同定」するケースでの問題も教えていただけると助かります。
変換時に見えてしまったり、学習されてしまったりすることが考えられます。
また、IME の無い環境では ID を入力することができなくなるかもしれません。
日本語で変換していた場合、外国語の IME で入力するのが難しくなることも考えられます。
> Zuishin さん
パスワードのマルチバイトは今回は考えていないので、見えたり学習されたりは問題ないと思ってます。
（日本語）IME の無い環境は確かに調査してみる必要がありそうですね。
回答1件
0
思いつくままに。
同値判定はどのように判断するにせよ、全体にわたって一貫していれば問題は無いと思います。
「別 ID なのに登録できないケース」はそこまで問題でしょうか。「他の人に使われているんだなあ」となるだけだと思います。
例えば「日本語で使う文字」だけに絞るといった仕様は、困難です。日本語で使う文字は他の文字と混ざって分布しており、簡単に定義できるものではありません。手間を掛けてまで行う価値があるかは疑問です。
既存の例えばJISコードに含まれる文字という定義にするのはひとつの手ですが、どうしてもアレは使えるのにコレは使えないという一貫性を欠く状況は出ますし、OSごとのUnicode変換テーブルの問題もあります。
また、Unicode変換テーブルの違いに由来する、環境ごとに入力が困難な文字があります。例えばWindowsで全角チルダ、Macで波ダッシュはキーボードから容易に入力できますが、逆は困難です。複数の環境からログインすることを考えると、これらの文字は同一視するのが親切かもしれません。
文字数の定義は困難です。Grapheme Clusterが比較的見た目の文字数に近いですが、Unicodeのバージョンに依存するのでバージョンが変われば一貫性を損ないえます。
参考: C# 文字列のカウント(サロゲートペアで構成されている文字列)
長さの制限はより一貫性のあるUnicodeコードポイント数やバイト数で行ったほうがよいでしょう。全体で一貫していなければログイン不能な場合が生じます。
Unicodeには目視で区別できない文字列が無数にあるため、IDを目視で区別する運用では他IDへのなりすましを防げません。
目視で区別できない文字列をIDに使えないようにすることは、完璧に行うのはまず不可能と思いますが、それを意図したと思われる実装例で、Wikipedia系のユーザー名は書記体系の異なる文字を同時に使用できないようになっています。
例えば「Example」(すべて英字)に対する「Εxаmple」(ギリシャ・キリル文字入り)のようなものを弾くことができます。
文字の表示される横幅は予想外に広くなりえます。広い領域を確保しておくか、切り詰められる前提でUIを設計した方がよいでしょう。ただ、日本で使う文字に限れば正方形を超える横長の文字はほぼ存在しないと見てよいかもしれません。
縦幅も、文字によって行の上下に大きくはみ出します。
Unicodeコードポイント0x10000以降(UTF-16でサロゲートペア、UTF-8で4バイト)の文字は正常に扱えないプログラムがあります。最近は減ってきていますがまだ気をつけた方がよいでしょう。
Unicodeには非文字やサロゲートのように文字に割当てられないコードポイントがあったり、UTF-8にはUnicode範囲外や冗長なコードのように順当にコードポイントに割当てられないビットパターンがあったりします。これらは使用できるべきではありません。
IDを表示する際、RTL(Right-to-Left)文字が含まれていると、適切に処理しなければ、前後の文字を巻き込んで表示が乱れ読みづらくなります。
例: IDの後に日付が表示されるUIがあったとして、素直に書くと
Username : 12月31日
اللغة العربية : 12月31日
のようになります。
また、RTL/LTR属性を制御する制御文字があります。これらは禁止するのも手です。
投稿2022/01/01 23:57
総合スコア3047
思いつくままに書いていただいたという事ですが大変参考になります。
> 例えば「日本語で使う文字」だけに絞るといった仕様は、困難です。
これ、ワリと安易に考えていたんですけど面倒ですね。
出来るだけ範囲を絞った方が楽でしょうけど、どう絞ったのか、なぜ絞ったのかの説明をちゃんとしておかないとサポートコストに跳ね返りそうです。
趣味でやるには面白そうですけど、プロダクトにはしたくないなぁ^^;
MediaWiki がマルチバイト ID を許容しているのは盲点でした。
調査してみます。
ありがとうございます。
あなたの回答
tips
プレビュー
