Unicodeって、良いところもあるけど、特定の文字を除外しなきゃいけないのが面倒だよね。まるで複雑さのジャングルみたい。言語の書き方をたくさん形式化しようとした結果なんだろうけど、他の文字と比べて特別な文字を考えなきゃいけないのが本当に嫌だ。唯一見つけたまともな対処法は、Unicodeの文字列を独自のデータユニット形式として扱うこと。受け入れて、保存して、表示して、データとして（意味じゃなく）等しいかどうかを比較することはできるけど、その内容について考えようとは思わない。連結するのさえも気が進まないよ。

「意図的に制御文字を含まない」という盲目的な前提で、実際のプログラムが壊れたことがある。特にページ分割用のものではフォームフィードがよく使われるし、端末用に設計されたものではエスケープが一般的だよね。「完全にUTF-8である」という前提も危険で、古いデータファイルやログは簡単には消えないから。テキストで何か役立つことをしていないなら、バイト列をそのまま通すのが一番いい。残念ながら、Microsoft Windowsがあるから、時にはchar16_tのシーケンスを通さなきゃいけないこともある。UTF-16の最悪なところは、無効なUTF-16が無効なUTF-8とは根本的に違うこと。これらの間で変換する時（実際には、外部データを処理用の内部形式に変換する時）、前者はWTF-8を使えるけど、後者はPythonスタイルのサロゲートエスケープを使うことになる。これらを混ぜることはできないんだ。

確信はないけど… 一方では、ペアになっていないサロゲートのような問題のある（または無効な）文字には同意するよ。でも、最悪のシナリオは、データ構造やプロトコルを設計している人たちが、適切にエスケープされた文字の任意のクラスを禁止しなきゃいけないと感じることだと思う。例えば、ユーザー名の検証は別のレイヤーの仕事だよね。ユーザー名が60文字未満で、絵文字やzalgoテキストがなく、ヌルバイトもないことを確認して、APIから適切なエラーを返したい。JSONパースが全く別のレイヤーの事前検証で失敗するのは避けたいし。ユーザー名には明らかにダメなクラスがあるけど、もし変なタブを使っているテキストファイルを送ったらどうなるの？自分の言語のutf8「文字列」タイプで動くものがエンコード可能であることを期待してるし、ヌルバイトの使い道もたくさん見てる。実際、ヌルバイトは野生のJSONでもよく見かけるし。一方で、制限された「普通の」Unicode文字のセットを使わなきゃいけないなら、標準があると便利だと思う。みんなが自分のミニスタンダードを作るよりはマシだから。だから、そのアイデアは好きだけど、ブログの主張や例には納得できないな。

PRECISion · IETFが「Bad Unicode」に関して2025年まで待った理由を疑問に思うかもしれないけど、実際にはそうじゃない。RFC 8264があるよ：PRECISフレームワーク：アプリケーションプロトコルにおける国際化された文字列の準備、施行、比較。最初のPRECISの前身は2002年に発表されたんだ。8264は43ページもあって、9839よりもずっと多くの潜在的なBad Unicodeの問題について詳しく議論している。RFC 8265と8266もチェックすることをお勧めするよ：アプリケーションプロトコルにおける国際化された文字列の準備、施行、比較：ユーザー名とパスワードの表現 — https://www.rfc-editor.org/rfc/rfc8265 ニックネームを表す国際化された文字列の準備、施行、比較 — https://www.rfc-editor.org/rfc/rfc8266 一般的に言って、テキストの方向を変える可能性のあるユーザー名や、入力したデバイスによって異なるバイト表現を持つパスワードは表示したくない。これらのRFCにはそれを避けるための特定のプロファイルがあるよ。こういう目的のためには、失敗がオープンになるよりもクローズになる方が安全だと思う。最新の絵文字をユーザー名から禁止する方が、ユーザー名を表示するすべてのページを壊す可能性を許すよりはマシだよ。

グラフィカルユニットが持てるUnicodeスカラー値の数に制限を設けるべきだと思う。数年前にチェックした時には、標準にはそんな制限はなかったけど、グラフィカルユニットを「ストリーミングアプリケーション」のために128バイトに制限することを推奨する文言はあった。これを標準に取り入れるか、少なくともスカラー単位に制限を設けることで、実装や処理がずっと楽になると思うし、合理的なアプリケーションを制限することもないはず。

Unicodeはすでに「一般カテゴリ」を定義していて、これらの「変な」文字のいくつかを分類していることに注意する価値があるよ。例えば、Pythonで、import unicodedataして、print(unicodedata.category(chr(0)))とprint(unicodedata.category(chr(0xdead)))を実行すると、「Cc」（制御）と「Cs」（サロゲート）が表示される。

「レガシーコントロール」をリテラルだけでなく、エスケープされた文字列（例: "\u0027"）としても除外するのはやりすぎな気がする。C1は基本的に使われてないと思うけど、それはいいとして、いくつかのC0文字は実際に使われてる（エスケープ、EOF、NUL）。個人的には、いくつかの使用例は正当で合理的だと思う。

ほとんどは、文字列をUTF-8として解釈する際に無効なUTF-8バイトシーケンスを拒否することで処理されてるみたいだね（理想的には、完全にエラーを返す）。つまり、ペアになってないサロゲートや、他のサロゲートも、すでにUTF-8バイトシーケンスとしては違法だし。UTF-8を使う文字列を持つ有能な言語なら、そういうシーケンスが与えられたときにはエラーを返すべきだよ。問題のあるコードポイントのリスト（非印刷可能なものなど）は、個人的にはもっと有用で重要だと思う。でも、それらを普通の違法なUTF-8バイトシーケンスとは別の概念として扱うのは有益だね。

一つの決断に迷ってるんだ：入力を制御するか、信頼できない入力を安全に表示するデータ型でラップするか（ウェブ＋ログ＋デバッグ）。

これがどう役立つのか理解できないな。受け入れるユニコードのサブセットを定義しても、値が型定義に従っているか確認する必要はなくならないよね。