ケースケーストゥルースプログラマーは知っておくべき

で、ノースベイのPython会議2018で、私が与えた話のユーザー名にします。レポートからの情報のほとんどは、django-registrationをサポートしてきた12年以上にわたって私が収集したものです。この経験は、私が計画していたよりもはるかに多くの知識を私に与えてくれました。



しかし、私の話の冒頭で、これは一連の「プログラマーが信じているXについての誤解」からの別の露出ではないことを述べました。あなたはそのような啓示をいくつでも見つけることができます。しかし、私はこれらの記事が好きではありません。彼らはおそらく間違っていると思われるさまざまなことをリストしていますが、これがなぜであり、代わりに何をすべきかを説明することはめったにありません。人々はこのような記事を読んで、この成果を祝福し、これらの記事に記載されていない間違いを犯すための興味深い新しい方法を見つけに行くのではないかと思います。これは、これらのエラーの原因となっている問題を実際に理解していなかったためです。



したがって、私のレポートでは、いくつかの問題を可能な限り説明し、それらを解決する方法を説明しようとしました-私はこのアプローチがはるかに好きです。通過するときに触れただけのトピックの1つ（1つのスライドと他のスライドでのいくつかの言及）は、キャラクターの場合に関連する可能性のある複雑さです。私が議論した問題（大文字と小文字を区別しない識別子の比較）に対する公式のCorrect Answer™があり、講演では、Python標準ライブラリのみを使用することで私が知っている最善の解決策を示しました。



ただし、Unicodeの場合のより深い複雑さについて簡単に説明したので、詳細については少し時間を割いて説明したいと思います。これは興味深いことであり、それを理解することは、テキスト処理コードを設計および作成する際の決定に役立ちます。したがって、「プログラマーが信じるXについての誤解」、「プログラマーが知っておくべき真実」という記事の反対を提供します。



そしてもう1つ、Unicodeには用語がたくさんあります。この記事では、Unicode標準であるため、主に「大文字」と「小文字」の定義を使用します。これらの用語を使用します。小文字/大文字のような他の用語が好きなら、それは問題ありません。また、私はよく「シンボル」という用語を使用しますが、これは間違っていると感じる人もいます。はい、Unicodeでは、「文字」の概念は必ずしも人々が期待するものではないため、他の用語を使用して回避するのが最善の場合がよくあります。ただし、この記事では、Unicodeで使用されている用語を使用して、主張できる抽象的なエンティティを説明します。重要な場合は常に、コードポイントなどのより具体的な用語を使用して明確にします。

3つ以上のレジスタがあります

ヨーロッパの言語のネイティブスピーカーは、彼らの言語が特定のことを示すために大文字と小文字を使用するという事実に慣れています。たとえば、英語[およびロシア語]の言語では、通常、文は大文字で始まり、ほとんどの場合小文字で続きます。また、固有名詞は大文字で始まり、多くの略語や略語は大文字で書かれています。



そして、私たちは通常、レジスターは2つしかないと考えています。文字「A」と文字「a」があります。 1つは大文字、もう1つは小文字です-そうではありませんか？



ただし、Unicodeには3つのレジスタがあります。大文字、小文字、タイトルケース[titlecase]があります。英語では、名前はこのように書かれています。たとえば、「アベンジャーズ：インフィニティウォー」。通常、この場合、各単語の最初の文字は単純に大文字で記述されます（また、さまざまなルールやスタイルによっては、記事などの一部の単語は大文字になりません）。



Unicode標準では、大文字の文字の例を示しています。U+ 01F2 LATIN CAPITAL LETTER D WITH SMALLZ。次のようになります：Dz。



このような文字は、Unicode標準の最も初期のソリューションの1つである既存のテキストエンコーディングとの下位互換性の悪影響を処理するために必要になる場合があります。 Unicodeは、標準の文字の組み合わせを使用してシーケンスを作成する方が便利です。ただし、多くの既存のシステムでは、既製のシーケンス用にスペースがすでに割り当てられています。たとえば、ISO-8859-1（ "latin-1"）では、 "é"文字の番号は0xe9の既製のフォームです。 Unicodeでは、この文字を別の「e」とアクセントマークで書くことが望ましいでしょう。ただし、latin-1などの既存のエンコーディングとの完全な下位互換性を確保するために、Unicodeは既製の文字にコードポイントも割り当てます。たとえば、U + 00E9 LATIN SMALL LETTER E WITHACUTE。



この文字のコード位置はそのlatin-1バイト値と同じですが、これに依存しないでください。Unicodeでの文字エンコードがこれらの位置を保持する可能性は低いです。たとえば、UTF-8では、コード位置U + 00E9はバイトシーケンス0xc30xa9として書き込まれます。



そしてもちろん、既存のエンコーディングには大文字を使用するときに特別な処理が必要な文字があります。そのため、それらは「そのまま」Unicodeに含まれていました。それらを確認したい場合は、お気に入りのUnicodeデータベースでLtカテゴリ（「レター、タイトルケース」）の文字を検索してください。

ケースを定義する方法はいくつかあります

Unicode標準（§4.2）には、3つの異なるケース定義がリストされています。おそらく、3つのうちの1つを選択するのは、プログラミング言語によって行われます。それ以外の場合、選択は特定の目標によって異なります。これらの定義は次のとおりです。

1. 文字は、Luカテゴリ（「文字、大文字」）の場合は大文字で、Llカテゴリ（「文字、小文字」）の場合は小文字です。この規格は、この定義の制限を認識しています。特定の各シンボルは、カテゴリの1つにのみ帰属する必要があります。このため、大文字または小文字で「必須」である多くの文字は、他のカテゴリに属しているため、この要件を満たしません。
2. 文字は、Uppercaseプロパティを継承する場合は大文字になり、Lowercaseプロパティを継承する場合は小文字になります。これは、1つの定義と他の文字プロパティの組み合わせであり、大文字と小文字が含まれる場合があります。
3. 大文字にマップされた後も変更されない場合、文字は大文字になります。小文字にマッピングされた後も変更されない場合、文字は小文字になります。これはかなり一般的な定義ですが、直感的ではない動作をすることもあります。

シンボルの限られたサブセット（具体的には文字）を使用している場合は、1つの定義で十分な場合があります。レパートリーがより広い場合（文字ではない文字のような記号が含まれている場合）、2番目の定義が適している可能性があります。Unicode標準§4.2で推奨されています。

Unicode文字列を操作するプログラマーは、文字プロパティを直接操作しない場合は、isLowerCase（およびその機能的ないとこtoLowerCase）などの文字列関数を操作する必要があります。

ここで言及されている機能は、Unicode標準の§3.13で定義されています。正式には、定義3は§3.13のisLowerCase関数とisUpperCase関数を使用し、それぞれtoLowerCaseとtoUpperCaseの固定位置で定義されています。



プログラミング言語に文字列または個々の文字の大文字と小文字をチェックまたは変換する機能がある場合は、上記の定義のどれが実装で使用されているかを調べる価値があります。興味があれば、Pythonのisupper（）メソッドとislower（）メソッドは2番目の定義を使用します。

キャラクターの場合をその外観や名前で理解することは不可能です

多くのキャラクターの登場により、どのような場合かがわかります。たとえば、「A」は大文字です。これは、シンボルの名前「LATIN CAPITALLETTERA」からも明らかです。ただし、この方法が機能しない場合があります。コードポイントU + 1D34を取ります。次のようになります：ᴴ。Unicodeでは、次の名前が割り当てられます：MODIFIER LETTER CAPITAL H.では、大文字ですよね？



実際、小文字のプロパティを継承しているため、定義＃2では、視覚的に大文字のHに似ており、名前に「CAPITAL」という単語が含まれているにもかかわらず、小文字になっています。

一部の文字はまったく大文字と小文字を区別しません

Unicode標準の§3.13の定義135は次のように述べています。

Cに小文字または大文字のプロパティがある場合、またはGeneral_CategoryがTitlecase_Letterである場合に限り、Cは大文字と小文字を区別します。

これは、多くのUnicode文字（実際には、それらのほとんど）が大文字と小文字を区別しないことを意味します。彼らの事件についての質問は意味がなく、事件の変更は彼らに影響を与えません。ただし、定義＃3により、この質問に対する答えを得ることができます。

一部の文字は、複数のレジスタがあるように動作します

つまり、定義＃3を使用して、大文字と小文字を区別しない文字が大文字であるか小文字であるかを尋ねると、「はい」という答えが得られます。



Unicode標準は、文字U + 02BD MODIFIER LETTER REVERSED COMMA（次のようになります： ʽ）の例（表4-1、7行目）を示しています。継承された小文字または大文字のプロパティがなく、Ltカテゴリに属していないため、大文字と小文字は区別されません。同時に、大文字に変換しても変更されず、小文字に変換しても変更されないため、3番目の定義によれば、「あなたは大文字に属しますか？」という両方の質問に「はい」と答えます。と「あなたは小文字ですか？」



これは不必要な混乱を引き起こす可能性があるようですが、要点は、定義＃3がUnicode文字の任意のシーケンスで機能し、大文字と小文字の変換アルゴリズムを単純化できることです（大文字と小文字を区別しない文字はそのままになります）。

ケースは状況に応じて異なります

Unicodeケース変換テーブルがすべての文字をカバーしている場合、この変換は単にテーブル内の適切な場所を見つけることであると考えるかもしれません。たとえば、Unicodeデータベースには、U + 0041 LATIN CAPITAL LETTERAは小文字のU + 0061 LATIN SMALL LETTER Aと記載されています。単純ですね。



このアプローチが機能しない1つの例は、ギリシャ語です。文字Σ（つまり、U + 03A3 GREEK CAPITAL LETTER SIGMA）は、単語のどこにあるかに応じて、小文字に変換されると2つの異なる文字にマップされます。単語の終わりにある場合は、小文字のσ（U + 03C2 GREEK SMALL LETTER FINAL SIGMA）になります。他の場所ではσ（U + 03C3 GREEK SMALL LETTER SIGMA）になります。



これは、レジスタが1対1または一時的ではないことを意味します。別の例はß（U + 00DF LATIN SMALL LETTER SHARP S、またはescet）です。別の大文字の形式（ẞ、U + 1E9E LATIN CAPITAL LETTER SHARP S）がありますが、大文字は「SS」になります。また、「SS」を小文字に変換すると「ss」になります。したがって（大文字と小文字の変換にUnicodeの用語を使用）：toLowerCase（toUpperCase（ß））！= Ss。

ケースはロケールに依存します

言語が異なれば、大文字と小文字の変換ルールも異なります。最も一般的な例：i（U + 0069 LATIN SMALL LETTER I）とI（U + 0049 LATIN CAPITAL LETTER I）は、ほとんどのロケールで相互に変換されます。すべてではありませんが、ほとんどです。ロケールazおよびtr（トルコ語）では、大文字のiはİ（U + 0130 LATIN CAPITAL LETTER I WITH DOT ABOVE）になり、小文字のIはı（U + 0131 LATIN SMALL LETTER DOTLESS I）になります。時々、それを正しくすることは本当に生と死の違いを意味します。



Unicode自体が、すべてのロケールで考えられるすべての大文字小文字変換ルールを処理するわけではありません。 Unicodeデータベースには、ロケールに固有ではなく、すべての文字を変換するための一般的なルールのみがあります。また、いくつかの言語と複合形式には特別な規則があります-リトアニア語、トルコ語、ギリシャ語のいくつかの機能。他のすべてはそこにありません。規格の§3.13はこれに言及しており、必要に応じてロケール固有の変換ルールの導入を推奨しています。



一例は英語を話すサインです-これは特定の名前のタイトルケースです。 「O'brian」は「O'brian」に変換する必要があります（「O'brian」ではありません）。ただし、その際、「It's」は「It'S」ではなく「It's」に変換する必要があります。 Unicodeで処理されない別の例は、オランダ語の文字の組み合わせ「ij」です。これは、タイトルケースに変換するときに、単語の先頭にある場合はすべて大文字に変換する必要があります。したがって、タイトルレジスタのオランダで最大のベイは、「Ijsselmeer」ではなく「IJsselmeer」になります。 Unicodeには、必要に応じて、IJU+ 0132 LATIN CAPITAL LIGATUREIJおよびijU+ 0133 LATIN SMALL LIGATUREIJの文字があります。デフォルトでは、ケース変換はそれらを相互に変換します（ただし、互換性の同等性を使用するUnicode正規化フォームはそれらを2つの別々の文字に分割します）。

レポートに示されている資料に戻ります。 Unicodeの大文字小文字管理は複雑であるため、多くのプログラミング言語に見られる標準の小文字または大文字の変換関数を使用して、大文字と小文字を区別しない比較を実行することはできません。このような比較のために、Unicodeには大文字と小文字の区別の概念があり、標準の§3.13はtoCaseFold関数とisCaseFolded関数を定義しています。



折りたたまれたケースへのキャストは小文字へのキャストに似ていると思うかもしれませんが、そうではありません。 Unicode標準では、大文字と小文字を区別する文字列を小文字にする必要はないと警告しています。例として、チェロキー言語が与えられています-そこで、折りたたまれた大文字小文字の文字列では、大文字の文字も出くわします。



私の講演のスライドの1つでは、Unicodeテクニカルレポート＃36が可能な限りPythonで完全に実装されています。 NFKC正規化が実行され、結果の文字列に対してcasefold（）メソッド（Python 3以降でのみ使用可能）が呼び出されます。それでも、一部のエッジケースは失敗し、それはID比較に推奨されるものではありません。最初の悪いニュース：Pythonは、XID_StartまたはXID_Continueにない文字、またはDefault_Ignorable_Code_Pointプロパティを持つ文字を除外するのに十分なUnicodeプロパティを公開していません。私の知る限り、NFKC_Casefoldマッピングはサポートされていません。変更されたNFKCUAX＃31§5.1を使用する簡単な方法もありません。



幸いなことに、これらのエッジケースのほとんどには、問題のシンボルによってもたらされる実際のセキュリティリスクは含まれていません。また、ケースフォールディングは、原則として正規化保存操作として定義されていません（したがって、ケースフォールディング後にNFCに再正規化されるNFKC_Casefoldマッピング）。一般に、比較する場合、前処理後に両方の文字列が正規化されているかどうかは関係ありません。前処理に一貫性がないかどうか、および後で「異なるはず」の行のみが後で異なることが保証されるかどうかを気にします。これが心配な場合は、レジスタの追加後に手動で再正規化できます。

今のところ十分です

この記事は、前のレポートと同様に網羅的ではなく、このすべての資料を1つの投稿に収めることはほとんど不可能です。これがこのトピックの複雑さの有用な概要であり、さらなる情報を探すのに十分な出発点を提供することを願っています。したがって、原則としてここで停止できます。



他の人が一連の「プログラマーが信じるXについての誤解」からの露出を書くのをやめて、「プログラマーが知っておくべき真実」のような記事を書き始めることを期待するのは単純ではないでしょうか。