wrap="soft"仅控制显示层视觉折行，不影响实际换行符生成；用户输入的换行符由操作系统、浏览器和输入法决定，常见为\r\n或\n，后端必须统一归一化处理。

后台拿到的换行符不固定，取决于用户操作系统和浏览器，常见的是 \r\n（Windows）或 \n（macOS/Linux），wrap="soft" 对它完全没影响。

wrap="soft" 根本不干预换行符生成

wrap="soft" 只控制显示层是否视觉折行，不影响用户按 Enter 时 DOM 中实际存入的换行字符。用户敲下回车，浏览器就照操作系统习惯写入：\r\n 或 \n；粘贴内容时还可能混入 \r 或 Unicode 换行符（如 \u2028）。这些全由输入源决定，wrap 属性一个字都改不了。

为什么你总看到 \r\n？

不是 wrap="soft" 导致的，而是因为：

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 多数 Windows 用户用 Chrome/Firefox，它们在 textarea.value 中把 Enter 存为 \r\n
• 表单以 application/x-www-form-urlencoded 提交时，\r\n 会被编码成 %0D%0A，后端解码后还原为 \r\n
• 但 macOS Safari 用户提交的很可能就是纯 \n，且不会被自动转成 \r\n

后端必须自己归一化，不能假设

别指望前端传来的换行符整齐划一。实操上必须：

立即学习“前端免费学习笔记（深入）”；

• 用正则 /[\r\n\u2028\u2029]+/g 切分，而不是 split('\r\n') 或 split('\n')
• 入库前统一转成 \n：比如 Python 用 text.replace('\r\n', '\n').replace('\r', '\n')
• 若需保留原始格式（如邮件正文），也得先识别再转换，不能直接信任 wrap 值

真正容易被忽略的点是：哪怕你设了 wrap="soft"，只要用户在 iOS 软键盘上点了「换行」键（而非「发送」），照样会插入 \n；而某些安卓键盘可能插 \r\n —— 这些行为跟 wrap 完全无关，全是输入法和系统定的。