我正在尝试创建表单验证单元，除了“常规”测试之外，它还会检查编码。
根据这篇文章http://www.w3.org/International/questions/qa-forms-utf-8允许的字符是 0-31 范围内的 CR、LF 和 TAB，不允许 DEL=127。
另一方面，在 0x80-0xA0 范围内有控制字符。在不同的来源中，我看到它们是被允许的，而不是被允许的。我也看到这对于 XHTML、HTML 和 XML 是不同的。
有些文章告诉过FF也被允许？
有人可以提供一个很好的答案吗？什么可以给出，什么不能给出？
编辑：即使有http://www.w3.org/International/questions/qa-controls一些歧义
支持 C1 范围
但是表格显示它们是非法的并且之前显示的 UTF-8 验证允许它们？
我认为您正在以错误的方式看待这个问题。您链接的资源指定哪些编码值在(X)HTML中有效，但听起来您想验证来自 Web 表单的“响应”——例如，各种表单控件的值，传递回您的服务器. 在这种情况下，您不应该查看 (X)HTML 中的有效内容，而是application/x-www-form-urlencoded以及multipart/form-data和 MIME 类型中有效的内容。元素的HTML 4.01 标准<FORM>明确规定，对于 application/x-www-form-urlencoded，“非字母数字字符替换为 '%HH'”：
这是默认的内容类型。使用此内容类型提交的表单必须编码如下：
- 控件名称和值被转义。空格字符被 '+' 替换，然后保留字符被转义，如[RFC1738]第 2.2 节所述：非字母数字字符替换为 '%HH'、一个百分号和两个代表 ASCII 码的十六进制数字特点。换行符表示为“CR LF”对（即，`%0D%0A'）。
- 控件名称/值按照它们在文档中出现的顺序列出。名称与值之间用“=”分隔，名称/值对之间用“&”分隔。
至于包含什么字符编码（即%A0是不间断空格还是错误），这是由元素accept-charset上的属性和响应的（嗯，实际上是一个或请求）标头协商的。<FORM>GETPOSTContent-Type
波斯特定律：做事要保守；对你从别人那里接受的东西要自由。
如果您正在生成文档供其他人阅读，您应该避免/转义所有控制字符，即使它们在技术上是合法的。如果你正在解析文档，你应该努力接受所有的控制字符，即使它们在技术上是非法的。
首先，任何八位字节都是有效的。提到的 UTF-8 序列的正则表达式只是省略了其中的一些，因为它们在实践中很少被用户输入。但这并不意味着它们是无效的。他们只是预计不会发生。
您提到的第一个链接与验证 XHTML 中允许的字符没有任何关系......该链接上的示例只是显示了一种通用/通用模式，用于检测原始数据是否采用 utf-8 编码。
这是第二个链接的引用：
HTML、XHTML 和 XML 1.0 不支持 C0 范围，但 HT（水平制表）U+0009、LF（换行）U+000A 和 CR（回车）U+000D 除外。支持 C1 范围，即您可以直接对控件进行编码或将它们表示为 NCR（数字字符引用）。
我读这个的方式是：
如果您对 C1 范围内的任何控制字符进行编码（使用 base64 或十六进制表示）或将它们表示为 NCR，则支持它们。
C0 范围仅支持 U+0009、U+000A 和 U+000D。无法表示该范围内的其他控制代码。
这些范围内的 Unicode 字符在 HTML 4.01 中有效：
0x09..0x0A 0x0D 0x20..0x7E 0x00A0..0xD7FF 0xE000..0x10FFFF
在 XHTML 1.0 中……还不清楚。见http://cmsmcq.com/2007/C1.xml#o127626258
如果已知文档是 XHTML，那么您应该只加载它并根据模式对其进行验证。
你使用什么编程语言？至少对于 Java，存在检查字符串（或字节数组）编码的库。我猜其他语言也会存在类似的库。
我是否正确理解您的问题：您想检查表单提交的数据是否有效且编码正确？
如果是这样，为什么同时做几件事？恕我直言，将这些检查分开并逐步执行它们会容易得多。