文本大小写转换：命名规范的幕后逻辑
什么是文本大小写转换？
把 hello_world 变成 helloWorld，把 font-size 变成 fontSize，把 user id 变成 USER_ID——这些操作，统称大小写转换。
听起来简单？不就是改几个字母的大小写嘛。
但如果你真这么想，等着你的就是土耳其语的 İ、德语的 ß，还有 Python 和 Java 混编项目里那场没完没了的命名规范之争。
我打个比方：大小写转换就像给同一个单词换衣服。去参加 Python 聚会你得穿蛇形（snake_case）正装，去 JavaScript 的场子你得换驼峰（camelCase）便服。但有些词——比如”iPhone”——不管穿什么衣服，那个大写 I 加小写 p 的固执劲儿都不该变。可很多工具偏偏就在这种地方一刀切，把 iPhone 变成了 Iphone，读起来跟”爱丰”似的，别扭得很。
五种主流命名规范
先不管内部实现，咱们把市面上最常见的五种命名方式摆出来：
| 命名风格 | 示例 | 主流使用者 |
|---|---|---|
| camelCase（小驼峰） | userName, getUserById | JavaScript, Java, Go 导出变量 |
| PascalCase（大驼峰） | UserProfile, HttpClient | C#, Java 类名, React 组件 |
| snake_case（蛇形） | user_name, max_retry_count | Python, Ruby, SQL, C 标准库 |
| kebab-case（烤串） | user-name, font-size | CSS, URL slug, CLI 参数 |
| CONSTANT_CASE（常量） | MAX_SIZE, API_BASE_URL | 几乎所有语言的环境变量和常量 |
这些命名规范不是审美偏好——它们背后是实实在在的工程合同。Python 社区用 PEP 8 把 snake_case 写成了法律，违反它的代码连 PR 都合不进去。Java 社区反过来，camelCase 变量名和 PascalCase 类名是约定俗成的铁律。
我之前维护过一个 Python-JavaScript 混编项目，后端 Python 返回的 JSON 字段清一色 snake_case，前端 JS 又只能按 camelCase 读。中间写了厚厚一层字段映射——光命名转换就占了整个数据层代码的三分之一。说真的，项目一开始就该约定一种跨语言的字段命名规范，要么全 snake 要么全 camel，别两边互相迁就。
大小写转换的底层是怎么工作的？
在 ASCII 范围内，大小写转换简单得令人发指。
字母 A 的码点是 65，a 的码点是 97，差了 32。大写转小写就加 32，小写转大写了减 32。一个 bit 翻转的事儿：
A (0100 0001) → a (0110 0001) // 第 6 位置 1
a (0110 0001) → A (0100 0001) // 第 6 位清零
这也是为什么 ASCII 时代，大小写转换从来不出 bug——逻辑太简单，写不错。
但跳出 ASCII 的 128 个字符范围，世界就完全不一样了。
德语 ß（Eszett，尖 s）的大写是 SS。一个字符变成两个字符。你事先声明了 CHAR(1) 的数据库字段，一转大写直接撑爆。别笑，这是真实发生过的事。
更经典的雷是土耳其语的 İ（大写 I 带点）和 I（大写 I 不带点）。土耳其语里，小写 i 的大写是 İ（带点），而小写 ı（不带点 i）的大写才是 I（不带点）。
问题来了：大多数编程语言的 toUpperCase() 用的是当前系统的 locale。如果你的代码跑在一个土耳其用户的机器上，"index".toUpperCase() 会变成 "İNDEX"——那个 İ 跟 ASCII 的 I 不是同一个字符。
我之前做国际化时被这个坑惨了。一个 Java 后台服务跑了半年，突然有一天所有 String.toUpperCase() 全挂了——后来一查，是运维在服务器上装了个土耳其语语言包，JVM 的默认 locale 跟着变了。从那以后我写国际化代码，凡是跟大小写有关的逻辑，一律强制指定 Locale.ENGLISH。
Unicode 大小写折叠：比你以为的复杂得多
Unicode 标准定义的不只是简单的”大写↔小写”，而是三个相关但不同的概念：
- 大小写映射（Case Mapping）：一个字符的大写和小写形式，如
a ↔ A - 大小写折叠（Case Folding）：一种更激进的”去大小写差异”操作，主要用于大小写不敏感的字符串比较。比如
ß会折叠成ss，这样"groß"和"gross"在大小写无关的比较下才能被视为相等 - 全大写/全小写（Uppercase/Lowercase）：把一个字符串中所有有大小写之分的字符统一转成大写或小写
JavaScript 的 .toUpperCase() 和 .toLowerCase() 做的是第 3 种——而且它们不接收 locale 参数（toLocaleUpperCase 才接收），看上去好像避开了土耳其 İ 的问题，对吧？
并不。"i".toUpperCase() 在 Node.js 里的行为取决于 ICU 库的版本和运行时环境。有些版本返回 I，有些返回 İ。你没法靠”反正我没传 locale”来免责。
真要写健壮的代码，大小写无关的比较请用 String.prototype.localeCompare 或者自己实现 case-fold 逻辑。
核心特性
| 特性 | 说明 |
|---|---|
| ASCII 范围 | 大写 A-Z（65-90）和小写 a-z（97-122）偏移 32，极简 |
| Unicode 范围 | 大小写映射非对称（ß→SS, İ→i），不同语言环境规则不同 |
| 大小写折叠 | 比普通大小写转换更激进，专为大小写无关比较设计 |
| Locale 依赖 | 同一代码在不同 locale 下行为可能不同，需显式指定 |
| 不可逆性 | 部分转换不可逆："ß".toUpperCase() 得 "SS"，再 toLowerCase() 可能得 "ss" 而非原文 |
实际应用场景
1. 命名规范自动转换
后端给 created_at，前端要 createdAt——这个需求几乎每个全栈项目都会遇到。很多 ORM（比如 Python 的 SQLAlchemy、Node.js 的 Sequelize）内置了字段映射，底层做的就是大小写转换。
2. 搜索引擎的大小写无关匹配
用户搜 “iPhone”，你数据库里存的是 “IPHONE” 还是 “iphone”，搜索结果应该一致。处理方式一般有两种：建索引时统一做大小写折叠，或者查询时同时匹配多种大小写形式。前者更高效，后者更灵活但容易遗漏。
3. 排序和去重
做个通讯录，用户名字 “Alice”、“alice”、“ALICE” 应该被视为重复。碰上土耳其用户名还得绕开 İ 的坑。中文虽然没有大小写概念，但拼音排序时一样会撞上 locale 的问题。
4. URL 规范化
URL 的路径部分理论上大小写敏感（取决于服务器），但域名部分永远不区分大小写。Example.COM 和 example.com 指向同一个站。很多 Web 框架会强制把路由转成小写，防止 /About 和 /about 指向不同页面。
常见误区
误区一：toUpperCase / toLowerCase 是可逆的
不是。"Straße" → toUpperCase → "STRASSE" → toLowerCase → "strasse"。回不去了。这个不可逆性在需要保留原始大小写的场景里尤其致命——比如做大小写保持的 URL shortener 或文件系统路径映射。
误区二：所有语言的大小写规则都一样
土耳其语的 İ/I/ı/i 四个人一台戏，荷兰语的 IJ（一个字母的大写是两个大写字母），希腊语的 Σ 在词尾变成 ς——这些都是只有深入本地化开发才会撞见的真实问题。
误区三：大小写转换不涉及性能问题
单个字符串确实不涉及。但如果你在一个百万级字符串的列表里做大小写无关的去重，用错了方法（比如每次比较都重新做大小写转换而不是预计算折叠值），性能差异会是数量级的。我之前处理一个 500 万行的 CSV 去重任务，光是把 toLowerCase 换成预先做好的 case-fold key，时间就从 40 秒降到了 3 秒。
camelCase vs snake_case 怎么选？
这是个工程决策，不是审美问题。我把几个关键维度列出来：
| camelCase | snake_case | kebab-case | |
|---|---|---|---|
| 可读性 | 高（词间大写分界清晰） | 中（下划线可能干扰扫描） | 中（连字符易被忽略） |
| 输入效率 | 高（不需要按住 Shift 打 _） | 中 | 低（连字符需要按 -） |
| URL 友好 | 差（大小写歧义） | 差（下划线在链接下划线样式里隐身） | 好（SEO 用连字符分词） |
| 双击选中词 | 差（整个驼峰是一个词） | 好（下划线天然分词） | 好 |
| 文件系统兼容 | 好 | 好 | 好 |
| 正则匹配 | 繁琐 | 简单（\w+ 即可） | 简单 |
一个实用的建议：项目内部统一一种就够了。选哪个取决于你用的语言生态——Python 团队硬上 camelCase 会招骂，Java 团队用 snake_case 同理。全栈项目的话，后端按后端惯例，前端按前端惯例，中间加一层自动转换，这是最现实的方案。
常见问题
Q: "ß".toUpperCase() 到底返回什么？
在标准的 Unicode 大小写映射中返回 "SS"，两个字符。如果你需要一个字符一个字符地处理（比如限制用户名长度），这个长度变化会直接让判断逻辑出 bug。建议先做大小写标准化再做长度校验。
Q: 怎么彻底避开土耳其 İ 问题？
三步：第一，涉及大小写转换的逻辑永远指定 Locale.ENGLISH（Java）或 locale: 'en'（JavaScript 的 toLocaleUpperCase）；第二，大小写无关比较使用 localeCompare 而非手动转小写再 ===；第三，如果你的产品面向土耳其市场，不要想当然地用”先转小写再比较”，直接用 Unicode case folding。
Q: CSS 里为什么用 kebab-case 而不是 camelCase？
CSS 属性名对大小写不敏感（CSS 标准规定），而连字符自带分词效果——background-color 比 backgroundColor 更适合在样式表里被开发者扫描。另外，浏览器的 CSS 解析器本来就是按 - 做 token 分割的。
Q: 中文/日文/韩文有没有大小写？
没有。CJK 字符全是”没有大小写变体”的字符，Unicode 的大小写映射对它们返回自身，属于空操作。但这不代表你可以忽略它们——含有 CJK 字符的字符串做大小写折叠可能被其他字符（比如夹杂的数字符号、拉丁字母）影响，结果未必是恒等变换。
Q: snake_case 前面加 _ 是约定还是语法？
在 Python 里是约定（PEP 8 用 _var 表示内部变量），在 JavaScript 里也是约定，但在某些语言如 Dart 里 _ 前缀确实有语法含义（标记为私有）。话说回来，Python 社区里还有一层：双下划线 __var 会触发 name mangling，这个是语言层面的东西，跟单下划线约定不是一回事。