テキストの大文字小文字を変換する方法

命名規則は重要です。コードを書いていても、ファイル名を作っていても、見出しをフォーマットしていても、正しいテキストケースを使うことで一貫性とプロフェッショナルさが保たれます。手動でケースを変換するのは退屈でエラーが起きやすく、特に長いテキストや変数名では大変です。ブラウザベースのコンバーターは、よくあるケース形式のすべてを瞬時に処理します。

一般的なテキストケースと使われる場所

テキストケースを変換する手順

1. テキストを貼り付け: 任意のテキストをコンバーターに入力します。単語、変数名、文、段落全体で動作します。
2. ケースを選択: 望むフォーマットをクリックします。変換は即座に適用されます。
3. 結果をコピー: 「コピー」をクリックして、コード、文書、ファイル名のために変換されたテキストを取得します。

コードの命名規則の簡単な歴史

初期のプログラミング言語には、識別子の長さに厳格な制限がありました。FORTRAN(1957年)は6文字、ALGOL(1958年)は限定的な文字を許可しました。プログラマーは積極的に略す必要がありました。識別子が短すぎて複数の単語を持てなかったため、ケース規則は必要ありませんでした。

言語が長い識別子を許可するようになると(C 1972年、Pascal 1970年)、単語の区切りが問題になりました。Pascalは単語を区切るために大文字を使うことを普及させました: MyVariable。Cは歴史的にアンダースコア付きの小文字を使いました: my_variable。この分かれ目は続いています。ほとんどのCファミリーとUnix言語はsnake_caseを好み(Python、Ruby、デフォルトのRust、PostgreSQLカラム)、JavaファミリーとMicrosoft言語はcamelCaseを好みます(JavaScript、Java、C#、Swift、Kotlin)。

PascalCaseは1980年代にSmalltalkからクラス名のために登場し、C++(1985年)、Java(1995年)、C#(2000年)に採用されました。今日、ほとんどの言語は単語区切りの好みに関わらず、型/クラスにはPascalCaseを、インスタンス/関数にはcamelCaseを使います。

kebab-caseはWebとともに現れました。CSSはハイフン(background-color)を選び、URLもそれを好みます。ほとんどのモダンWeb言語(HTML、CSS、URLパス、JSONスキーマ)は、ユーザーから見える識別子にkebab-caseを使います。

最新の規則は、定数と環境変数のためのSCREAMING_SNAKE_CASEです。これは2000年代までにほとんどのプログラミング言語に渡ったUnixシェルの遺産です。

それぞれの規則をいつ使うか

実用的なガイド:

• UPPERCASEを散文で: 頭字語(NASA、HTML、CSS)、強調(まれに。太字の方が通常は良い)、それを指定するデザインシステムの見出し。
• lowercaseを散文で: URL、メールアドレス、ハッシュタグ、カジュアルチャット。コードでは: 一部のLispの派生を除いてまれです。
• Title Case: 書籍タイトル、記事見出し、固有名詞。どの単語を大文字にするかについて、スタイルガイドごとに異なるルールがあります。
• Sentence case: 本文、説明、モダンなデザインシステムのUIラベルの標準(Material DesignとApple HIGはどちらもボタンにSentence caseを好みます)。
• camelCase: JavaScript / TypeScript変数、Java / Swiftメソッド名、ほとんどのOO言語のインスタンス変数。
• PascalCase: クラス名、型名、React / Vueコンポーネント名、列挙型。
• snake_case: PythonとRubyの変数/関数、データベースカラム名、GraphQLフィールド名(時折)、シェル変数。
• SCREAMING_SNAKE_CASE: ほとんどの言語での定数、環境変数(DATABASE_URL、NODE_ENV)、YAML / JSONの設定キー。
• kebab-case: URLスラグ、CSSクラス名、HTML data-*属性、npmパッケージ名、静的サイトジェネレーターのファイル名。
• dot.case: コード内のオブジェクトプロパティパス、設定ファイル(Nginx、Spring Bootプロパティ)、名前空間付きイベント。

Title Caseのルール

「Title Case」はシンプルに聞こえますが、スタイルガイドの複雑さがあります:

• APAスタイル: 4文字以上の単語を大文字に。長さに関わらず、すべての名詞、動詞、形容詞、副詞を大文字に。
• Chicago Manual of Style: 最初/最後の単語を大文字に。すべての名詞、動詞、形容詞、副詞、代名詞を大文字に。冠詞(a、an、the)、短い前置詞、等位接続詞(and、but、or)は小文字に。
• APスタイル: 4文字以上のすべての単語を大文字に。前置詞には特定の例外があります。
• MLAスタイル: Chicagoに似ていますが、前置詞の扱いにわずかな違いがあります。

「シンプルなタイトルケース」コンバーターはすべての単語を大文字にします(これは厳密には主要なスタイルガイドのどれとも一致しません)。ほとんどのコンバーターは「Title Case」を素早い推定として提供しますが、次のものについては結果を手動レビューするようフラグを立てます:

• 冠詞(a、an、the)
• 接続詞(and、but、or、for、nor)
• 短い前置詞(in、on、at、by、to、of)
• 頭字語(API、HTTP、CSS)

よくある落とし穴

• camelCase内の頭字語: xmlHTTPRequestは不格好です。GoogleのJavaScriptスタイルガイドは頭字語を単語として扱うことを推奨しています: xmlHttpRequestまたはXmlHttpRequest。MicrosoftとJavaのスタイルガイドはすべて大文字を保ちます: XMLHttpRequest。1つの規則を選んでください。
• 識別子内の数値: version2Point0 vs version2_0 vs version20。普遍的なルールはなく、言語の規則に依存します。
• 頭文字大文字の頭字語: 「i18n」はcamelCase、「I18n」はPascalCase、「I18N」はscreamingです。文脈に合わせてください。
• 前置詞のTitle Case: 「Off The Record」はほとんどの編集者には間違って見えます。「Off the Record」はほとんどのスタイルガイドに従います。公開前に検証してください。
• データベースのケース規則は変動する: PostgreSQLとほとんどのSQL実装は、クォートされていない識別子では大文字小文字を区別しませんが、クォートされたものでは区別します。実際のカラム名がmycolumnなら、SELECT myColumn FROM tableは失敗するかもしれません。
• OS別のファイル名の大文字小文字の区別: macOSのHFS+はデフォルトで大文字小文字を区別しません。APFSは大文字小文字を区別しませんが保持します。LinuxのEXT4は大文字小文字を区別します。WindowsのNTFSは大文字小文字を区別しません(ただしWindows上のLinuxサブシステムは区別します)。MyFile.txtとmyfile.txtは同じファイルである場合もそうでない場合もあります。
• Unicodeのケースはロケール依存: 大文字の İ(トルコ語のドット付きI)対 I(英語)。一部のtoUpperCase()実装は、明示的なロケールなしでこれを誤ります。

使いこなしのヒント

• 言語の規則に合わせる: Pythonはsnake_case、JavaScriptはcamelCase、CSSはkebab-caseを使います。コードベース内の一貫性は個人の好みより重要です。
• Unicodeはサポートされている: コンバーターはアクセント付き文字、絵文字、CJK文字を扱うため、どの言語のテキストでも動作します。
• Title Caseでは頭字語を確認: ほとんどのタイトルケースコンバーターはすべての単語を大文字にするため、「API」が「Api」になることがあります。変換後に頭字語をレビューしてください。
• 読みやすさにはSentence caseを使う: ボタンラベルや説明のようなユーザー向けテキストには、Title CaseよりもSentence caseの方が読みやすいことが多いです。
• リンターを設定する: ESLint、Prettier、Pylint、RuboCopはすべて命名規則を自動的に強制できます。一度設定すれば、保存時にリンターがケース違反をキャッチします。
• コードスタイルガイドを使う: Google、Airbnb、Microsoft、GitHubはすべて主要な言語のスタイルガイドを公開しています。プロジェクト用に1つを選び、それを続けてください。

プライバシーと機密テキスト

ケースコンバーターは完全にブラウザ内で動作します。貼り付けたテキスト、中間変換、出力はすべてデバイス上に留まります。サーバーへのアップロード、ロギング、第三者との共有は一切ありません。

これは変換する文字列がしばしば機密だからです。プロプライエタリなコードベースの変数名、内部APIエンドポイント、記事タイトルの下書き、エンバーゴ下の顧客向けコピー、製品構造を明かすデータベースカラム名など。クラウドのケースコンバーターはすべての変換をリクエストログに記録し、「改善」や分析のために使用するかもしれません。ブラウザ専用のコンバーターは露出ゼロで、ページを一度読み込めばオフラインでも動作します。