この質問はベンダー/バージョンに依存しないことに注意してください
英語を話す人（タイピスト、作家）としては、単語の大文字と小文字の区別は正しいが、正しいアクセントが必ずしも正しい方向に進むとは限らないように思えます。
シャンゼリゼ通りにあるレストランクロエのテテアテテで熟考しました。
あなたはそれでアイデアを得る。
そのため、今日、大文字と小文字を区別し、アクセントを区別しない照合を使用する検索条件が必要であると考えましたが、見つかりませんでした。これには正当な理由がありますか、それとも私にとってはまれなユースケースですか？
ここに私が見ていたいくつかのドキュメントの例があります（ただし、ベンダー/バージョンに依存しないと考えています）。
回答:
TL; DR
照合順序の「ベンダーに依存しない」ビューや「バージョンに依存しない」ビューのようなものはありません。なぜなら、それらの実装は、どの側面をインセンシティブにすることができるか、命名規則を含めて、ベンダー固有であり、時間とともに変化するためです。
ここに私が見つけたものの要約があり、詳細は行の下の長いセクションにあります：
RDBMS Naming- Combinations Case-Sensitive and
convention of options? Accent-Insensitive support?
------- ------------ ------------- -----
SQL Server _CS, _AI, etc Yes Latin1_General_100_CS_AI
DB2 _E{x}, _S{y}, etc Yes CLDR181_EO_S1
PostgreSQL locale: en_US N/A unaccent(), not via Collation
MySQL _cs, maybe _ai No No: _cs implies _as & _ci implies _ai
Yes? Create your own Collation :-)
Oracle only _CI & _AI No No: _AI always implies _CI
SAP ASE arbitrary: turdict N/A No: "AI" always implies "CI"
Informix locale.codepage N/A No: no "AI" via Collationsグラフからわかるように、7つのRDBMSのうち2つは、照合を介して「大文字と小文字を区別せず、アクセントを区別しない」操作をネイティブにサポートしますが、命名規則は異なります（その他の機能の違いもあります）。
1つのRDBMS-PostgreSQL-はこの組み合わせをネイティブにサポートしていませんが、unaccent()アドオン機能でアクセントを取り除くことでそれを達成できます。
最後の4つのRDBMS（2つはオプションの命名規則が似ています）は、この組み合わせをネイティブにサポートしておらず、アクセント/発音区別記号を削除する独自の関数を作成せずにこれを達成する手段もありません。MySQLでは独自の照合順序を作成できますが、それをソース管理に追加し、テストおよび展開プロセスに組み込んで、すべての環境のすべてのサーバーに適用できるようにする必要があります（ただし、非常にクールで柔軟なオプション） 。SAP ASEは、SAP が追加のUnicodeソート順を提供できると述べていますが、提供する意思があることについては言及していません。
その事に付いては：
これには正当な理由がありますか、それとも私にとってはまれなユースケースですか？
この答えの調査を行っていると、MySQLで大文字と小文字を区別せず、アクセントを区別することを望んでいる人がたくさんいますが、希望する組み合わせを求めている人はほとんどいません。
大文字と小文字を区別するがアクセントを区別しない照合を使用する検索条件が必要でしたが、検索が見つかりませんでした。
... この質問はベンダー/バージョンに依存しません
Collation仕様に基づいてRDBMSを探すのは実際には意味がないため、検索に失敗しました。これは、照合が機能する方法ではありません。ベンダーに依存しないとしてこれにアプローチしたいのですが、現実には、Collations-少なくとも私たちがやり取りする部分は非常にベンダー固有であり、常に検索しているスキームに適合しているわけではありません。
文字列の比較とソートは非常に複雑であり、これらのルールを実行するさまざまな方法があります。1つの方法は、1つ以上のルールを考慮したマッピングを持つことです。したがって、大文字と小文字を区別する大文字と小文字の4つの組み合わせは、4つの個別のマッピングに相当します。たとえば、SQL Server Collation Nameの MSDNページでこれを見ました。下にスクロールすると、チャートの左の列がであることがわかりますSort Order ID。大文字と小文字の区別のみが異なる場合でも、各照合には異なるID：SQL_Latin1_General_Cp1_CI_AS= 52 while SQL_Latin1_General_Cp1_CS_AS= 51があります。
または、Unicode Collation Algorithm（UCA）を通じてUnicodeが提供するものなど、ルールベースにすることもできます。このアプローチでは、すべてのキャラクターにデフォルトで1つ以上の重みが与えられます。次に、各カルチャ/ロケールには、これらの重みのいずれかを上書きするか、ルールを削除するか、ルールを追加するオプションがあります。アルゴリズムは、ロケール固有のルールを考慮し、選択されたオプションに基づいてそれらの重みを操作する可能性があります（大文字と小文字を区別するソートを行う場合に大文字と小文字が区別されるなど）。これが、Unicodeソートを行うことが非Unicodeソートよりも少し遅い理由の1つです。
実際に存在するオプションの数（実際の複雑さ）を把握するには、ICU（International Components for Unicode）プロジェクトからこのデモをチェックしてください。
そこを指定する8つの別のオプションがあり、そのうちのいくつかは、あなたが（例えば考えていることを照合名仕様の複数の要素で表されますCS、CI、AS、AI、など）。バリエーションの数を考えると、各組み合わせに独自のIDがあるマッピングファイルアプローチを使用すると、何千ものファイルが作成されます。これらのファイルの多くは、これらの特定の言語に変更があった場合、またはバグが見つかった場合に更新する必要があります。これがおそらく、SQL Server 2012にこれらの種類の照合順序が75のみある理由です（つまり、名前がで始まるものSQL_）。したがって、の組み合わせはありません_CS_AI。
UCAベースの照合の組み合わせが見つからなかった理由は何ですか？さて、SQL Server 2012には、で始まらない3810個の照合順序があるSQL_ため、合計3885個の照合順序があります。そのリストは、Webページで完全に列挙するには長すぎるようです。しかし、これは、他のベンダーにこの組み合わせが見つからなかった理由を完全には説明していません。
すでに言及されていること（つまり、実装するには組み合わせが多すぎ、リストするには実装が多すぎる）を超えて、ベンダー固有の実装と競合する必要があります。意味：すべてのベンダーがこれらすべてのオプションを調整できるわけではなく、そもそも照合の標準的な命名規則はありません。また、すべてのベンダーが並べ替えオプションを照合の一部と見なしているわけではありません。PostgreSQL照合は選択したロケールのデフォルトの順序でありILIKE、大文字と小文字を区別しない比較を行うために使用する必要があります。ベンダー固有の情報については、以下を参照してください。
これらの2つのMSDNドキュメントページに表示される内容と、質問に関するコメントで@MartinSmithが提供するクエリ（以下で少し修正）の違い：
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';これら2つのMSDNページは、非推奨のSQL Server照合を特に参照しているのに対して、そのクエリの結果として表示される照合（SQL Server 2012 SP3の時点で888）はWindows照合です。
SQL Server 2000以降、古いSQL Server照合順序（SQL ServerがWindows照合順序を利用できるようになる前に作成された）は廃止され、新しいルールや機能で更新されていません。たとえば、SQL Server 2012以降、補助文字の組み込み関数（UCS-2で最初に定義された「ベース」65,536文字を超える残りのUTF-16文字）の適切な処理をサポートする照合のセットが追加されました。 ）。これらの新しい照合順序は_SC（S補足Cハラクターのように）で終わります。
SQL Server照合順序-で始まる名前の照合順序は使用しないことをお勧めしSQL_ます。そのため、探しているオプションの組み合わせをサポートする多くの照合順序（大文字と小文字を区別する、アクセントを区別しない）にアクセスできます。利用可能な場合はいつでも、_SC希望する他のオプションがすべて揃っている限り、一方の端を使用することをお勧めします。
SQL Serverは_CS_AI命名規則を使用しますが、3810（SQL Server 2012現在）のすべてのWindows照合順序のリストはありません。すべてのロケールとバージョン、および命名規則の仕組みをリストしたWindows Collation Nameページだけがありますが、それだけです。
SQL Serverは、幅とかなの両方の感度の切り替えもサポートしています。
MySQLバージョン5.7、ドキュメンテーション、それがサポートしていることの状態は_ai、_as、_ci、および_cs接尾辞（および_bin完全性のため）だけでなく、述べて：
アクセントの区別を指定しない非バイナリ照合名の場合、大文字と小文字の区別によって決定されます。照合順序名が含まれていない場合つまり、
_aiあるいは_as、_ci名前に意味_aiや_cs名前に暗示します_as。たとえば、
latin1_general_ci大文字と小文字を区別しない（暗黙的にアクセントを区別しない）、latin1_general_cs大文字と小文字を区別する（暗黙的にアクセントを区別する）
これは、latin1_general_cs_ai照合を行うことが可能であることを確かに暗示しています。しかし、私はへのアクセス権を持っていることのMySQL 5.5.50サーバが複数のサフィックスを持つ任意の照合順序を持っていない、と私だけが見るサフィックスです：_cs、_ci、および_bin198の合計照合順序間。SHOW COLLATIONコマンドを使用してそれらをリストしました。
そのため、MySQLは（少なくともこれらの2つのオプションに関する限り）同様の命名規則を使用しているように見えますが、探しているものと一致する照合を見つけることができません。ただし、アクセント（およびその他の発音区別記号）を取り除き、_cs照合を使用して必要なものを取得することが可能かもしれません（PostgreSQLで行う方法と同様に、以下を参照）。しかし、私はこのオプションについて確信が持てず、現時点でさらに研究する時間はありません。
または、必要なことを正確に行うために、独自の照合を作成できます。他のRDBMSとは異なり、MySQLは独自の照合順序を追加するのをかなり簡単にしているように見えます。この場合、各文字の重みを完全に制御できます。詳細については、8ビット文字セットへの単純な照合の追加およびUnicode文字セットへのUCA照合の追加を参照してください。
MySQLがさまざまなタイプの照合を処理する方法の詳細については、照合の実装タイプのページを参照してください。
PostgreSQLの照合順序ははるかに柔軟性が低いようです。：あなただけの文化/ロケールを指定するen_US、de_DEなどのために彼らのドキュメントページを参照してください照合サポートの詳細について。したがって、デフォルトでは、カルチャ固有のオーバーライドを得るが、照合順序は、（ちなみに、である、そうでない場合はすべて小文字が区別されていない「バイナリ」照合と同じ）。
ILIKE（セクション9.7.1）を使用して大文字と小文字を区別することはできますが、アクセントの区別に類似した演算子はありません。しかし、アクセントやその他の発音区別符号を取り除くために使用できるアクセントのない機能があることがわかりました。この関数は追加で提供されるモジュールであるため、使用する特定のPostgreSQLサーバーに必ずしも存在するわけではないことに注意してください。最近リンクされたドキュメントの状態：
ソースディストリビューションからビルドする場合、「world」ターゲットをビルドしない限り、これらのコンポーネントは自動的にビルドされません
...
PostgreSQLの事前パッケージバージョンを使用している場合、これらのモジュールは通常、 postgresql-contrib。
その機能がなく、必要な場合にその機能を取得する方法については、そのドキュメントを参照してください。
詳細については、次のスタックオーバーフローの回答にも記載されています。
PostgreSQLは「アクセントを区別しない」照合をサポートしていますか？
Microsoft SQL Serverと同様に、DB2には2種類の照合があります。
「SYSTEM」照合SYSTEM_{codepage}_[optional-territory]。次の形式を使用して指定されます。これらは非常に柔軟ではなく、大文字と小文字、アクセントなどに合わせて感度を調整することはできません。サポートされている照合のリストは、サポートされているテリトリーコードとコードページで確認できます。
Unicode Collation Algorithm（UCA）ベースの照合。これらはかなりの調整をサポートします。動作、命名規則、および有効なロケールのリストを構成する方法の詳細については、Unicode Collation Algorithm based collationsページを参照してください。表1では、3行目の例（「ケースレベル」）が次で始まることに注意してください。
Case Level属性をonに設定し、Strength属性をプライマリレベルに設定すると、アクセントは無視されますが、大文字と小文字は区別されません。
それはまさにあなたが探していたものです。ただし、その構文は次のとおり
CLDR181_EO_S1です。これが、検索でDB2に関連するものが見つからなかった理由です。
Oracle 10gでは、アクセントを区別しない比較とソートのサポートが追加されました。しかしながら：
_CIし、_AI_CI--はまだアクセントを区別します_AI「常に大文字と小文字を区別しません。」（以下にリンクされているドキュメントから引用）詳細と例については、言語ソートと文字列検索のドキュメントページをご覧ください。
ASEは、各ロケール/文字セットごとに、次の1つ以上の感度の組み合わせをサポートしています。
ロケール、文字セット、使用可能なソート順の関係は、デフォルトのソート順の選択ページで確認できます。また、照合名とIDページで照合の完全なリストを確認できます。
照合の命名規則は、すべて4〜8文字であり、ロケール名またはコードページとソートの意味をキャプチャしようとするため、任意です。例えば：
altnoacc==「CP 850代替–アクセントなし」
rusdict==「ロシア語辞書の順序付け」
dynix==「中国語の音声順序付け」
「デフォルトのUnicodeソート順の選択」ページには、次のような注記があります。
$/collate/Unicodeディレクトリ内の外部ファイルを使用して、ソート順を追加できます。名前と照合IDはに保存されsyscharsetsます。syscharsetsデフォルトのUnicodeソート順を設定する前に、外部Unicodeソート順の名前を指定する必要はありません。
...
外部Unicodeソート順はSAPによって提供されます。外部のUnicodeソート順を作成しようとしないでください。
SAPが大文字と小文字を区別し、アクセントを区別しないようにする外部ソート順を提供するかどうかは不明です。たぶんいつか私はそれらを電子メールで送信し、要求できるかどうか尋ねます。
必要な感度の組み合わせを得るには、スカラーのユーザー定義関数を作成して、アクセントやその他の発音区別符号を取り除く必要があります。
Informixは、ほとんどの場合、照合のデフォルトのソートおよび比較動作をサポートしているだけです。したがって、照合順序はロケールと文字セットにすぎません。大文字と小文字の区別はデータベースレベルで処理され、デフォルトでは大文字と小文字が区別されます。ステートメントでNLSCASE INSENSITIVEを指定することで、大文字と小文字を区別しないようにデータベース（テーブル、列、クエリ、または述語でもない）を設定できますCREATE DATABASE。
データベースの照合（ロケールと文字セット）はクライアント接続ごとにオーバーライドできますが、大文字と小文字の区別の設定をオーバーライドする方法はないようです。AND、NLSCASEオプションには名前に「NLS」が含まれています。理由はNCHAR、NVARCHARデータとデータにのみ影響するためです。CHARそしてVARCHAR、常に大文字と小文字が区別されます。
アクセントの感度は考慮されておらず、アクセント/発音区別符号を取り除く組み込み関数もありません。
Informix Collationの命名規則は次のとおりです。
<lang>_<country>.<code set>どこ：
<lang> = 2文字または3文字の言語コード<country> = 2文字の国または地域コード<code set> =次の3つの同等の方法のいずれかで指定されたコードページ：
したがって、次の3つのロケール指定はすべて、まったく同じロケールを参照しています。
詳細については、以下を参照してください。