大小写转换器

天真地把标题里每个单词的首字母都大写,会产生一种在习惯了专业编辑标题的人看来明显不对劲的效果——"The Cat Sat On The Mat" 这种写法,大多数读者说不出具体哪里不对,却能立刻察觉出问题。AP 和芝加哥格式手册所使用的真正标题格式,会让简短的功能词——像 "a" "the" 这样的冠词,像 "and" "but" 这样的并列连词,以及像 "of" "in" "to" 这样的简短介词——保持小写,除非它们是标题的第一个或最后一个单词。"The Cat Sat on the Mat" 才是那种读起来经过精心设计、而不是机械式大写的版本。

这个区别之所以存在,是因为这些简短的单词承载的是语法功能而不是语义分量,把每一个都大写会在视觉上把标题压平成一堆同等强调的单词,掩盖了真正重要的词是哪些。编辑格式手册几十年前就确立了这个惯例,目的正是让标题保持易于扫读。

编程中的命名惯例彼此之间并不能互换,尽管表面上看起来相似,因为不同的语言和场景各自约定俗成地选择了不同的默认风格。在同一个代码库里混用它们,通常会被视为一种风格违规,而不是个人偏好。

对纯英文文本来说,大小写转换看起来很简单——把每个字母的码点按固定偏移量移动就行——但这个捷径在遇到带重音符号的字符时立刻就会失效,在某些非拉丁文字上失效得更严重。一个只支持 ASCII 的简单大写程序,会让 é 完全原样保留而不是转换成 É,在任何含重音符号的文本上都会静默失败。土耳其语的情况更棘手:字母 "i" 在土耳其语里大写后应该是带点的 İ,而不是基于英语规则的程序会产出的不带点的 I,把英语的规则套用到土耳其语文本上,会产出一个土耳其语读者一眼就能看出是错的结果。真正支持 Unicode 的大小写转换,会正确处理这些按语言而异的规则,而不是悄悄地破坏非英语文本。

这个工具不需要你先转换成一种格式、再重新操作一遍才能看到另一种格式,而是从同一份输入同时计算出每一种大小写风格,所以在大写、标题格式和 snake_case 之间切换,只是看一眼不同的结果,而不需要重新运行转换。当你还没决定用哪种风格时,这一点尤其有用——比如给一个新变量命名,camelCase 和 snake_case 并排放在一起看,能让这个选择变得具体,而不是抽象。