来自Chrome和Edge的断线错误提交

Question

背景:我们正在使用类型记录和反应产生一个基于浏览器的替代WinForms应用程序.这个前端通过一个SQL层将数据存储到一个C#数据库中.

问题:我已经发现，当使用<textarea>允许多行输入和显示时，Chrome和Edge只将换行作为LF提交，而火狐则为CRLF。HTML5规范指出，LF应在内部使用以确定长度等，但在提交内容时应将换行符转换为CRLF。

由于历史原因，由于三个不同的目的，元素的价值被以三种不同的方式规范化。原始值是最初设置的值。它还没有标准化。API值是在value IDL属性、textLength IDL属性中使用的值，以及由maxlength和minlength内容属性所使用的值。它是规范化的，因此行中断使用U+000A行提要(LF)字符。最后，在本规范中的表单提交和其他处理模型中使用了该值。它是规范化的，因此行中断使用U+000D回车返回的U+000A行提要(CRLF)字符对，此外，如果有必要，在给定的宽度下插入额外的换行符来包装文本。 获取元素API值的算法是返回元素的原始值，并将换行符归一化。 元素的值被定义为元素的原始值，并应用textarea包装转换。textarea包装转换是应用于字符串的以下算法： 将U+000D回车(CR)字符的每一次出现替换为没有跟随U+000A行提要(LF)字符的字符，以及没有在U+000D回车返回(CR)字符前面出现的U+000A行提要(LF)字符，替换为由U+000D回车返回U+000A行提要(CRLF)字符对组成的两个字符字符串。 如果元素的has属性处于硬状态，则使用实现定义的算法将U+000D回车返回U+000A行提要(CRLF)字符对插入到字符串中，以便每行不超过字符宽度字符。为了满足这一要求，行由字符串的开始、字符串的结尾和U+000D回车返回的U+000A行提要(CRLF)字符对分隔。

这是Chrome/Edge及其HTML5实现的问题吗? React是如何处理值的，还是我们使用React？

创建元素的代码将导致：

const [text, setText] = setState<string>("");
<textarea
value={text}
onChange={(e) => setText(e.target.value)}
/>

编辑:作为解决办法，我已经将上面的代码修改为

<textarea
value={text}
onChange={(e) => setText(e.target.value
?.split(/\r?\n/).join('\r\n')
.split(/\r\n?/).join('\r\n'))}
/>

我仍然有兴趣知道这是否是浏览器/React的问题。

Answer 1

更改后端期望数据的方式。

有时，我发现C#做C#想做的事情，只编写正确的实现就更容易了。在提交期间，我将使用JS将文本区域转换为数组，如下所示：

textArea.split("\n");

然后在C#上期待一个string[]并将其重新合并到C#中，类似于

string.Join("correct CLFR character", textArea);

这不是一个很好的解决方案，但有些战斗不值得去战斗。