共 33 篇相关文章
JSON.rawJSON方法是JavaScript中用于解决JSON.stringify序列化时精度丢失问题的实用工具。它允许开发者创建一个原始JSON对象，当这个对象被stringify序列化时，会将传入的JSON文本原样输出，不进行转义或修改。这主要解决了超大整数或BigInt类型数据在序列化时因浮点数精度限制导致的错误，例如超过2^53的整数会被自动四舍五入，而rawJSON能保持原值和数字类型，避免后端接口接收异常。使用时，必须传入合法的JSON原语（如数字、字符串、布尔值或null），不能是
这篇讲的是如何用Springboot快速搭建一个标准的Restful API服务。作者从一个完整的Web案例切入，演示了从数据库准备、项目结构解析到运行测试的全过程。核心聚焦在控制层的实现上，作者通过一个城市的增删改查Demo，清晰展示了如何使用`@RequestMapping`来映射不同的HTTP动词（GET/POST/PUT/DELETE），并配合`@PathVariable`和`@RequestBody`注解优雅地处理URL参数和请求体。文章还对REST风格的五大要素和HTTP方法做了简要知识梳理，帮助读者理解背后的设计理念。这是一个很典型的、即开即用的Springboot RESTful入门示例，体现了框架在简化Web服务开发上的便捷性。
这篇文章讲的是如何为前后端交互设计出清晰、可协作的API。它从API的基本定义出发，聚焦于一个实际问题：当团队协作时，混乱的接口定义会导致沟通成本激增。作者给出的核心方案是，团队必须先就返回值格式达成明确约定。 文章重点对比了两种主流的JSON返回值结构。第一种方式中，`errcode`字段可选，它的出现即意味着错误，并伴有可选的`msg`描述。成功则通常返回`items`数据或特定字段。第二种方式则要求`errcode`必须存在，并约定以`0`表示成功，其他值则为错误码。文章指出，这些错误码可以建立为公共码（如1001代表未登录），便于前端统一处理。 作者强调，JSON因其轻量和可扩展性已成为首选。通过建立这样的强约定，前端可以依据`errcode`进行明确的逻辑判断，而后端也能遵循规范返回数据。这种前置的、统一的接口设计，能够显著减少联调时的误解，让前后端协作更加顺畅，也使得接口本身更为健壮和可维护。
这篇讲的是JSON对象的两个核心方法：parse()与stringify()。作者从字符串与对象互相转换这一基本需求出发，清晰拆解了这对方法。 parse()负责“解析”，将符合JSON格式的字符串转换成可用的JavaScript对象，其translator参数允许自定义转换逻辑。而stringify()则执行反向的“序列化”，将对象转为字符串，并重点介绍了它强大的格式化能力：通过replacer参数可以选择性序列化指定属性，通过space参数则能控制输出字符串的缩进层级（数字指定空格数，字符串用作缩进符），大幅提升可读性。 文章通过对比示例与运行效果截图，直观展示了不同参数组合下的输出差异，比如如何只输出“name”字段，或如何用“###”作为缩进。最后，作者特别强调了一个实践原则：应避免使用eval()方法来解析JSON，指出了其潜在风险。 对于前端开发者而言，这篇文章将这两个高频使用的方法讲得细致透彻，不仅说明了“怎么用”，还阐释了“怎么用更好”，是扎实的技术参考。
这篇评测文章从实际开发需求出发，对 iOS 平台常用的六个 JSON/模型转换库进行了横向对比。评测覆盖了手动转换（Manually）、YYModel、FastEasyMapping、JSONModel、Mantle 和 MJExtension 这几个主流选择。 文章的核心围绕三个维度展开：性能、功能与容错性。在性能测试中，作者使用了两个典型用例（一个简单的 GitHub User 数据，一个复杂的微博数据），给出了直观的耗时对比图表。结论非常明确：YYModel 的性能显著领先，甚至接近手写代码的效率；Mantle 的性能在对比中最弱；JSONModel 和 MJExtension 处于中间水平。功能上，各库各有侧重，比如 FastEasyMapping 支持 CoreData，但使用者较少。 容错性测试则揭示了更实际的开发体验差异。YYModel 和 Mantle 会进行类型检查以避免崩溃，但处理策略不同：前者尝试自动转换并在失败时留空，后者直接终止转换并向上报错，更利于调试。MJExtension 在自动转换失败时可能直接赋值不匹配的类型，存在潜在风险。 总的来说，文章为开发者选择库提供了清晰的参考：追求极致性能可以看 YYModel，注重稳定和调试体验可考虑 Mantle，而 MJExtension 和 JSONModel 则是在功能与易用性上的常见折中选择。
这篇讲的是作者如何从零开始，动手实现一个兼容 SwiftyJSON 核心 API 的纯 Swift JSON 库。 作者最初的动机，是源于在实际项目中使用 SwiftyJSON 时遇到过非合法长字符串导致崩溃的问题，并对实现递归取值（如 `["key"]["key1"]`）的复杂性感到好奇。于是，在一个中秋节，他决定自己动手“复刻”一个，并命名为 JSONNeverDie（永不崩溃）。 文章的核心，是清晰地拆解了整个实现思路。作者设计了两个值类型（struct）：`JSONND` 作为入口负责从 `NSData` 等源解析数据；`JSONNDElement` 则专注于递归取值和类型转换。通过重载下标操作符，自然地实现了链式取值。随后，文章详细展示了如何为 `Int`、`String`、`Array` 等常见 JSON 类型实现从 `AnyObject` 到目标类型的“两级”转换，以及如何将对象序列化回格式化的 JSON 字符串。 作者不仅分享了代码，更传递了一种学习方法：通过亲自实现熟悉的工具（造轮子），能深入理解其设计精髓。最终完成的 JSONNeverDie 库，既是一个功能完备的轻量级替代品，也是这个探索过程的结晶。
这篇文章从社区中一个常见的争论出发，客观对比了XML和JSON这两种数据交换格式。作者没有简单地断言谁更优越，而是通过具体代码示例，细致地分析了两者在体积、表达直观性和功能特性上的关键差异。 文章指出，JSON在数据类型区分（如数字与字符串）、数组表示（用[]更直观）以及处理特殊字符（如换行）时更为简洁自然，这些特性使其在JavaScript生态中拥有原生支持的优势。然而，XML也并非没有强项：它支持声明和编码信息，可通过命名空间灵活组合不同定义，并且其DTD和XML Schema提供的验证能力远强于JSON Schema，能实现更严格的自描述和自校验。 在对象转换方面，JSON的解析和序列化在许多语言中已成为基础操作，而XML则通常需要依赖额外的类库和注解配置。文章还介绍了在线转换工具作为实用补充。总的来说，作者的分析平衡而深入，帮助读者理解两种格式各自的适用场景——JSON更轻便直观，适合Web API和前端交互；XML则在需要复杂验证、命名空间管理和文档自解释性的企业级或配置场景中更显稳固。
这篇讲的是如何从头实现一个JSON解析器。作者从JSON解析器的基本定义出发——即将JSON字符串转换为语言内存中的数据结构，对比了它与XML的差异，并梳理了JSON基本类型与Java数据结构（如Map、List）的映射关系。 文章的核心在于拆解实现思路。它强调解析器应采用流式单次扫描，本质是一个状态机。实现的关键步骤被清晰地勾勒出来：首先，需要封装一个`CharReader`来支持`peek()`操作，以便在不移动指针的情况下预判字符；其次，将原始字符流进一步抽象为Token流（如`BEGIN_OBJECT`、`STRING`等），从而大幅简化状态判断逻辑。最后，文章点出了处理嵌套结构的技巧：利用栈来管理Object和Array的构建，遇到开始标记时创建对应的Map或List并压栈，以此高效地完成递归解析。 整个实现过程体现了从具体到抽象、逐步化繁为简的设计思想，将看似复杂的解析任务分解为字符读取、Token识别和栈操作几个清晰的模块。
作者从JSON和JSONP这对常被混淆的概念出发，清晰地区分了它们的本质。JSON是一种轻量级、独立于语言的数据交换格式，它使用键值对和数组来描述数据，易于人读写和机器解析，几乎所有现代编程语言都支持它。 而JSONP则是一种利用HTML `
