关于大小写转换器
这款免费的大小写转换器可以改变文本的大小写形式。粘贴文本后，一键即可切换为 UPPERCASE、lowercase、Title Case、Sentence case、camelCase、PascalCase、snake_case 或 kebab-case。
所有处理都在您的浏览器中完成——不会上传任何内容。这比听上去更重要，因为人们需要重新调整大小写的文本，往往是一列客户姓名、一份电子邮件地址清单，或者一份数据库导出文件。
各种形式，以及分别适合什么场合
UPPERCASE——每个字母都大写。适合简短的标签和缩写。不适合超过几个词的内容：大写字母抹去了单词的外形，而读者部分是靠轮廓来辨认单词的，因此全大写的句子读起来明显更慢。屏幕阅读器有时会把长的大写单词逐个字母念出来，而在消息里这读起来像是在喊叫。
lowercase——全部小写。适合在比较之前规范化数据，也适合标签、slug 和电子邮件地址。
Sentence case——句子的首字母大写，其余保持原样。这就是普通的行文方式，而且因为更易读、更易翻译，它也越来越成为标题和界面文案的标准。
Title Case——大多数单词首字母大写。在英语中，这是标题和书名的传统写法。麻烦在于，具体规则取决于您遵循哪一本风格指南。
camelCase——firstNameField。单词之间不留空格，除第一个词外每个新词首字母大写。这是 JavaScript、Java 和 C# 中变量和函数的标准。
PascalCase——FirstNameField。思路相同，但第一个词的首字母也大写。在大多数语言中用于类名和组件名，包括 React 组件。
snake_case——first_name_field。单词之间用下划线连接。这是 Python 和 Ruby 的标准，在 SQL 列名中几乎通用。
kebab-case——first-name-field。单词之间用连字符连接。用于 URL、CSS 类、HTML 属性和文件名——凡是连字符安全而下划线别扭的地方。
为什么 Title Case 比看起来难
两本风格指南，同一个标题会得出两种不同的结果。
难点在于决定哪些小词保持小写。按照 AP 风格，三个字母及以下的词保持小写，除非它位于标题的开头或结尾。按照 芝加哥风格，冠词（a、an、the）、并列连词（and、but、or）以及所有介词无论长短都保持小写——所以 Between 在芝加哥风格中保持小写，在 AP 风格中却要大写。
两者在两点上是一致的：首词和末词永远大写，以及不在清单上的其余部分一律大写。
此外还有一些词是任何自动转换器都无法正确处理的，因为它得知道您指的是什么。iPhone 必须保留小写的 i。eBay、macOS、PhD、NASA 和 iOS 都有固定写法。任何转换器都会把其中一些抹平，所以用 Title Case 处理过的标题在发布前始终值得由人过一遍。
为什么编程中有这么多种形式
这看上去像是毫无意义的门户之见。其实不是——原因在于标识符不能包含空格，所以每种语言都必须选定一种连接单词的方式，而这个选择就沿用了下来。
如今它们各自的归属：
- JavaScript / TypeScript——变量和函数用 camelCase，类和 React 组件用 PascalCase，文件名和 CSS 用 kebab-case
- Python——变量和函数用 snake_case，类用 PascalCase
- Java / C#——变量用 camelCase，类和方法用 PascalCase
- SQL——表名和列名用 snake_case，因为很多数据库本来就会把未加引号的名称转为小写
- CSS / HTML——通篇使用 kebab-case
- 常量——几乎所有语言都用 UPPER_SNAKE_CASE
- URL——kebab-case，因为搜索引擎把连字符视为分词符，把下划线视为连接符
转换器的实用价值就在于在它们之间切换：一个 snake_case 的数据库列会在上百处变成 camelCase 的 JavaScript 属性，而手工去做正是错别字的来源。
土耳其语的 i，以及其他陷阱
改变大小写并不总是可逆的，有时甚至并不安全。
无点的 i。 在土耳其语和阿塞拜疆语中，大写的 I 转为小写是 ı（没有点），而 i 转为大写是 İ（带点）。在土耳其语系统上把字符串转为小写再与 "identifier" 比较，曾经搞垮过真实的软件——这个缺陷有名到甚至有了专门的名字。
德语的 ß。 ß 的大写形式历来是 SS，所以把 STRASSE 转为小写并不会还原成 straße。大写的 ẞ 如今已经存在，但并未被普遍使用。
转为小写会摧毁缩写。 NASA 会变成 nasa，而且没有任何转换器能够还原，因为它无法区分缩写和一个喊出来的词。
不区分大小写并非普遍规则。 域名不区分大小写，但其后的路径区分——/About 和 /about 可能是两个不同的页面。电子邮件也是如此：域名部分不区分大小写，@ 之前的部分从技术上讲是区分的，尽管多数服务商把它当作不区分来处理。
使用方法
- 在文本框中输入或粘贴您的文本
- 点击某种形式进行转换
- 复制结果
需要知道的事
- 转为小写会永久丢失信息。 姓名和缩写中的大写字母事后无法恢复。如果以后可能用到，请保留原文。
- Title Case 需要人工核对，例如 iPhone、eBay、macOS、PhD 以及其他所有写法固定的词。
- Sentence case 正在标题领域胜出。 如今多数现代风格指南更青睐它——读起来更快，也更经得起翻译。
- 较长的内容请避免全大写。 它读起来更慢，可能让屏幕阅读器出错，而且在消息中读起来像在喊叫。
- URL 中请用 kebab-case，不要用 snake_case。 搜索引擎按连字符分词；下划线会把词粘在一起。
- 检查带重音的字符是否完好。 不支持 Unicode 的转换器会弄坏 é、ü 和 ñ。本工具能正确处理它们。
常见问题
Title Case 和 Sentence case 有什么区别？
Sentence case 只把第一个词的首字母大写，就像普通写作那样："How to convert text case"。Title Case 则把大多数词的首字母大写："How to Convert Text Case"。英语的新闻标题和书名传统上使用 Title Case，但如今多数产品和文档风格指南更偏好 Sentence case，因为它读起来更快，翻译起来也更干净。
什么是 camelCase，它和 PascalCase 有什么不同？
两者都把单词无空格连接，并把每个新词的首字母大写。camelCase 让第一个词保持小写（firstName）；PascalCase 则把它也大写（FirstName）。按照惯例，camelCase 用于命名变量和函数，而 PascalCase 用于命名类、类型和 React 组件。
URL 应该使用哪种形式？
kebab-case——用连字符连接的小写单词，例如 /free-online-tools。Google 把连字符视为分词符，把下划线视为连接符，所以 image_resizer 可能被读成一个词，而 image-resizer 会被读成两个词。小写也很重要，因为在大多数服务器上 URL 路径是区分大小写的。
数据库列应该使用哪种形式？
snake_case 是几乎通用的惯例：first_name、created_at。它契合多数数据库把未加引号的标识符转为小写的做法，也免去了给名称加引号的麻烦。之后您通常会在应用层转换为 camelCase，这正是人们使用转换器最常见的原因之一。
为什么有些词在 Title Case 下会出错？
因为转换器无法知道那个词究竟是什么。iPhone、eBay、macOS 和 NASA 都有固定写法，任何大小写规则都预测不出来。各风格指南对哪些短词保持小写也意见不一——AP 让三个字母及以下的词保持小写，芝加哥则不论长短都让冠词、连词和介词保持小写。发布之前，请务必通读一遍用 Title Case 处理过的标题。
我的文本会被发送到服务器吗？
不会。转换完全在您的浏览器中进行，因此您粘贴的任何内容都不会离开您的设备，也不会被保存。由于人们常常在这里调整导出的客户名单和电子邮件地址的大小写，这一点值得了解。
