斜体文本生成器_Unicode 数学斜体一键复制

使用方法

把要转换的文字粘进上面的文本框。页面打开时框里已经有一段示例 hello 斜体 italic 2026，转换结果会立刻显示在下方的只读框里，不需要点任何按钮。
变换内容时结果实时更新。文本较长时可以按 Ctrl + Enter（macOS 用 Cmd + Enter）手动重算一次，Enter 键留给换行——这里处理的是多行文本，回车换行比触发更重要。
「字形档位」决定用哪一段码位：默认的 数学斜体 U+1D434 是衬线体，笔画末端带装饰；换成 无衬线斜体 U+1D608 后线条粗细均匀，在手机小字号下更清楚。
小写 h 是个特例，由「小写 h 的替身」决定：默认用 ℎ（U+210E），也可以选 𝒉（U+1D489）或干脆保留 ASCII 的 h。原因见下面的原理一节。
点「复制结果」把斜体文字带走，粘到昵称、群名、签名、标题栏等只支持纯文本的位置。点「载入示例」还原样例，点「清空」清空输入。
下方对照表逐字符列出码位，支持「加载更多」「复制对照表」（TSV）和「导出 CSV」。

这个斜体文本生成器能解决什么问题

一是往不支持富文本的位置塞斜体。微博昵称、微信签名、抖音个人简介、QQ 群名、论坛的用户名、电商的商品标题，这些位置只收纯文本，没有加粗斜体的按钮，写 font-style: italic 或者  只会被当成普通字符显示出来。斜体文本生成器的做法是把斜体写进字符本身：换个码点，样式就跟着走了，任何能显示文字的输入框都认。

二是在没有 Markdown 的评论区做视觉强调。很多平台的评论区不解析 Markdown，但会原样显示字符，用它把一个词换成斜体就能起到分隔和提示的作用。

三是做排版样稿。给设计或运营同事发一版纯文本的标题候选，用斜体字标注需要强调的部分，比截图更省事，也比「这个字要斜体」的口头说明更准确。

四是批量验证字体覆盖。把一段英文字母转成斜体字符，粘到目标设备或目标 App 里看看有没有变成方框，就能快速判断这台设备的字体有没有覆盖 U+1D400 区块——做多端适配时这一步比查文档快。

本页不做这些事：不做真正的排版斜体（网页里能用 CSS 就用 CSS，本页产出的是换了字符的文本），不转中文与日文假名（Unicode 数学字母区块只覆盖拉丁字母和希腊字母），不做粗体，也不做花体、手写体、DoubleStruck 这些别的字形。要粗体请用页面底部的「粗体文本生成器」，要一次比较多种字形请用「特殊字体生成器」。

生成原理：码点偏移、U+1D455 空位与 ℎ 替代

核心只有两个 API：codePointAt() 与 String.fromCodePoint()。前者按码点读出一个字符的编号，后者按编号造出新字符。这里不能用 charCodeAt()：它按 UTF-16 码元读取，遇到编号超过 U+FFFF 的字符时会把一个字符劈成两个半截的代理码元，而 U+1D434 之后的全部码点都超过 U+FFFF，用错这个函数会得到一堆乱码。

映射规则是一次纯算术偏移。大写字母的斜体码点从 U+1D434 开始，小写字母从 U+1D44E 开始，所以 A 到 Z 依次落在 U+1D434~U+1D44D，a 到 z 依次落在 U+1D44E~U+1D467。换算公式就是「基址 +（原码点 − ASCII 起点）」：字母 A 是 0x41，斜体 A 就是 0x1D434 +（0x41 − 0x41）= U+1D434；字母 I 是 0x49，斜体 I 就是 0x1D434 + 8 = U+1D43C。小写同理，字母 a 是 0x61，得到 U+1D44E。

唯一要特殊处理的是小写 h。按偏移算，h 是 0x61 + 7，对应码点 U+1D455——而 Unicode 标准里这个码位没有分配字符，是数学字母区块里唯一的一个小写空位。原因是 U+210E 的 ℎ（PLANCK CONSTANT，普朗克常数符号）形状上就是一个斜体 h，标准把它当作既有字符使用，不再重复造一个。所以本页默认把 h 映射到 U+210E；如果你更喜欢笔画更重的效果，可以切到 U+1D489（粗体斜体小写 h），或者干脆保留 ASCII 的 h。三种选择都不会影响其它 25 个小写字母。

其余字符一律原样保留。数字没有斜体码位——数学字母区块里的十套数字分别是粗体、双线体、无衬线、无衬线粗体、等宽这几档，没有斜体数字，所以 0 到 9 转完之后还是 0 到 9。中文、日文假名、标点、空格、换行同样不变，因为斜体区块里根本没有对应的码点。这也是为什么转换后的文本看起来「只有英文部分变了样」。

这些字符在 Unicode 里带兼容性分解。数学字母区块的每个字符都有一条  兼容映射，指向它所模仿的普通 ASCII 字母。这意味着做一次 NFKC 或 NFKD 归一化，斜体 A 会被直接折叠回 ASCII 的 A，U+210E 的 ℎ 也会被折叠回 h。归一化在很多环节会自动发生：表单提交前的数据清洗、数据库的唯一索引、搜索引擎的索引器、部分输入法的候选处理。

本页只用字符串运算，不做归一化，也不联网。输入多少码点、映射多少次、拼接多少段，全部在当前页面完成；每次修改输入都会重新跑一遍，所以结果永远和你看到的输入一致。

完整示例（默认示例文本）

示例条件就是页面打开时的状态：文本框里是 hello 斜体 italic 2026，字形用默认的数学斜体 U+1D434，小写 h 用默认的 ℎ（U+210E）。

输出为 ℎ𝑒𝑙𝑙𝑜 斜体 𝑖𝑡𝑎𝑙𝑖𝑐 2026；
原文 20 个码点，输出也还是 20 个码点——映射是一对一的，字符个数不会变；
但输出的 UTF-16 码元数是 30，比输入的 20 多出 10，多出来的正是那 10 个被换成补充平面字符的字母；
整段文字里一共 11 个拉丁字母被替换（h、e、l、l、o、i、t、a、l、i、c），中文「斜体」和数字 2026 原样保留；
把 h 的替身换成 U+1D489，输出里第一个字符从 ℎ 变成 𝒉，其余 10 个字母不变。

再拿一个更短的例子看长度口径：Italic Text 是 11 个码点，转换后依然是 11 个码点，但由于 10 个字母都进了补充平面，按 UTF-16 数出来是 21 个字符，输出为 𝐼𝑡𝑎𝑙𝑖𝑐 𝑇𝑒𝑥𝑡。很多平台的长度限制是按 UTF-16 算的，这就是「明明只有 11 个字母却提示超过 20 字」的来源。

码位对照表与两档字形的选择

下图这张表逐字符给出两档字形的码位，以及它们在内存里占多少。看「UTF-16 码元」和「UTF-8 字节」两列就能明白：斜体字母看着还是 1 个字符，实际存储体积是普通字母的 4 到 2 倍。

原字符	数学斜体（U+1D434 起）	码位	无衬线斜体（U+1D608 起）	码位	UTF-16 码元	UTF-8 字节
a	𝑎	U+1D44E	𝘢	U+1D622	2	4
b	𝑏	U+1D44F	𝘣	U+1D623	2	4
h	ℎ	U+210E（替代）	ℎ	U+210E（替代）	1	3
i	𝑖	U+1D456	𝘪	U+1D62A	2	4
l	𝑙	U+1D459	𝘭	U+1D62D	2	4
o	𝑜	U+1D45C	𝘰	U+1D630	2	4
t	𝑡	U+1D461	𝘵	U+1D635	2	4
x	𝑥	U+1D465	𝘹	U+1D639	2	4
z	𝑧	U+1D467	𝘻	U+1D63B	2	4
A	𝐴	U+1D434	𝘈	U+1D608	2	4
I	𝐼	U+1D43C	𝘐	U+1D610	2	4
H	𝐻	U+1D43B	𝘏	U+1D60F	2	4
0	0	U+0030（无斜体）	0	U+0030（无斜体）	1	1
#	#	U+0023（标点）	#	U+0023（标点）	1	1

两档字形怎么选：数学斜体（U+1D434）笔画细、末梢带衬线，接近传统印刷体，适合放在标题和正文字号较大的位置；无衬线斜体（U+1D608）笔画等宽、没有装饰，在 12 到 14 像素的手机小字号下比前者清晰。两档的大写基址分别是 U+1D434 与 U+1D608，小写基址是 U+1D44E 与 U+1D622，各自连续 26 个码位、没有别的空位——小写 h 的空位只在数学斜体那一档里出现，无衬线斜体本来也是用 U+210E 补的，本页统一处理。

边界：补充平面、平台截断与归一化

输出字符全部落在补充平面。U+1D434 = 十进制 119860，远大于 BMP 的上界 U+FFFF（65535），也就是 Unicode 的补充多语言平面。JavaScript 字符串以 UTF-16 存储，一个补充平面字符占 2 个码元，所以任何按 length 计数的长度限制都会把斜体字母算成 2 个字符。
体积按倍增长。普通拉丁字母在 UTF-8 里是 1 字节，斜体字母是 4 字节；U+210E 的 ℎ 是特例，占 1 个 UTF-16 码元、3 个 UTF-8 字节。整段「Italic Text」转完是 41 字节，未转换时只有 11 字节。
平台截断是真实存在的。昵称、签名、简介这类字段普遍有长度上限，而后端多半按码元或字节数校验。11 个字母的单词转成斜体后就占 21 个码元，接近两倍；如果字段上限是 20，粘贴后末尾会被硬切掉，出现「少了一个字母」的现象。用之前先留出比原文多一倍的余量。
字体覆盖不全会显示成方框。U+1D400 区块在 Windows 的 Cambria Math、macOS 的 STIX 类字体里都有，但不少安卓定制系统、老旧设备、部分小程序内置字体没有覆盖，缺字形时会显示成豆腐块或者回退成普通字母。粘到群里之前先在目标设备上看一眼。
NFKC 归一化会把斜体「抹平」。这些字符带  兼容分解，任何做 NFKC / NFKD 的环节都会把它们还原成 ASCII。这意味三件事：用它写的昵称在别人搜索时等价于普通字母；平台的敏感词过滤同样能识别；数据库如果对唯一索引做了归一化，斜体用户名会和普通用户名撞车。
复制到 Office 里要小心。转到 Word、PPT 里粘贴时字符本身会被保留，但一旦经过「只保留纯文本」的粘贴或另存为纯文本再重新录入，某些编辑器会顺手做归一化，斜体就没了。这也是为什么它不适合当作长期存储的格式，只适合当排版手段。
无障碍与朗读。屏幕阅读器读到 U+1D44E 时不一定能像读普通字母那样发音，部分读屏软件会跳过或读成「未知字符」。内容里有关键信息（价格、日期、姓名）时，不要把斜体字符当作唯一表达方式。
输入上限 20000 个字符。超过会拒绝，不会静默截断——文本再长也没有意义，绝大多数平台的单条文本上限都远小于这个数。

常见问题

为什么小写 h 转出来是 ℎ，看起来和其他字母不是一个风格？

因为数学斜体小写 h 在 Unicode 里根本没有码位。小写 a 对应 U+1D44E，往后数 7 位落在 U+1D455，而这个码位在标准里是空的——数学字母区块里唯一一个未分配的小写字母位。标准认为 U+210E 的 ℎ（普朗克常数符号）已经是一个形状合适的斜体 h，所以不再另造。本页默认用它补位，也可以切成 U+1D489 的 𝒉，或者保留 ASCII 的 h。

为什么粘到微信、小红书里会少字或者显示成方框？

两种情况。少字通常是长度截断：斜体字母每个占 2 个 UTF-16 码元，按码元计数的字段会在上限处把尾巴切掉，先留出原文两倍的余量再粘。方框则是字体缺字形，说明这台设备的字体没有覆盖 U+1D400 区块，换一台设备或换成无衬线档位都未必有效，只能改用普通字母。

用斜体文字写的昵称，为什么别人搜不到？

因为搜索和去重通常会先做 NFKC 归一化，而斜体字母带  兼容分解，会被折叠成普通 ASCII 字母。别人输入普通字母其实匹配的是同一个字符，但如果搜索接口先按原始码点比对，两边就对不上。想让昵称可被搜索，末尾或开头保留一个普通字母的版本更稳妥。

数字和标点为什么一点变化都没有？

因为 Unicode 没有斜体数字。数学字母区块里的数字只有粗体、双线体、无衬线、无衬线粗体、等宽这几档，斜体这一档在字母之后就直接跳到了粗体斜体字母，没有对应的数字码点。标点和空格更是如此，斜体区块里没有它们的映像，只能原样保留。

它和粗体文本生成器是同一个东西吗？

不是，用的码位完全不同。斜体文本生成器走的是 U+1D434（大写）与 U+1D44E（小写）这一段；粗体走的是 U+1D400 与 U+1D41A，中间隔着两段字母表。两边的字符不能互换，视觉上一个是倾斜细笔画、一个是加粗正立，混用会明显不协调。

为什么 11 个字母的单词转完显示占了 21 个字符？

因为 UTF-16 用代理对表示补充平面字符：一个斜体字母在内存里是 2 个码元，字符串.length 数的是码元，于是 11 个字母变成 21（10 个字母 ×2 + 1 个空格）。按码点数是 11，两种算法都没错，只是口径不同，而多数表单校验用的是前者。

能靠它绕过平台的敏感词过滤吗？

不能，而且原因很具体：这些字符带  兼容分解，只要过滤链路里做过一次 NFKC 归一化，斜体写法就会被还原成普通字母，和直接写原词完全一样。反过来，如果过滤没做归一化，你写的词别人也搜不到、读屏也读不出，除了让内容失效没有任何好处。

为什么粘到某些网站的表单里会被拒绝？

因为很多表单在提交前会做字符校验：要么用正则限定只允许 ASCII，要么用 NFKC 归一化后做长度和唯一性检查。斜体字符既不落在 ASCII 范围内，又会和普通字母归一化冲突，遇到前者会直接报「包含非法字符」，遇到后者会提示「用户名已存在」。

斜体文本生成器