大小写转换完整指南

在软件开发中，命名规范（Naming Convention）不仅仅是「代码好看」的问题——它直接影响代码的可读性、可维护性和团队协作效率。一个项目中如果混用多种命名风格，会让阅读者产生认知负担，增加理解成本。

命名规范的核心目标是：用一致的格式传达语义信息。例如，看到 UserManager 就知道这是一个类（PascalCase），看到 getUserById 就知道这是一个函数（camelCase），看到 MAX_CONNECTIONS 就知道这是一个常量（UPPER_SNAKE_CASE）。这种视觉上的约定俗成让开发者无需查看类型声明即可快速理解代码结构。

历史上，不同语言社区因设计哲学的差异形成了各自的命名传统：

• C 语言家族（C/C++/Java/C#）倾向于使用 camelCase/PascalCase
• 脚本语言（Python/Ruby）倾向于 snake_case
• Web 前端（HTML/CSS）倾向于 kebab-case

以下是四种最常见命名规范的全面对比：

以下汇总了主流编程语言的官方或社区推荐命名惯例：

• JavaScript / TypeScript（Airbnb Style Guide / Google JS Style）：变量和函数用 camelCase，类和构造函数用 PascalCase，常量用 UPPER_SNAKE_CASE 或 camelCase 前缀（如 const MAX_SIZE = 100）。CSS-in-JS 中类名常用 PascalCase。
• Python（PEP 8）：变量和函数用 snake_case，类名用 PascalCase，常量用 UPPER_SNAKE_CASE。「私有」成员以单下划线前缀（_internal），「名称改写」成员以双下划线前缀（__mangled）。
• Java（Oracle Code Conventions）：变量和方法用 camelCase，类和接口用 PascalCase，常量用 UPPER_SNAKE_CASE。包名全小写（如 com.example.util）。
• Go（Effective Go）：导出标识符（对外可见）必须首字母大写（PascalCase 风格），非导出标识符首字母小写。接口通常以 -er 后缀命名（如 Reader、Writer）。
• Ruby（Ruby Style Guide）：方法名和变量名统一 snake_case，类名和模块名 PascalCase，常量 UPPER_SNAKE_CASE。谓词方法以 ? 结尾（empty?），破坏性方法以 ! 结尾（save!）。
• Rust（RFC 430）：变量和函数用 snake_case，类型（struct/enum/trait）用 PascalCase，常量（static const）用 UPPER_SNAKE_CASE（SCREAMING_SNAKE_CASE）。
• Swift（API Design Guidelines）：类型和协议用 PascalCase，方法和属性用 camelCase（lowerCamel），常量用 camelCase 小驼峰。
• Kotlin（Android 官方风格）：与 Java 类似，但属性访问器可用更简洁的语法，文件级顶层函数用 camelCase。

大小写转换的核心是字符串模式匹配与替换。以下展示常见格式转换的正则表达式实现：

1. camelCase → snake_case

// JavaScript 实现
const camelToSnake = (str) =>
  str.replace(/[A-Z]/g, (letter) => `_${letter.toLowerCase()}`);
// 例：'getUserInfo' → '_get_user_info'
// 通常需要去除开头的下划线：.replace(/^_/, '')

2. snake_case → camelCase

// JavaScript 实现
const snakeToCamel = (str) =>
  str.replace(/_([a-z])/g, (_, letter) => letter.toUpperCase());
// 例：'user_name' → 'userName'

3. snake_case → PascalCase

// JavaScript 实现
const snakeToPascal = (str) =>
  str.replace(/(?:^|_)([a-z])/g, (_, c) => c.toUpperCase());
// 例：'user_name' → 'UserName'

4. 驼峰/蛇形 → kebab-case

// 统一转为 kebab-case
const toKebab = (str) => str
  .replace(/([a-z])([A-Z])/g, '$1-$2')   // 驼峰插入横线
  .replace(/_/g, '-')                      // 下划线替换为横线
  .toLowerCase();                          // 全部转小写

本工具的内部实现即基于上述正则逻辑，并额外处理了边界情况（连续分隔符、数字边界、非字母字符等）。

现代文本处理不仅涉及英文字母 A-Z，还包含大量 Unicode 字符。JavaScript 的 .toUpperCase() 和 .toLowerCase() 方法对 Unicode 有良好的支持：

• 德语 sharp s（ß）：'ß'.toUpperCase() 返回 'SS'（长度变化！）
• 土耳其语 I/i：土耳其语中 I 的小写是 ı（无点），i 的大写是 İ（带点）。普通 toUpperCase/toLowerCase 无法正确处理，需要使用 toLocaleUpperCase('tr')。
• 希腊语 Σ/σ/ς：Σ 的大写对应两个小写形式（词尾 ς vs 词中 σ）。
• 中文/日文/韩文：这些文字系统没有大小写概念，toUpper/toLower 保持原样不变。

本工具使用浏览器原生 API 处理 Unicode 转换，确保多语言文本的正确性。对于需要特定 locale 的场景（如土耳其语），建议使用 .toLocaleUpperCase(locale) 方法。

• 误区 1：所有语言都用 camelCase — 错误。Python 社区强烈推荐 snake_case（PEP 8），强行使用 camelCase 会被 linter 报错或 code review 指出。
• 误区 2：kebab-case 可以用作变量名 — 错误。大多数编程语言中 - 是减法运算符，不能用于标识符。kebab-case 仅适用于 HTML 属性、CSS 类名等非代码标识符的场景。
• 误区 3：toUpper/toLower 是对称操作 — 不一定。德语 'ß'.toUpperCase() 是 'SS'（2 个字符），再 .toLowerCase() 得到 'ss'（不是原来的 'ß'）。这种不可逆性在密码哈希比较等场景需要特别注意。
• 误区 4：常量只能用 UPPER_SNAKE_CASE — 并非绝对。JavaScript 中常量也常用 camelCase（如 React 的 useState），Go 语言甚至推荐用 camelCase 表示常量（因为导出规则已通过首字母大小区分）。
• 误区 5：自动转换可以替代人工审查 — 自动化工具能处理 90% 的常规情况，但缩略词（HTTP、URL、ID）的大小写往往需要根据具体项目的 style guide 决定。例如 parseXmlString 还是 parseXMLString 取决于团队约定。

在使用任何在线文本处理工具时，数据隐私是一个不容忽视的问题。许多在线工具会将您的输入内容发送到远程服务器进行处理，这意味着您的文本可能被记录、存储甚至泄露。

本工具采用完全不同的架构设计：

• 零网络请求：所有转换逻辑运行在您的浏览器中，无需将文本发送到任何服务器。
• 纯前端实现：核心算法基于 JavaScript 原生字符串方法（.toUpperCase()、.toLowerCase()）和正则表达式，不依赖任何后端服务。
• 即时清除：页面关闭后，所有输入输出数据即刻从内存中清除，不会留下任何痕迹。
• 开源透明：核心转换逻辑对所有用户公开透明，无隐藏的数据收集行为。

对于包含敏感信息的文本（如 API Key、数据库字段名、配置文件内容），选择本地处理工具是最安全的选择。