JSON vs. XML vs. SQL vs. JS - 半特殊字符竞赛答案

【问题标题】：JSON vs. XML vs. SQL vs. JS - semi-special characters competitionJSON vs. XML vs. SQL vs. JS - 半特殊字符竞赛
【发布时间】：2017-02-11 19:46:09
【问题描述】：

我们从 MS-SQL 生成 JSON 和 XML，供客户端的 JS 函数使用（Cordoba 中的浏览器和应用程序）

JSON和SQL中“字段”的名称要遵循一定的逻辑，经常会复合其他字段，而JS函数使用split来分割，分别使用

到目前为止，要求是不变的...... 所以我们把一些更简单的东西命名为Something.Otherthing.EvenOther ...

好吧，从这里开始战斗，使用用于连接名称的符号：

. => destroy the outputted JSON as it make it multilevel
_ => can't be used as already in naming convention on 
/ => introduce escape \ and JSON/XML are a mess
\ => not possible in JSON
= => breakes the XML
^ => same, XML broken
@ => same again
$ % & and so on => not even elegant, and difficult to read data

到目前为止，我们最好的选择是：

· => so far the most elegant and working solution, but not so intuitive

这是真的吗？你们觉得怎么样？任何其他更好的字符/符号，直观，不被视为特殊字符，可以在 SQL 和 JS 中轻松处理并且不会破坏 XML 和 JSON，并且确保我们在接下来的三个月内无需更改？

【问题讨论】：

很难弄清楚您的具体问题是什么。提供minimal reproducible example 并更好地描述您正在尝试做的事情
我认为具体问题是“要求不可更改”:-)
你说这会破坏 XML，其他会破坏 JSON，等等……这些字符肯定可以正确转义，这样它们就不会“破坏”你的文件格式？
让我解释清楚，
让我解释得更好，我会尝试... 我们的目标是直接从 SQL 服务器生成 XML 和 JSON 以供 JS 使用。当然我可以转义符号，但是当我们正在构建我们的“标准”时，我们尝试使用不需要转义的符号，你能想象两个点、点和反斜杠应该在 URL 中转义吗？ http':'/\/\www'.'IBelieveThatNot'.'com/\WTF 为了提高可读性，我们的目标是一个不添加噪音的字符：This.is.easier.to.read This&Is&Not&Easy

标签： javascript sql sql-server json xml

【解决方案1】：

我理解正确吗？您只需要一个好看的分隔符，它不会破坏 XML？

你可以试试管道标志：

SELECT 'test|character' FOR XML PATH('x')

导致

<x>test|character</x>

【讨论】：

是的，没错，一个漂亮的分隔符，不会破坏 XML，也不会破坏 JSON，而且它在 JS 中是无痛的，管道问题：列名 'i|Customer|Country'包含 FOR XML 要求的无效 XML 标识符； '|'(0x007C) 是第一个错误字符。

【解决方案2】：

更像是一个 JSON 专家，但我采用了破折号。它们链接到我的类，并使命名约定更具可读性。

Select [Ugly-Field-Name]=25
      ,[Another-Ugly]  ='Some Name' 
 For  XML PATH('row')

<row>
  <Ugly-Field-Name>25</Ugly-Field-Name>
  <Another-Ugly>Some Name</Another-Ugly>
</row>

RAW 是可读的，如下所示（我的 EAV 函数）

Declare @xml xml = (Select [Ugly-Field-Name]=25,[Another-Ugly]  ='Some Name' for XML RAW)
Select * from [dbo].[udf-EAV](@XML)

Entity  Attribute       Value
25      Another-Ugly    Some Name

最后，我的 JSON 生成器返回（字段名称始终转换为小写）

{"status": {"successful":true,"timestamp":"2016-52-03 19:52:27 GMT","rows":1,"runtime_ms":0.15},"results": [{"ugly-field-name":25,"another-ugly":"Some Name"}]}

【讨论】：

在 js 中使用下划线更简洁，以便在处理响应时允许点表示法。不确定你的，但我的 js IDE 会自动建议用点但不使用 ['string-name']
@charlietfl 是的，但例如 $.go.application["banner-logo"] 返回“App_Images/Logo_Micro.png”，但通过方法我可以使用宏替换 aa="banner-logo ";$.go.application[aa]
但是有什么好处...增加了一个额外的步骤，并且更容易编写点以及使用它获得代码智能...仍然可以根据需要回退到[] 方法
@charlietfl 通过可重用函数和通用数据模式减少代码。它对我有用。
我还是宁愿自己有这两种选择......当你有选择的时候，在 js 属性名称中添加特殊字符似乎毫无意义