From ec45d94b88a9fe649ad56b4f91e14beed7199187 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=B8=85=E9=A3=8E?= Date: Mon, 20 Dec 2021 21:17:42 +0800 Subject: [PATCH] Update ch4.md fix typo --- ch4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch4.md b/ch4.md index 506a0ae6..c5030eeb 100644 --- a/ch4.md +++ b/ch4.md @@ -66,7 +66,7 @@ * 这类编码通常与特定的编程语言深度绑定，其他语言很难读取这种数据。如果以这类编码存储或传输数据，那你就和这门语言绑死在一起了。并且很难将系统与其他组织的系统（可能用的是不同的语言）进行集成。 * 为了恢复相同对象类型的数据，解码过程需要**实例化任意类**的能力，这通常是安全问题的一个来源【5】：如果攻击者可以让应用程序解码任意的字节序列，他们就能实例化任意的类，这会允许他们做可怕的事情，如远程执行任意代码【6,7】。 * 在这些库中，数据版本控制通常是事后才考虑的。因为它们旨在快速简便地对数据进行编码，所以往往忽略了前向后向兼容性带来的麻烦问题。 -* 效率（编码或解码所花费的CPU时间，以及编码结构的大小）往往也是事后才考虑的。 例如，Java的内置序列化由于其糟糕的性能和臃肿的编码而臭名昭着【8】。 +* 效率（编码或解码所花费的CPU时间，以及编码结构的大小）往往也是事后才考虑的。 例如，Java的内置序列化由于其糟糕的性能和臃肿的编码而臭名昭著【8】。 因此，除非临时使用，采用语言内置编码通常是一个坏主意。