ケース変換
ケースコンバーターは、お使いのブラウザ内で、識別子をcamelCase、PascalCase、snake_case、kebab-case、CONSTANT_CASE、さらにそのほか9つの記法の間で書き換えます。変換そのものは単純で、難しいのは入力を単語に分割する部分です。XMLHttpRequestは3語、user2faも3語です。ここを間違えるコンバーターは、誰も望まない出力を返してしまいます。
ケース変換はどう動きますか？
どの命名規則も、同じ単語の並びを違う形で書いたものにすぎません。つまり形式間の変換とは、1つの問題（入力を単語に分割する）と、その後の自明な結合だけです。コンバーター同士の違いは、実のところすべてこの最初の段階にあります。
見落とされやすい順に並べた3種類の単語境界
小文字から大文字への遷移は見分けやすいものです。userNameは2語です。頭字語の後に単語が続く形は、多くのコンバーターが間違えるケースです。XMLHttpRequestはXML Http Requestの3語であり、1語でも8語でもありません。そして、文字から数字への遷移は誰も考えないものです。user2faはuser 2 faの3語に分かれるため、user2faはuser2faのままではなく、user_2_faに変換されます。
区切り文字（スペース、アンダースコア、ハイフン、ドット、スラッシュ）はすべて同じように扱われます。だからこそ、どの記法かを教えなくても、ツールはどんな入力でも受け付けられるのです。入力の形式を選ぶ必要がないのは、選ぶべきものが何もないからです。
トルコ語のI
"I".toLocaleLowerCase()は、トルコ語とアゼルバイジャン語では"ı"（ドットのないi）となり、"i"にはなりません。その言語としては正しくても、コードにとっては大惨事です。ASCII文字列との大文字小文字を無視した比較はすべて失敗し、IDという名前の識別子は、コンパイラが認識できないものに変わってしまいます。そこでこのツールの大文字小文字変換は、デフォルトではロケールに依存しません。ロケール対応の変換も用意されており、それが正解になるのは散文テキストの場合です。
散文向けスタイルは構造を変えずに、大文字小文字だけを変える
センテンスケースとタイトルケースは、単語ではなくテキスト全体に対して働きます。句読点、空白、すでにある頭字語はそのまま残ります。タイトルケースでは、a、an、the、of、toなどの短い語は、文頭や文末に来ない限り小文字のままです。これはほとんどの英語のスタイルガイドに共通するルールで、リストの中身については見解が分かれています。
頭字語をどう扱うかは、本当の選択
user_idをPascalCaseに変換すると、言語の慣習に応じてUserIdにもUserIDにもなります。Goのスタイルガイドは後者を要求し、C#は2文字の頭字語にも、それより長い頭字語にも前者を要求します。どちらが間違いということはないので、これは勝手に決められるものではなく、切り替えられる設定になっています。
入力
XMLHttpRequest
変換結果
words XML | Http | Request camelCase xmlHttpRequest snake_case xml_http_request CONSTANT XML_HTTP_REQUEST kebab-case xml-http-request
ケース変換が対応するオプションとエッジケースは？
| パラメータ | 型 | デフォルト | 動作とエッジケース |
|---|---|---|---|
| camelCase | camel | userFirstName | JavaScriptとJavaの変数および関数。最初の単語は小文字、それ以降は大文字になります。 |
| PascalCase | pascal | UserFirstName | ほぼすべての言語の型名：クラス、インターフェース、Reactコンポーネント。 |
| snake_case | snake | user_first_name | PythonとRubyの識別子、PostgreSQLのSQL列名。 |
| CONSTANT_CASE | constant | USER_FIRST_NAME | C、Java、Go、JavaScriptの環境変数とコンパイル時の定数。 |
| kebab-case | kebab | user-first-name | URL、CSSカスタムプロパティとクラス名、npmパッケージ名。ほとんどの言語では有効な識別子ではありません。 |
| Train-Case | train | User-First-Name | HTTPヘッダー名——Content-Type、X-Request-Id——は大文字と小文字を区別しませんが、慣例としてこのように書かれます。 |
| dot.case | dot | user.first.name | ネストされた設定キー、i18nメッセージキー、Javaパッケージスタイルの名前空間。 |
| path/case | path | user/first/name | 名前から構築されたURLパスセグメントとファイルパス。 |
| 文頭のみ大文字 | sentence | User first name | 文章。文頭の最初の文字を大文字にし、それ以外は変更しないため、既存の頭字語はそのまま残ります。 |
| 単語の先頭を大文字 | title | User First Name | 見出し。小さい単語は最初または最後でない限り小文字のままです。 |
| 小文字 | lower | user first name | 文字列全体を小文字にします。句読点とスペースは変更されません。 |
| 大文字 | upper | USER FIRST NAME | 文字列全体を大文字にします。 |
| 大文字と小文字を交互に | alternating | uSeR fIrSt nAmE | 文字ごとに交互に大文字と小文字になります。 |
| 大文字と小文字を反転 | inverse | uSER fIRST nAME | すべての文字の大文字と小文字が反転します。 |
よくある質問
XMLHttpRequestが3語に分割されるのはなぜですか？
実際に3語だからです。ルールはこうです。すべて大文字の連なりの後ろに、大文字1文字とそれに続く小文字が現れたら、そこで単語が終わる。つまりXMLH-ttpはXML | Httpに分かれます。このルールがなければ、1語のxmlhttprequestになるか、大文字のたびに新しい単語が始まって8語のx_m_l_http_requestになるかのどちらかです。どちらも間違いで、どちらもよく見かけます。
入力がどんな形式かを指定する必要はありますか？
ありません。意図的に、そのためのオプションは用意していません。すべての区切り文字は同じように扱われ、大文字小文字の境界はすべて検出されるため、camelCase、snake_case、kebab-case、dot.case、普通の文章のいずれも、同じ単語リストに分割されます。混在した入力もそのまま処理できます。誰かが3つのコードベースから集めたリストを変換するときに、これが効いてきます。
小文字化にロケールのオプションがあるのはなぜですか？
"I".toLocaleLowerCase()が、トルコ語とアゼルバイジャン語では"ı"（ドットのないi）を返すからです。言語学的には正しいのですが、識別子にとっては大惨事です。"id"とのASCII比較は失敗し、ユーザー入力を小文字化してキーワードと比較するコードは、トルコ語ユーザーに対して動かなくなります。ここでの主な仕事はコードなので、オプションはデフォルトでオフになっています。それらの言語の散文テキスト向けにはオンにできます。
UserIdとUserID、どちらにすべきですか？
言語によります。GoのスタイルガイドはUserIDを要求し、頭字語はすべて大文字にします（APIURL、HTTPServer）。C#とJavaはUserIdを使い、2文字を超える頭字語は先頭の1文字だけを大文字にします。どちらがより正しいということはありません。周囲のコードに合わせるのが筋で、だからこそこれは切り替え式になっています。
識別子が並んだファイル全体を変換できますか？
1行に1つという条件で、可能です。各行は独立して変換されるため、スキーマや設定ファイルから列をコピーして貼り付け、全体をまとめて受け取れます。ただしコードを理解したリネーム機能ではありません。行内のどの単語が識別子で、どれが構文なのかは判断できないので、行全体を1つの名前として変換します。
入力したテキストはアップロードされますか？
されません。ブラウザ内で動作する文字列操作にすぎません。変換される識別子は、テーブル名、フィールド名、機能フラグといった内部システムの情報です。厳密には秘密とまでは言えませんが、理由もなく見知らぬサーバーに渡すべきものでもありません。