输出中应过滤的Unicode字符列表？

最近，由于浏览器支持的数据质量问题，我遇到了一个错误，我正在寻找一个安全的规则来应用字符串转义，除非需要，否则不使用两倍大小

UTF-8字节序列“E2-80-A8”（U+2028，行分隔符），Unicode数据库中完全有效的字符。但是，该序列表示一个行分隔符（是，除“0A”之外）

糟糕的是，许多浏览器（包括Chrome、Firefox和Safari；我没有测试其他浏览器）无法处理包含Unicode字符的字符串的JSONP回调。JSONP包含在一个非Unicode HTML中，我没有任何控制权

浏览器只是报告了此类JavaScript上的无效代码/语法错误，从调试工具和所有文本编辑器来看，这些代码/语法错误都是有效的。我猜它可能会尝试将“E2-80-A8”转换为BIG-5，并破坏JS语法

以上只是Unicode如何意外破坏系统的一个示例。据我所知，一些黑客可以使用RTL和其他控制字符为他们好。在Unicode规范中有许多“引号”、“空格”、“符号”和“控件”

问题:

是否有一个Unicode字符列表，供每个程序员了解我们可能不希望它们在应用程序中有效的隐藏特性（和bug）。（例如，Windows在文件名中禁用RTL）

编辑：

---

我不是在要求JSON或JavaScript。我要求提供Unicode处理所有程序的一般最佳实践。

它破坏了javascript，因为字符串中不能有换行符：

var myString = "

";

//SyntaxError: Unexpected token ILLEGAL

现在，UTF-8序列

“E2-80-A8”

解码为unicode代码点，其处理类似于javascript中的换行符：

 var myString = "
";

//Syntax Error

然而，书写是安全的

var myString = "\u2028";
//you can now log myString in console and get real representation of this character

这就是正确编码的JSON将具有的功能。我将研究如何正确编码JSON，而不是保留不安全字符的黑名单。（分别为U+2028和U+2029 AFAIK）

在PHP中：

echo json_encode( chr(0xe2). chr(0x80).chr(0xA8 ) );
//"\u2028"

---

A-Z、A-Z和0-9通常是安全的。在这62个字符之外，您将遇到一些系统问题。没有其他人能给你答案

---

例如，你提到域名。处理Unicode域名的唯一方法是遵循RFC 3454和RFC 5890-5893，并以这种方式处理数据。大多数Unix文件系统上的文件名是不包含/或\0的任意字节字符串。在功能上，将Unix上的文件名视为Unicode字符串而不中断任何内容本身就是一个问题。请注意，Windows文件名不是A-Z安全的；NUL和PRN等都是保留名称。每个领域都会有自己的小问题和怪癖，没有简单的总结能满足所有领域的需要。

看看Unicode图表。有一个非打印字符的列表。这些都是潜在的麻烦制造者。你的朋友U+2028有一群朋友：而且不只是在2000年的范围内

您可以全部使用核弹，也可以将它们分为不同的类别（SEP字符，如U+2028变为\n或正确转义），等等

---

HTH

有一个字符属性数据库和一个描述它的报告，该报告很好地说明了浏览器“应该”如何处理代码点。我喜欢“应该”这个词。最安全的是白名单，你可能会选择L | M | N | S、字母或标记、数字或符号

---

请看一下for a library

JSON只是一个示例。有XML编码、HTML文本、HTML属性、SQL、URI编码、文件名、电子邮件地址、域名等。在上面的示例中，它已经在使用框架提供的编码方法；这显然有一个bug。使用API并不能确保字符转义总是正确的，当它出现故障时，您可能不得不自己动手。更具体地说，JSONP是由Spring MVC API生成的。@DennisCheung JSONP是作为javascript代码执行的，而其他的只是数据，我看不出它们与此有什么关系。您描述的问题只适用于JSONP。令人好奇的是，尽管U+2028/2029在JavaScript中是无效的，但在JSON中是有效的（因此JSONP）。一个好的JSON编码器应该为了兼容性而避开它们，但实际上很少有人这样做。这就是为什么我要求的不是JS，而是Unicode。我打赌有十几个应该由谁来处理，为所有地方编写那些“转义/编码”API对我来说毫无意义。如果我们只能使用A-Z0-9，那么UTF-8的用途是什么？这听起来像是回到7位BBS网络的日子，你必须把一切都建立在基础上。Unicode有太多的设计功能，我们应该学习和理解，而不是忽略它们。我不是说不要使用Unicode。我是说你问过域名系统；你需要看看那些RFC 3454和5890-5893。您询问了文件名；POSIX文件名是不包含\0或\x2F的任意字节字符串。Windows文件名不区分大小写的UTF-16，需要排除一组ASCII保留名称。这些文件的正式答案没有相似之处。Windows文件名就是一个很好的例子。RTL在文件名规范中是有效的（有一个病毒在使用它），但事实上它应该被阻止。您无法从规范/RFC中读取该信息。即使编写RFC的人也需要知道Unicode，然后才能将这些危险字符排除在列表之外。RTL必须在文件名中有效，才能支持阿拉伯语和希伯来语。如果你说的是RLO角色，RFC3454确实提到了RLO。在任意情况下，RLO不是“危险”字符；在某些情况下，它可能会导致文本重新排序，这可能会造成混乱。您不想从任意文本中过滤它，在大多数情况下，即使在文件名中，阻止它也是有问题的；您需要接受磁盘上的文件名。这只是一个小领域；你想知道一切。是Unicode中的安全注意事项列表。正如您所见，它比字符列表复杂得多，并且在很大程度上取决于您的问题集