!5701 【文档体验官】根据master更正3.1 release分支contribute文件夹的拼写错误等问题

Merge pull request !5701 from wusongqing/contribute-0622-zh

zh-cn/contribute/OpenHarmony-Java-secure-coding-guide.md

@@ -807,10 +807,10 @@ public class DeserializeExample implements Serializable {
 
     // 使用外部数据执行反序列化操作
     ObjectInputStream ois2= new ObjectInputStream(fis);
-    PersionInfo myPerson = (PersionInfo) ois2.readObject();
+    PersonInfo myPerson = (PersonInfo) ois2.readObject();
 ```
 
-上面的示例中，当反序列化操作的对象是攻击者构造的DeserializeExample对象的序列化结果，当`PersionInfo myPerson = (PersionInfo) ois2.readObject()`该语句执行时会报错，但是DeserializeExample对象中的`readObject()`方法中的攻击代码已经被执行。
+上面的示例中，当反序列化操作的对象是攻击者构造的DeserializeExample对象的序列化结果，当`PersonInfo myPerson = (PersonInfo) ois2.readObject()`该语句执行时会报错，但是DeserializeExample对象中的`readObject()`方法中的攻击代码已经被执行。
 
 **【正例】**（使用白名单校验）
 
@@ -826,7 +826,7 @@ public final class SecureObjectInputStream extends ObjectInputStream {
 
     protected Class<?> resolveClass(ObjectStreamClass desc)
         throws IOException, ClassNotFoundException {
-        if (!desc.getName().equals("com.xxxx.PersionInfo")) { // 白名单校验
+        if (!desc.getName().equals("com.xxxx.PersonInfo")) { // 白名单校验
             throw new ClassNotFoundException(desc.getName() + " not find");
         }
         return super.resolveClass(desc);
@@ -874,7 +874,7 @@ public final class HWObjectInputStream extends ObjectInputStream {
 (3) 在policy文件里设置白名单
 
 ```
-permission java.io.SerializablePermission "com.xxxx.PersionInfo";
+permission java.io.SerializablePermission "com.xxxx.PersonInfo";
 
 ```
 
@@ -910,7 +910,7 @@ permission java.io.SerializablePermission "com.xxxx.PersionInfo";
 实现：hibernate-validator 、Spring：
 
 - hibernate-validator 是 JSR 380（Bean Validation 2.0）、JSR 303（Bean Validation 1.0）规范的实现，同时扩展了注解：@Email、@Length、@NotEmpty、@Range等。
-- Spring validtor 同样实现了JSR 380和JSR 303，并提供了MethodValidationPostProcessor类，用于对方法的校验。
+- Spring validator 同样实现了JSR 380和JSR 303，并提供了MethodValidationPostProcessor类，用于对方法的校验。
 
 产品可自主选择合适的校验框架，也可以自主开发实现外部数据校验。
 
@@ -1414,7 +1414,7 @@ private void createXMLStream(BufferedOutputStream outStream, User user)
 **【正例】**（使用安全的XML库）
 
 ```java
-public static void buidlXML(FileWriter writer, User user) throws IOException {
+public static void  buildXML(FileWriter writer, User user) throws IOException {
     Document userDoc = DocumentHelper.createDocument();
     Element userElem = userDoc.addElement("user");
     Element idElem = userElem.addElement("id");

zh-cn/contribute/OpenHarmony-JavaScript-coding-style-guide.md

@@ -643,7 +643,7 @@ console.log(sum2); // 输出：0.6。所以对于二进制浮点数，(a + b) +
 
 1. 尽可能的采用整数值运算，因为整数在表示是不需要舍入；
 
-2. 使用JavaScript的原生方法`Number.prototype.toFixed(digits)`,`digist`参数表示小数点后数字的个数，不使用指数法，在必要时会进行四舍五入。使用该方法，在判断浮点数运算结果前对计算结果进行精度缩小。示例代码如下所示：
+2. 使用JavaScript的原生方法`Number.prototype.toFixed(digits)`,`digits`参数表示小数点后数字的个数，不使用指数法，在必要时会进行四舍五入。使用该方法，在判断浮点数运算结果前对计算结果进行精度缩小。示例代码如下所示：
 
    ```javascript
    parseFloat(0.1 + 0.2).toFixed(1); //0.3

zh-cn/contribute/OpenHarmony-JavaScript-docs-guide.md

@@ -18,7 +18,7 @@
 
   apidiff说明该版本所有接口的修改，包括新增、变更、废弃三种情况，若无修改则不用说明。
 
-  若该版本存在变更后无法适配的接口，需要在changlog中说明每一个接口需要做的适配操作。
+  若该版本存在变更后无法适配的接口，需要在changelog中说明每一个接口需要做的适配操作。
 
 - **FAQ**（ Frequently Asked Questions ）：开发者常见异常及处理建议。
 

zh-cn/contribute/OpenHarmony-c-coding-style-guide.md

@@ -540,11 +540,11 @@ int result = reallyReallyLongVariableName1 +    // Good: 加号留在行末
 
 表达式换行后，注意保持合理对齐，或者4空格缩进。参考下面例子
 ```c
-int sum = longVaribleName1 + longVaribleName2 + longVaribleName3 +
-    longVaribleName4 + longVaribleName5 + longVaribleName6;         // OK: 4空格缩进
+int sum = longVariableName1 + longVariableName2 + longVariableName3 +
+    longVariableName4 + longVariableName5 + longVariableName6;         // OK: 4空格缩进
 
-int sum = longVaribleName1 + longVaribleName2 + longVaribleName3 +
-          longVaribleName4 + longVaribleName5 + longVaribleName6;   // OK: 保持对齐
+int sum = longVariableName1 + longVariableName2 + longVariableName3 +
+          longVariableName4 + longVariableName5 + longVariableName6;   // OK: 保持对齐
 ```
 
 ## <a name="c2-10"></a>变量赋值

zh-cn/contribute/OpenHarmony-c-cpp-secure-coding-guide.md

@@ -3101,7 +3101,7 @@ if (file == NULL) {
 }
 
 if (IS_ERR(file)) {
-	printk("Error occured while opening file %s, exiting ...\n", MY_FILE);
+	printk("Error occurred while opening file %s, exiting ...\n", MY_FILE);
 	return 0;
 }
 

zh-cn/contribute/OpenHarmony-cpp-coding-style-guide.md

@@ -417,7 +417,7 @@ default:                // Bad: default 未缩进
 // 假设下面第一行已经不满足行宽要求
 ```cpp
 if ((currentValue > threshold) &&  // Good：换行后，逻辑操作符放在行尾
-    someConditionsion) {
+    someCondition) {
     DoSomething();
     ...
 }
@@ -428,11 +428,11 @@ int result = reallyReallyLongVariableName1 +    // Good
 表达式换行后，注意保持合理对齐，或者4空格缩进。参考下面例子
 
 ```cpp
-int sum = longVaribleName1 + longVaribleName2 + longVaribleName3 +
-    longVaribleName4 + longVaribleName5 + longVaribleName6;         // Good: 4空格缩进
+int sum = longVariableName1 + longVariableName2 + longVariableName3 +
+    longVariableName4 + longVariableName5 + longVariableName6;         // Good: 4空格缩进
 
-int sum = longVaribleName1 + longVaribleName2 + longVaribleName3 +
-          longVaribleName4 + longVaribleName5 + longVaribleName6;   // Good: 保持对齐
+int sum = longVariableName1 + longVariableName2 + longVariableName3 +
+          longVariableName4 + longVariableName5 + longVariableName6;   // Good: 保持对齐
 ```
 ## <a name="c3-10"></a> 变量赋值
 
@@ -516,14 +516,14 @@ int&p = i;      // Bad
 在文件头保护宏、条件编译、日志记录等必要场景中可以使用宏。
 
 ### <a name="r3-13-3"></a>规则3.13.3 禁止使用宏来表示常量
-宏是简单的文本替换，在预处理阶段完成，运行报错时直接报相应的值；跟踪调试时也是显示值，而不是宏名； 宏没有类型检查，不宏全； 宏没有作用域。
+宏是简单的文本替换，在预处理阶段完成，运行报错时直接报相应的值；跟踪调试时也是显示值，而不是宏名； 宏没有类型检查，不安全； 宏没有作用域。
 
 ### <a name="r3-13-4"></a>规则3.13.4 禁止使用函数式宏
 宏义函数式宏前，应考虑能否用函数替代。对于可替代场景，建议用函数替代宏。
 函数式宏的缺点如下：  
 - 函数式宏缺乏类型检查，不如函数调用检查严格  
 - 宏展开时宏参数不求值，可能会产生非预期结果  
-- 宏没有独产的作用域  
+- 宏没有独立的作用域  
 - 宏的技巧性太强，例如#的用法和无处不在的括号，影响可读性
 - 在特定场景中必须用编译器对宏的扩展语法，如GCC的statement expression，影响可移植性  
 - 宏在预编译阶段展开后，在期后编译、链接和调试时都不可见；而且包含多行的宏会展开为一行。函数式宏难以调试、难以打断点，不利于定位问题  
@@ -2178,12 +2178,12 @@ class LockGuard {
 public:
     LockGuard(const LockType& lockType): lock_(lockType)
     {
-        lock_.Aquire();
+        lock_.Acquire();
     }
     
     ~LockGuard()
     {
-        lock_.Relase();
+        lock_.Release();
     }
     
 private:
@@ -2651,11 +2651,11 @@ void func()
 ```
 
 ## <a name="c10-2"></a> 智能指针
-### <a name="r10-2-1"></a>规则10.2.1 单例、类的成员等所有机不会被多方持有的优先使用原始指针源而不是智能指针
+### <a name="r10-2-1"></a>规则10.2.1 单例、类的成员等所有权不会被多方持有的优先使用原始指针而不是智能指针
 **理由**
 智能指针会自动释放对象资源避免资源泄露，但会带额外的资源开销。如：智能指针自动生成的类、构造和析构的开销、内存占用多等。
 
-单例、类的成员等对象的所有权不会被多方持有的情况，仅在类析构中释放资源即可。不应该使用智能指针而增额外的开销。 
+单例、类的成员等对象的所有权不会被多方持有的情况，仅在类析构中释放资源即可。不应该使用智能指针增加额外的开销。
 
 **示例**
 

zh-cn/contribute/OpenHarmony-hdf-coding-guide.md

@@ -526,7 +526,7 @@ int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject)
     ret = InitDiver();
     // 自定义方法使用HDF的错误码
     if (ret != HDF_SUCCESS) {
-        HDF_LOGE("init drvier is failed");
+        HDF_LOGE("init driver is failed");
         return ret;
     }
     return HDF_SUCCESS;

zh-cn/contribute/docs-release-process.md

@@ -25,7 +25,7 @@
 
 如果你是某个业务SIG的成员，负责开发某一新特性，你需要与SIG Docs一起配合，确保在版本发布之前完成该新特性文档开发。否则，在最终的版本发布中未提供配套文档的特性可能被移除。
 
-如果你需要文档组织方面的帮助，请在`#SIG-Docs` ZULIK频道中提问求助。
+如果你需要文档组织方面的帮助，请在`#SIG-Docs` ZULIP频道中提问求助。
 
 1. 参考[评审人沟通表](docs-reviewers.md)，联系SIG Docs资料作者，沟通文档设计建议。
 2. 获取[文档模板](template)，了解文档写作规范。
@@ -33,7 +33,7 @@
 
 ### 提交PR评审
 
-所有新增内容的PR评审，为确保技术描述准确性需要指定相应业务SIG的技术专家参与技术评审，同时指定SIG Docs的资料专家评审文档规范性内容，请参考[评审人沟通表](docs-reviewers.md)在PR评论区@相关专家。也可以在`#SIG-Docs` ZULIK频道中反馈评审需求。
+所有新增内容的PR评审，为确保技术描述准确性需要指定相应业务SIG的技术专家参与技术评审，同时指定SIG Docs的资料专家评审文档规范性内容，请参考[评审人沟通表](docs-reviewers.md)在PR评论区@相关专家。也可以在`#SIG-Docs` ZULIP频道中反馈评审需求。
 
 在评审周期内，所有评审意见闭环修改后，该PR通过审核可以合并入仓的必要条件：
 

zh-cn/contribute/docs-reviewers.md

@@ -5,8 +5,8 @@
 
 | Feature      | Docs Reviewers                                               |
 | ------------ | ------------------------------------------------------------ |
-| 快速入门     | [@duangavin123](https://gitee.com/duangavin123)              |
-| 获取源码     | [@duangavin123](https://gitee.com/duangavin123)              |
+| 快速入门     | [@duangavin123](https://gitee.com/duangavin123_admin)         |
+| 获取源码     | [@duangavin123](https://gitee.com/duangavin123_admin)         |
 | 内核         | [@Austin23](https://gitee.com/Austin23)                      |
 | 驱动         | [@Qianchenya](https://gitee.com/Qianchenya)                  |
 | 设备开发指南 | [@Austin23](https://gitee.com/Austin23)                      |

zh-cn/contribute/写作规范.md

@@ -54,9 +54,9 @@
 
 图片统一存放到文档同级目录下的pic文件夹中（英文文档对应pic-en），如：
 
-“OpenHarmony\_DOCUMENTS/docs/quick-start/write-standard.md“中使用的图片，统一放置到
+“OpenHarmony\_DOCUMENTS/docs/quick-start/write-standard.md”中使用的图片，统一放置到
 
-“OpenHarmony\_DOCUMENTS/docs/quick-start/pic“目录下，文档中使用相对路径引用图片。
+“OpenHarmony\_DOCUMENTS/docs/quick-start/pic”目录下，文档中使用相对路径引用图片。
 
 >![](public_sys-resources/icon-caution.gif) **注意：** 
 >请使用原创图片，避免存在知识产权侵权风险。

zh-cn/contribute/许可证与版权规范.md

@@ -16,8 +16,8 @@
 
 ## LICENSE文件
 1. 每个开源仓必须有清晰描述的许可证信息，且许可证必须与OpenHarmony整体许可证规则一致，如用户态开源仓使用Apache License 2.0许可协议,LiteOS内核态开源仓使用BSD 3-clause许可协议。
-2. 每个开源仓的许可证文件必须为纯文本格式，放置于代码仓的根目录，里面包含该许可的全文，并且以”LICENSE“命名，不用带".txt",".md"等后缀。
-3. 如果开源仓的不同源码包含多种许可证，请将主许可证描述在以”LICENSE“命名的文件中，其它许可证请以”LICENSE-许可证类型-备注“命名并放置于仓的根目录或该许可证对应源码的根目录，同时在主许可证中描述各许可证文件位置及其适用的范围与场景。
+2. 每个开源仓的许可证文件必须为纯文本格式，放置于代码仓的根目录，里面包含该许可的全文，并且以“LICENSE”命名，不用带".txt",".md"等后缀。
+3. 如果开源仓的不同源码包含多种许可证，请将主许可证描述在以“LICENSE”命名的文件中，其它许可证请以“LICENSE-许可证类型-备注”命名并放置于仓的根目录或该许可证对应源码的根目录，同时在主许可证中描述各许可证文件位置及其适用的范围与场景。
 4. 每个开源仓的许可证文件必须要涵盖该仓下所有文件，确保各许可证的涵盖范围描述准确、精简，并且不要包含不在本仓发布的其它源代码许可等不必要的信息，比如要单独下载的依赖软件的许可不要包含在仓和许可证信息中。
 5. 如果开源仓在发布时以二进制形式发布，请确保许可证文件位于其发布格式的常规位置，如发布文件夹或压缩包的顶层目录，对于".jar"格式的文件，许可证可位于META-INF目录。
 

zh-cn/contribute/贡献文档.md

@@ -24,15 +24,15 @@
 
 高质量的问题反馈有助于我们不断完善文档内容和质量，您提供的信息越详尽，对我们问题改进越有帮助。
 
-1.  在Gitee页面中，“Issue“页签中单击“新建Issue“，在标题栏中描述问题，在编辑框中添加详细问题描述。
-2.  单击“创建“按钮，提交Issue，耐心等待文档团队成员确认您的问题。
+1.  在Gitee页面中，“Issue”页签中单击“新建Issue”，在标题栏中描述问题，在编辑框中添加详细问题描述。
+2.  单击“创建”按钮，提交Issue，耐心等待文档团队成员确认您的问题。
 
 >![](public_sys-resources/icon-note.gif) **说明：** 
 >**如何反馈一个高质量的问题？**
 >
 >-   提供问题的清晰描述，描述具体缺失、过时、错误的内容或者需要改进的文字。
 >-   解释该问题对用户的影响。
->-   将给定问题的范围限定在一个具体内容、任务。如果问题牵涉的领域较大，可以将其分解为多个小一点的问题。例如："文档需要优化" 是一个过于宽泛的问题，而 "XX开发指南缺少对XXX步骤的介绍" 就是一个足够具体的、可操作的问题。
+>-   将给定问题的范围限定在一个具体内容、任务。如果问题牵涉的领域较大，可以将其分解为多个小一点的问题。例如：“文档需要优化” 是一个过于宽泛的问题，而 “XX开发指南缺少对XXX步骤的介绍” 就是一个足够具体的、可操作的问题。
 >-   搜索现有问题的列表，查看是否已经有相关的或者类似的问题已被记录。
 >-   如果新问题与某其他问题或 PR 有关联，可以使用其完整 URL 或带 \# 字符的 PR 编号 来引用它。
 
@@ -43,7 +43,7 @@
 1.  在文档页面右上角单击“编辑“按钮即可跳转到对应的Gitee工程源文件页面。
 2.  在Gitee源文件md页面中，在对应内容处完成更改、修复。
 3.  修改完成后，可单击“预览“按钮，确认修改结果。
-4.  确认无误后，在“扩展信息框“中填写修改意见和补充信息、Signed-off-by邮箱信息触发DCO校验，单击提交审核。
+4.  确认无误后，在“扩展信息框”中填写修改意见和补充信息、Signed-off-by邮箱信息触发DCO校验，单击提交审核。
 
     例如：Signed-off-by: user.name <user.email> //与DCO签署邮箱保持一致
 
@@ -56,7 +56,7 @@
 
 ### 为发行版本贡献文档
 
-为了帮助开发者更高效使用OpenHarmony社区的每个Release版本，社区会根据每个版本规划的需求特性提供配套文档（如指南、API参考、开发示例、Release Notes、API Changelog、FAQ等）。有的需求涉及新增功能特性和文档，有的需求的是对现有特性和文档内容更新。
+为了帮助开发者更高效使用OpenHarmony社区的每个Release版本，社区会根据每个版本规划的需求特性提供配套文档（如指南、API参考、开发示例、Release Notes、API Changelog、FAQ等）。有的需求涉及新增功能特性和文档，有的需求是对现有特性和文档内容更新。
 
 欢迎开发者参与贡献，详细参考：[为发行版本贡献文档](docs-release-process.md)