2026-07-02 · Calc-Tools 编辑

大小写转换工具：英文大小写转换的几种方式

命名风格这件事，写业务逻辑时几乎感觉不到它的存在，但它每年都在真实项目里制造故障：CI 在 Linux 上构建失败而本地一切正常，接口返回的字段名突然从 userName 变成 user_name，一份 JSON 配置在两个系统间往返之后多出几十 KB。这些问题全都属于同一类，源头是大小写与词边界的约定在系统之间不一致。

本文不重复工具页已经讲过的八种模式用法，而是换一个工程师视角：命名风格各自从哪个生态长出来，跨语言、跨平台、跨语种时会在哪里断裂，以及怎么把一个标识符在不同风格之间可靠地搬来搬去。

一、命名风格谱系：每种写法都有它的生态来源

命名风格不是审美偏好，而是历史与语言约束留下的沉淀。理解来源才能理解"为什么这里必须这么写"。

camelCase 与 PascalCase 来自 C 语言传统与早期标识符不允许空格的限制。C 把"下划线开头的标识符"保留给标准库，于是应用层自然转向大小写分词。Java 把它制度化：类名用 PascalCase、方法与变量用 camelCase，这套约定随 Java 生态扩散到 JavaScript、C#、Swift 和 TypeScript。

snake_case 的来源是 C 标准库自身的命名习惯（如 str_to_lower 一类的函数名），被 C 之后的脚本语言继承。Python 的 PEP 8 明确把 snake_case 定为函数与变量风格，Ruby 跟随同一路线；它还是 SQL 的通行风格，因为 SQL 既不区分大小写、又几乎不允许标识符里出现连字符。

kebab-case 能从代码标识符里出局，唯一原因是算术运算符的存在：user-name 在几乎所有编程语言里都会被解析成"变量 user 减去变量 name"。但它换了个场地存活下来，成为 CSS 属性与类名、HTML 属性、URL 路径和 npm 包名的通用风格。

SCREAMING_SNAKE_CASE 是常量与宏的约定，用来在阅读代码时提供一个"这个值不会变"的视觉信号。

值得记住的失败案例是匈牙利命名法。它最初的设计目标是在弱类型语言里把"类型"编进变量名（如 strName），但随着 IDE 和类型系统普及，声明能表达的信息远多于前缀，它退化成了一种噪声，最终被绝大多数现代规范弃用。

二、选型决策：不同场所该用哪种风格

选型原则可以收敛成一句话：跟随所在场所的既有惯例，只在系统边界上做一次显式映射。下面这张表把常见场所与它的惯例、以及最容易犯的错列在一起。

表里最需要留意的是前两行。JSON 字段风格是契约的一部分，一旦发布就很难单方面修改：客户端解析代码、缓存键、日志字段都可能依赖它。企业级实践通常是在网关或序列化层配置一次命名策略（例如后端 snake_case 自动映射为 camelCase），而不是让每一层各自手工转换。数据库这一行则涉及下一节要展开的大小写敏感问题。

三、大小写敏感陷阱：本地能跑、线上就炸

这类故障的共同特征是在开发机上永远无法复现，因为开发机的文件系统不区分大小写。

文件系统层面。 Linux 的 ext4 严格区分大小写，User.js 与 user.js 是两个不同文件；Windows 的 NTFS 默认不区分；macOS 的 APFS 默认不区分但可以格式化为区分。后果是代码里写 import User from "./user" 而磁盘上是 User.js 时，macOS 与 Windows 都不会报错，一旦部署到 Linux 容器就立刻失败。这也是"文件名与导入路径必须逐字一致"这条规范存在的唯一原因。

数据库层面。 MySQL 的表名与库名是否区分大小写由 lower_case_table_names 决定：Linux 上默认取值为 0（区分），Windows 与 macOS 上默认不区分。这意味着在 Windows 上开发时用 UserOrders 建表、代码里写 userorders 也能正常查询，迁移到 Linux 后立刻报"表不存在"。稳妥做法是建表时统一全小写加下划线，让代码在任何平台上都只有一种写法。

HTTP 协议层面。 头字段名本身是大小写不敏感的，但这不代表可以随手写。HTTP/2 与 HTTP/3 要求头字段名必须全小写，把 HTTP/1.1 风格的 Content-Type 直接塞进 HTTP/2 帧会被判定为协议错误。反过来，一些值是大小写敏感的：媒体类型里的参数、ETag 比较、Bearer 令牌，改动任何一个字母都会导致校验失败。

Git 层面。 在不区分大小写的文件系统上，git mv Readme.md readme.md 可能被静默忽略，即使 git status 显示重命名成功，实际改动也可能没有进入索引。需要改名时，用两段式操作（先改成中间名再改成目标名）比依赖强制重命名更可靠。

四、国际化陷阱：映射不是一一对应

大小写映射在 Unicode 里不是简单的"翻转"，这正是转换在国际文本上出错的根源。三个最典型的例子：

土耳其语的 i 问题。 土耳其语与阿塞拜疆语的大小写关系与英语完全相反：i 的大写是带点的 İ（U+0130），I 的小写是无点的 ı（U+0131）。在不指定语言环境时，I 一律转成 i，于是土耳其地名 İstanbul 会被改写成 istanbul，原有的点被永久丢掉。这类问题最常出现在"把用户邮箱按小写归一"的代码里——土耳其用户的地址本地部分被破坏后，邮件就再也匹配不上。

德语的 ß。 ß 没有对应的单字符大写形式，转大写时必须展开成两个字母：straße 变成 STRASSE，长度从 6 变成 7。反过来 STRASSE 转小写得到 strasse，与原始拼写不同，这说明大小写转换在德语里是不可逆操作，不能用作"归一后比较再还原"的中间步骤。

希腊语的词尾 sigma。 希腊语的小写 σ 在词尾写作 ς，两者的大写形式都是 Σ。因此大写转小写需要知道字符是否处于词尾，这已经不是逐字符映射能完成的工作，必须依赖分词。

这几例的共同教训是：把大小写转换当成无状态的字符替换，只在纯 ASCII 环境下安全。要做多语言归一，正确顺序是先规范化（NFC 或 NFKC），再按目标语言环境做大小写映射，最后再比较。

五、Title Case 的规则差异

"每个词首字母大写"只是 Title Case 的粗略描述。真正的规则由风格手册规定，而主流的两套手册结论并不一致。

最常被引用的例子是 to：Chicago 风格在它作为不定式标记时要求大写（How to Play Chess），AP 风格则一律小写（How to Play Chess 的 AP 版本仍是小写）。对于 and、of、the、in 这类短词，两套规范都倾向小写，但如果它出现在标题开头或结尾，又都要大写。这就是同一篇文章在不同媒体上呈现出不同标题的原因。

比规范差异更容易出错的是缩写词与复合词。像 NASA、iPhone、macOS 这类已经固化了内部大小写的专有名词，机械地按"首字母大写"处理会得到 Nasa、Iphone、Macos，把品牌写法改坏了。因此工程上的正确做法是维护一份"保留原样"的白名单，凡是命中白名单的词一律跳过转换。这也是自动 Title Case 永远需要人工复核一遍的原因。

六、真实算例：一个标识符在六种风格之间的搬迁

把命名风格转换做对，难点不在替换，而在分词。下面用同一个标识符走一遍完整的转换链。

算例一：拆开连续大写。输入 HTTPServer。直觉上它应该拆成 HTTP 与 Server 两个词。但如果先执行"小写字母后跟大写字母就断开"，得到的是 HTTPS 与 erver；如果先执行"连续大写后跟大写加小写就断开"，得到的是 HTTP 与 Server。两条规则的执行顺序决定了结果对错，正确写法必须把连续大写的规则放前面。拆出词列 [http, server] 之后，各风格的结果如下：

请注意 PascalCase 那一行：原始写法 HTTPServer 与转换结果 HttpServer 并不相同。这说明自动转换会丢掉"这个词本来是全大写缩写"这一信息，因此它是单向的——不要指望对同一字符串来回转换能回到原样。同一个规律在 XMLHttpRequest 上同样成立：拆分为 [xml, http, request] 之后，camelCase 得到 xmlHttpRequest，与原写法也不一致。

算例二：识别边界比识别大小写更难。输入 userID。这里没有连续大写串，只有两个大写字母结尾。正确分词是 [user, id]，snake_case 得到 user_id；若按"大写前不断开"的粗糙规则处理，会得到 userid 或 user_i_d。所以自动化转换上线前，务必先用一批真实标识符做回归，重点看缩写词结尾与数字相邻的样本。

算例三：命名风格对数据体积的影响。风格选择不只是可读性问题，它直接进入存储与网络开销。以两个字段为例：

单条记录只差 2 个字符，看起来无关紧要。但字段名在 JSON 里是随每条记录重复存储的：一百万条记录就意味着差值累积到百万字符量级，再叠加 gzip 之前的网络传输，就变成一个需要认真对待的数字。这也是列式存储、Protobuf 这类"字段名与数据分离"的方案在数据量上来之后更受欢迎的原因。

七、常见问题（FAQ）

数据库字段名到底该用 camelCase 还是 snake_case？

看数据库本身的惯例，不要看应用层语言。PostgreSQL 会把未加引号的标识符折叠成小写，因此 snake_case 是稳妥选择；MySQL 在 Windows 上默认不区分表名大小写、在 Linux 上区分，混合大小写会带来迁移风险。同一个字段名在应用层再做一次风格映射，比让数据库迁就语言更可靠。

URL 路径为什么普遍用短横线而不是下划线？

两个原因。其一是历史惯例：早期搜索引擎把连字符识别为词分隔符，而下划线常被当成词内字符，于是 word-counter 比 word_counter 更容易被切词。其二是可读性：下划线在小字号、带下划线的链接文本里会被文本装饰线盖住。Google 官方建议 URL 使用连字符，这也是主流做法。

土耳其语文本大小写转换为什么会出错？

因为土耳其语的大小写映射与英语相反：i 的大写是带点的 İ（U+0130），I 的小写是无点的 ı（U+0131）。不使用语言环境时，I 的小写一律得到 i，İstanbul 这样的地名会被改写成 istanbul 而丢掉原有的点。解决方式是显式指定土耳其语区域，或在转换后人工核对带点与无点的 i。

标题里的小词该不该大写？

取决于你遵循哪套规范，两套主流规范的结论并不一致。Chicago 风格把 to 视为不定式标记时大写，AP 风格则一律小写；对于 and、of、the 这类词，两套规范都倾向小写。真正的风险是整个页面混用两套规范，所以先选一套再统一执行。

为什么同一个文件名在同事电脑上能跑，到我这里就报找不到？

这是文件系统大小写敏感性差异的典型症状。Linux 的 ext4 严格区分大小写，Windows 默认不区分，macOS 默认不区分但可格式化为区分。代码里写 import User 而文件名是 user.js，在 Windows 上不会报错，部署到 Linux 才会暴露。排查时应先用文件名与导入路径的逐字对比确认大小写一致。

八、四个常见误区

误区一：文件名大小写不重要，反正系统不区分。区分与否取决于文件系统而不是语言。Windows 默认不区分、Linux 严格区分、macOS 默认不区分但可格式化为区分，于是同一个仓库在不同平台上可以表现出完全不同的行为，而这类差异只在部署时才暴露。

误区二：土耳其语问题是"边缘语言"的边缘问题。实际上它影响任何做了"统一转小写再比较"的场景：邮箱归一、用户名去重、搜索索引、URL slug 生成。只要用户里有一个土耳其用户，这条路径就会出问题，而它往往几年都不会被测到。

误区三：全大写等于强调，所以标题和按钮都该全大写。全大写会抹掉词形轮廓，长文本的阅读速度明显下降；在无障碍规范里，屏幕阅读器还可能把连续大写字母逐字母朗读，把单词读成字母串。强调应当交给字重、颜色或留白。

误区四：命名风格是个人偏好，不需要写进规范。风格本身确实没有绝对优劣，但不一致是有成本的。同一个系统里并存两种风格，会让代码搜索、批量重命名、自动生成文档全部失效，而这些工具恰恰是规模化维护的前提。

九、三条实用建议

• 建议一：把命名对照表写进项目文档，并且只写一张。明确列出数据库、API、前端、CSS、文件各自采用哪种风格，以及边界上由谁负责转换。这份表的价值在于消除"每层都以为别人会转"的空档，那是重复转换与漏转换的共同来源。
• 建议二：归一化操作一律显式指定语言环境。凡是把用户输入转小写用于比较或存储的代码，都应当在参数里写明语言环境，不要依赖运行时默认值。写完顺手加一条测试：土耳其语的 I 与其小写形式，德语的 ß 与其大写展开。这两条断言能拦住绝大多数国际文本回归。
• 建议三：批量改名与批量转换都在版本控制里做。先用大小写转换工具把一批字段名转换出来，再用文本对比工具核对差异，确认无误后一次性提交。避免"手工改一半、脚本改一半"这种最难排查的中间状态。字段名最终要落进结构化的配置文件时，可以先用JSON 格式化工具校验格式是否合法；如果你还在边写边统计文本量，字数统计工具可以顺手确认改动规模。

命名规范本身不产生功能，但它决定了代码库能不能被工具和新人理解。把它当成一次性的约定写清楚，比事后用脚本补救便宜得多；如果你还想看看不可见字符在复制粘贴时造成的另一类故障，可以接着读文本清理与不可见字符排查。