大小写格式转换器

转换器

在 camelCase、snake_case、kebab-case 与 PascalCase 等命名风格间互转。也能生成全大写下划线常量名与标题式写法,切换时无需手动改字。转换会保留数字与已有缩写,避免把 API 变成 aPI。转换前可预览每一行结果,确认无误再复制。可一次转换整列字段名与变量名。

文本
12 格式
小写hello world example_text
大写HELLO WORLD EXAMPLE_TEXT
首字母大写Hello World Example Text
句首大写Hello world example text
驼峰helloWorldExampleText
帕斯卡HelloWorldExampleText
蛇形hello_world_example_text
短横线hello-world-example-text
常量式HELLO_WORLD_EXAMPLE_TEXT
训练式Hello-World-Example-Text
点号式hello.world.example.text
路径式hello/world/example/text

关于 大小写格式转换器

变量名与文件名的大小写风格在不同语言与团队之间有不同约定:JavaScript 与 Java 偏好小驼峰,Python 与数据库字段偏好下划线,常量习惯全大写加下划线,类名用大驼峰,URL 与文件名多用小写连字符。把一段文字或一批标识在几种风格之间互转,是重构、接口对接与生成代码时反复要做的事。 转换原理是把输入按词边界切分,再按目标风格重新拼接。真正决定成败的就是「词边界怎么切」这一步:驼峰按大写字母切,下划线、连字符、空格按分隔符切,但缩写词例外——XMLHttpRequest 既可能是 XML 加 Http 加 Request,也可能被当成 X 加 M 加 L,两种切法会产出完全不同的结果,因此缩写词的切分规则必须由使用者显式约定或在转换前先把缩写作规范化处理。 使用要点:转换前先把输入统一成一种形态(例如全部转成下划线小写),再做目标风格的转换,两步走比一步到位更容易核对;批量转换时先拿十个样本验证结果,确认无误再处理全量,因为一旦切分规则不符合预期,全量处理的返工代价很高。对于包含数字的标识,要明确数字是否作为词边界的一部分,例如 base64 转成小驼峰时应当是 base64 还是 base64 加分隔,不同工具默认行为不一致。 边界与限制:大小写转换在多数语言里是「多对一」的映射,转完再转回去无法保证得到原文,因此不要把它当作可逆操作,也不要用它做标识归一化之外的事情。土耳其语的 i 分为有点与无点两种,德语有特殊的连字与大小写规则,这些语言的特例会让通用的转换函数出现意外结果;同样,URL 路径在服务器端区分大小写而 CDN 缓存可能不区分,把文件名风格改小写时务必确认所有引用同步更新,否则线上会出现图片或样式无法加载。 数据与隐私:本工具处理的通常是变量名、字段名与文件名,本身不含敏感信息,是本组工具里风险最低的一类。转换仍在浏览器内完成,不上传输入内容,可以断网使用。

在代码生成与数据映射的场景里,这项转换往往是自动化流程中的一环:数据库列名通常用下划线,接口字段常用小驼峰,把两者对齐的映射层如果命名规则不统一,就会出现「字段明明存在却取不到值」的问题,而且这类问题在编译期与类型检查阶段都发现不了。把命名规则写进项目规范并用脚本校验,比在出错后逐个排查便宜得多。团队协作中还有一点值得强调:提出命名规范时应当同时给出自动修复的手段,只提要求不提供工具,规范通常在两三个迭代后就会被绕过。 换算完成后,把同一个标识在代码、数据库与接口三处的写法列成一张对照表随文档维护,能让新成员在第一次改动时就有依据,而不是靠猜。 把这条对照表纳入新成员上手清单,能显著缩短第一次提交的往返次数,也减少评审时关于命名的无谓讨论。

实现原理

转换先按词边界切分再按目标风格重排。唯一的难点就是切分:驼峰按大写字母切、下划线连字符空格按分隔符切,而缩写词没有唯一答案——XMLHttpRequest 既可能切成三个词也可能切成五个字母,两种切法产出完全不同的结果。因此缩写必须在转换前显式规范化。

切分歧义
输入XMLHttpRequest
输出按「缩写整体」切分 → xml_http_request|按「逐字母」切分 → x_m_l_http_request

使用方法

  1. 打开「大小写格式转换器」
  2. 选择源格式与目标格式
  3. 根据需要调整输出选项
  4. 点击「转换」按钮,结果实时显示
  5. 复制或导出结果

使用场景

  • 变量改命名 — 把后端返回的 snake_case 字段批量转成前端习惯的 camelCase。
  • 生成常量 — 把一句描述转成 SCREAMING_SNAKE_CASE 用作枚举或环境变量名。
  • URL 别名 — 把文章标题转成 kebab-case 作为 SEO 友好的路由 slug。
  • 标题排版 — 把段落转成 Title Case 或句首大写,统一文档与按钮文案风格。
  • 类名规范 — 把组件描述转成 PascalCase,符合 React/类命名约定。

常见问题

它怎么判断单词边界?

工具会同时识别空格、下划线、连字符以及驼峰中的大小写跳变(如 fooBar)作为分隔点,再按目标风格重组,因此混合格式也能正确拆分。

数字会被当成单词的一部分吗?

会保留在相邻单词中。例如 user2Name 转 snake_case 得到 user2_name,数字不会被单独切走,符合大多数代码风格。

连续大写的缩写(如 HTTPURL)会怎样?

连续大写会被视为一个整体词,转 camelCase 时通常输出 httpurl 或按设定保留缩写,建议转换后核对缩写是否符合预期。

能处理多行批量转换吗?

可以逐行处理,每行作为一段独立文本转换,适合一次性整理一列字段名。

只想简单全大写/全小写怎么办?

直接选择大写或小写模式即可,它不会改动单词分隔,只调整字母大小写。

混合写法(如 user_Name_Test)能转换吗?

能。工具提取所有单词后按选中风格重组,因此只要单词边界清晰,任意混合分隔都能规整为目标风格。

转换后标识符仍不符合规范,怎么排查?

有些标识混用了多种风格,例如同时含大写缩写与下划线,切分规则无法判断作者的意图,结果会保留部分大写。遇到这类输入应先人工确定词边界,或在转换前把缩写统一规范化,不要期望工具自动推断;批量处理前用若干真实样本验证切分结果,比处理完再返工便宜得多。

camelCase 里遇到 IP地址、HTTP请求这类连续大写怎么处理?

这是 camelCase 的经典歧义:IPAddress 解析成 ip-address 还是 i-p-address 取决于分词策略。工具采用「连续大写作为一组」的常见约定(IPAddress → ip-address),与多数框架行为一致;有特殊需求时手动调整结果。

广告