基于前后端分离的模版探索
在做前后端分离时，第一个关注到的问题就是 渲染，也就是 View 这个层面的工作。
在传统的开发模式中，浏览器端与服务器端是由不同的前后端两个团队开发，但是模版却又在这两者中间的模糊地带。因此模版上面总不可避免的越来越多复杂逻辑，最终难以维护。
而我们选择了NodeJS，作为一个前后端的中间层。试图藉由NodeJS，来疏理 View 层面的工作。
使得前后端分工更明确，让专案更好维护，达成更好的用户体验。
渲染这块工作，对于前端开发者的日常工作来说，佔了非常大的比例，也是最容易与后端开发纠结不清的地方。
回首过去前端技术发展的这几年， View 这个层面的工作，经过了许多次的变革，像是：
Form Submit 全页刷新 =& AJAX局部刷新
服务端续染 + MVC =& 客户端渲染 + MVC
传统换页跳转 =& 单页面应用
可以观察到在这几年，大家都倾向将 渲染 这件事，从服务器端端移向了浏览器端。
而服务器端则专注于 服务化 ，提供数据接口。
浏览器端渲染的好处
浏览器端渲染的好处，我们都很清楚，像是
摆脱业务逻辑与呈现逻辑在Java模版引擎中的耦合与混乱。
针对多终端应用，更容易以接口化的形式。在浏览器端搭配不同的模版，呈现不同的应用。
页面呈现本来就不仅是html，在前端的渲染可以更轻易的以组件化形式 (html + js + css)提供功能，使得前端组件不需依赖于服务端产生的html结构。
脱离对于后端开发、发佈流程的依赖。
方便联调。
浏览器端渲染造成的坏处
但是在享受好处的同时，我们同样的也面临了 浏览器端渲染 所带来的坏处，像是：
模版分离在不同的库。有的模版放在服务端 (JAVA)，而有的放在浏览器端 (JS)。前后端模版语言不相通。
需要等待所有模版与组件在浏览器端载入完成后才能开始渲染，无法即开即看。
首次进入会有白屏等待渲染的时间，不利于用户体验
开发单页面应用时，前端Route与服务器端Route不匹配，处理起来很麻烦。
重要内容都在前端组装，不利于SEO
反思前后端的定义
其实回头想想，在我们把渲染的工作从 服务端(Java) 抽出来到 浏览器端(JS) 的时候，我们的目的只是 明确的前后端职责划分，并不是非浏览器渲染不可 。
只是因为在传统的开发模式中，出了服务器就到了浏览器，所以前端的工作内容只能被限制在浏览器端。
也因此很多人认定了 后端 = 服务端 前端 = 浏览器端 ，就像下面这张图。
而在淘宝UED目前进行的 中途岛Midway 项目中，藉由在 JAVA – Browser中间搭建一个NodeJS中间层，试图把这个前后端的分割线，重新针对 工作职责 去区分，而非针对硬体环境去区分（服务器 & 浏览器）。
因此我们有机会做到模版与路由的共享，也是一个前后端分工中最理想的状态。
淘宝中途岛 Midway
在中途岛项目中，我们把前后端分界的那条线，从浏览器端移回到了服务器端。
藉由一个由前端 轻松掌控 且 与浏览器共通 的Nodejs层，可以更清晰的完成了前后端分离。
也可以让前端开发针对不同的情况，自行决定 最适当的解决方案 。而不是所有事情 都在浏览器端来处理 。
中途岛并不是前端试图抢后端饭碗的项目，目的只是把 模版 这个模糊地带切割清楚，取得更明确的职责划分。
后端 (JAVA)，专注于
数据格式、数据稳定
前端，专注于
控制逻辑、渲染逻辑
交互、用户体验
而不再拘泥于服务端或浏览器端的差异。
在传统的开发模式中，浏览器端与服务器端是由不同的前后端两个团队开发，但是模版却又在这两者中间的模糊地带。因此模版上面总不可避免的越来越多复杂逻辑，最终难以维护。
有了NodeJS，后端同学可以在JAVA层专注于业务逻辑与数据的开发。而前端同学则专注于控制逻辑与渲染的开发。并且自行选择这些模版是要在 服务端 (NodeJS) 或是 浏览器端 做渲染。
用著一样的模版语言 XTemplate ，一样的渲染引擎 JavaScript
在 不同的渲染环境　（Server-side、PC Browser、Mobile Browser、Web View、etc.） 渲染出 一样的结果 。
也因为有了NodeJS这一层，可以更细致的控制路由。
假如需要在前端做浏览器端路由时，可以同时配置服务器端的路由，使其在 浏览器端换页 或是 服务端换页 ，都可以得到一致的渲染效果。
同时也处理了SEO的问题。
模版共享的实践
通常我们在浏览器端渲染一份模版时，流程不外乎是
在浏览器端載入模版引擎 （xtmpleate, juicer, handlerbar, etc.）
在浏览器端载入模版档案，方法可能有
使用 &script type="js/tpl"& ... &/script& 印在页面上
使用模块载入工具，载入模版档案 （KISSY, requireJS, etc.）
取得数据，使用模版引擎产生html
将html插入到指定位置。
從以上的流程可以觀察到，要想要做到模版的跨端共享，重点其实在 一致的模块选型 这件事。
市面上流行很多种模块标准，例如 KMD、AMD、CommonJS，只要能将NodeJS的模版档案透过一致模块规范输出到NodeJS端，就可以做基本的模版共享了。
而后续的系列文章会针对Model的proxy与共享，做进一步的探讨。
因为有了中途岛这中间层，针对过往的一些问题都有了更好的解答，例如说
案例一 复杂交互应用 （如购物车、下单页面）
状况：全部的HTML都是在前端渲染完成，服务端仅提供接口。
问题：进入页面时，会有短暂白屏。
首次进入页面，在NodeJS端进行 全页渲染 ，并在背景下载相关的模版。
后续交互操作，在浏览器端完成 局部刷新
用的是 同一份模版 ， 产生 一样的结果
案例二 单页面应用
状况：使用Client Side MVC框架，在浏览器换页。
问题：渲染与换页都在浏览器端完成，直接输入网址进入或f5刷新时，无法直接呈现同样的内容。
在浏览器端与NodeJS端共享 同样的Route 设定
浏览器端换页时，在浏览器端进行Route变更与 页面内容渲染
直接输入同样的网址时，在NodeJS端进行 页面框架 + 页面内容渲染
不管是浏览器端换页，或直接输入同样的网址，看到的内容都是 一样的 。
除了增加体验、减少逻辑複杂度外。更解决了 SEO 的问题
案例三 纯浏览型页面
状况：页面仅提供资讯，较少或没有交互
问题：html在服务端产生，css与js放在另外一个位置，彼此间有依赖。
透过NodeJS，统一管理html + css + js
日后若需要扩展成复杂应用或是单页面应用，也可以轻易转移。
案例四 跨终端页面
状况：同样的应用要在不同端点呈现不同的介面与交互
问题：html管理不易，常常会在服务端产生不一样的html，浏览器端又要做不一样的处理
跨终端的页面是渲染的问题，统一由前端来处理。
透过NodeJS层与后端服务化，可以针对这类型复杂应用，设计最佳的解决方案。
过去的AJAX、Client-side MVC、SPA、Two-way Data Binding 等技术的出现，都是试图要解决当时的前端开发遇到的瓶颈。
而NodeJS中间层的出现，也是在试图解决现今前端被侷限在浏览器端的一个限制。
这边文章专注于前后端模版共享，也希望能抛砖引玉，与大家一起讨论如何在NodeJS中间层这个架构下，我们可以怎样的改善我们的工作流程，怎样的跟 后端配合，来把 前端 这个工作做得更好。
【附】相关文章列表3881人阅读
& & & 软件的首要技术使命是管理复杂度(Complexity)。这是&&代码大全&&中的一个标题。软件本质性困难的根源都在于复杂性。Dijkstra指出没有谁的大脑能容得下一计算机程序。正如社会进步催生社会分工一样，软件行业也自然而然地发展出来了模块化方法，将整个系统分解为多个子系统来降低问题的复杂度，分而治之。它有两个主要的目的:
& &1. 分工 &(角色与责任)
& &2. 信息隐藏 (协作)
& & & 分工可以更容易实现并行开发，带来开发效率的提升。分工还可以隔离变化，使得软件应对变化的能力增强。而信息隐藏则降低了对程序员的要求，能够更好地掌握模块内的复杂度。
& & & 另一种将模块化视为系列决策组合的看法，只关注到了模块化过程的形式，而忽视了模块化的目的和目标。决策固然是贯穿整个开发过程，但并不是专属于模块化。还是应当强调模块化背后的目的以及使用的方法，关注其产出的结果：模块+接口。
& & & 模块是分工的结果，接口则由协作定义。
& & &为了强化模块的协作，上世纪80年代引入了(也称为Design by Contract，或Contract Programming)的概念，要求清楚地定义功能的前置条件和输出结果。正像是商业活动中使用合同(contract)来约束和规范商业协作。
& & & 凡事过犹不及，模块化的粒度多大才合适？在&&Unix编程艺术&&中第四章有专门一个章节进行探讨，可以作为一个参考。模块化并不能完全解决耦合和复用的问题，所以90年代末又有了将模块中分散着的各个相似的功能集中起来的设计实践，(AOP, Aspect Oriented Programming)。其实也是为了将分散的逻辑抽取出来，模块化。
& & & 这些都是对模块化的完善。
面向对象编程同模块化
&& & &面向对象编程其实是一种能更好地支持模块化的编程方法，可以更好的达到了模块化的两个目标。在系统级别的模块划分上，并没引入什么特别的贡献。但在系统模块的内部，却较以前面向过程的开法更方便地实现了逻辑上的模块，更为重要的是它在信息隐藏上的突破。
&&&&&举例来说，以前在某个模块(组件)内部，以面向过程来写代码时，很容易产生出复杂的函数关系和无法约束数据访问的问题。而面向对象却使用不同的类或接口很好的在内部又建立区不同的逻辑模块来。不同的类对象之间的访问和存取都受到各自实现的约束，真正做到了信息隐藏。
&&&&&虽然有时面向对象的编程语言也被发展的过于庞大，其本身的复杂度也越来越高，特别是如果过于专注于分层而引入了更多的细节，反而增加了复杂度。语言本身是个工具，如何使用好这个工具最终取决于设计者。它既可以用来雕琢天使，也可以用来创造魔鬼。
模块化的设计方法
& & & 如何进行模块化设计？要么从上到下(Top-Down)，要么从下向上(Down-Up)。从上到下时常常导致领域问题和技术细节考虑不足，而从下至上的设计方法却有时却让整合出了问题。所以还需要有设计验证的工作和迭代设计的流程。
&&&&&从上至下，是从整个系统的层面入手，切分子模块。可以按业务功能分(垂直切分)，如ERP分为财务、人事、制造/生产管理、采购、销售、资材管理(仓库)等。也可以按逻辑功能分(水平切分)，如UI模块、业务逻辑模块、数据持久层、报表管理模块等。
&&&&&为了实现并行开发，模块间的接口必须被清楚明确的定义出来，包括接口函数和公共数据结构。关于接口的设计，也有很多计论。比如下文:
&&&&&如何评估模块化的效果呢？Eric.Raymond推荐至少可以从两方面考察:紧凑性和正交性。紧凑性可以用来评估模块化的划分是否合适，而正交性则是关注在模块间的协作水平。为了提高紧凑性，就要减少方案中的特例和边界情况，尽量使用统一明确的规则来组织系统。
WebKit的模块化
&& &模块化的概念绝大多数人都知道，正如前面所说的，结果决定于设计者，而不是工具。向好的设计学习，是掌握模块化的好方法。
&&&&&后面将对目前使用最广的浏览器内核WebKit的模块化设计进行分析。
&&&&&Eric.Raymond在&&Unix编程艺术&&中讨论模块化时，多次提到浏览器设计，足可见浏览器设计的代表性。
&&&&&首先做个简要说明。我们常说的WebKit是浏览器内核，开发者只要在它上面加一个界面层就可以开发出一个浏览器。它的功能包括对网页的加载、解析、显示以及处理用户的交互。随着网页功能越来越复杂多样，浏览器内核的功能也是日益强大，其内部实现也是相当庞大。
&&&&&根据对Safari使用的WebKit进行统计(使用的是cloc.pl)，其中有13354个源文件，共计1645695行代码，不含注释等非代码行的内容。面对这样的代码，还要不断升级来满足各种标准和网页的变化，以及用户的需求变化，如果没有良好的模块化，是根本无法完成的。
&&&&&面对庞大复杂的浏览器软件，对于浏览器框架首要任务是区隔出核心功能及非核心功能，什么是变化的，什么是相对稳定的。像许多大型的开源项目一样，WebKit的开发也深受Unix的开发文化的影响。于是&只将一件事做好&的格言就决定了WebKit不会去做浏览器，只是浏览器的核心引擎。展示网页内容就是WebKit的核心功能。
&&&&&关于浏览器设计，有一个简洁的概念模型:
& & &(来源: &&A Reference Architecture for Web Browsers&&,Alan Grosskurth& Michael W. Godfrey)
&&&&&这个模型展示出来浏览器设计的主要要素。其中用户界面面向的是用户交互，渲染引擎则面向对各种页面标准的支持，而中间的浏览器引擎处理用户的操作，并回馈网页上的交互，是用户界面与渲染引擎交互的桥梁。数据持久层则是用于存储网页会使用的如Cookies和缓存一类的数据。在最下面一层，则是为渲染引擎提供支持的功能模块。
&&&&&虽然WebKit并没有完全按这样来切分，但其思想是相似的。WebKit将上图中的绿色部分构成了WebKit的主要部分，形成自己的结构:
&&&&&UI部分可以自由定制，通过WebKit2调用WebCore的功能。WebCore可以通过封装的接口方便地选择JSC或V8做为它的JavaScript解释器。在整个项目中所使用到的公共数据结构和一些与平台无关的辅助性的功能都被放到了WTF中。
&&&&&我在下面主要探讨WebKit模块化的要点:
&&&&&&&&&&1. 封装核心功能，与用户界面隔离。
&&&&&&&&&&2. 提取公共的基础代码和数据结构，封装成库，供其它模块使用。
&&&&&&&&&&3. 使用插件机制支持扩展需求。
&&&&&&&&&&4. 为跨平台提供良好的支持。
& & & & & 5. 持续改进。
应对变化 - 封装核心功能，与用户界面隔离
&& & &变化无处不在，但基本上是万变不离其踪。软件中的变化可以归纳为用户需求变化和技术环境变化等。在技术上来说，应用软件中的变化体现在两个层面，一个是外部展现的变化，如界面操作、事件响应等，另一种则是运行策略上的变化，在不同的配置或环境下执行的路径不同。对于浏览器软件还有一项重要的环境引起的变化：标准的变化。比如现在正在发展的HTML5、CSS3等。
&&&&&WebKit2的应对之道就是分离原则:接口与引擎分离，策略与机制分离。(以下内容参考了WebKit官网的介绍:)
&&&&&首先在接口与引擎的分离上，WebKit2除了提供一组C的API外，还将用户进程与内核进程分隔开来，如下图所示。上面的UI Process包含了UI和WebKit2的UIProcess层，下面的WebProcess则包括了WebKit内核模块和WebKit2的WebProcess层。这样做可以带来更好的健壮性、安全性和性能。因为如此UI与内核的耦合降低了，提高了正交性，大大降低了系统的复杂度。
& & (*源自WebKit官网)
&&&&&为了应对在外部显示的变化及运行策略上的变化，WebKit2提供的是非阻塞式的API，有丰富的回调机制。包括:
消息通知式的客户端回调(Notification style client callbacks)。在适当的时机通知客户端但并给它机会去执行什么干预操作，仅仅是通知而已。策略式的客户端回调(Policy style clients callbacks)。允许由客户端决定某个行为。策略配置(Policy settings) 让在客户端就可以预先设定一些策略选项。如一些预设文本之类的内容。可注入的代码(Injected code)。允许在Web Process中加载并执行特定的代码。实现在Web Process中的InjectedBundle模块。
建构基础 - 提取公共的基础代码和数据结构，封装成库
&& &&核心业务代码与非核心业务代码的分离,正是面向方面编程(AOP)的主要思想。在不运用AOP框架的情况下，也可以达到一定效果。关键在于识别并抽取出公共的数据结构及操作。
& & 如智能指针和内存分配器。WebKit中提供了丰富的智能指针操作来简化程序员的负担，而它们都被封装到了WTF中。
为了优化内存分配的性能，特别是小内存的分配和跨线程的安全性，WebKit使用了TCMaclloc来作为系统缺省内存分配器的替代者。使用宏定义就可以在它们之间切换。
& & &这些功能无论在WebCore，还是WebKit2都会被使用到。而它们也并不是核心业务，抽取出来，降低了核心业务部分的复杂度，好处不言自明。
灵活健壮 - 支持标准的插件机制
&& & &在云计算快速发展的时代，浏览器也正朝着平台化的方向发展，不再只是一个单纯的浏览器。在其上可以构建出许许多多的基于网页的应用，被称为WebApp。通过Chrome的应用商店就可以窥见一斑(国内的360和猎豹因为使用的正是相同的内核，也就可以很容易共享这些应用)。
&& & &Netscape为当时的Netscape Navigator定义了一套插件接口 (NAPI) ，现在由Mozilla维护，并被多个主流浏览器所采用。
&&&&&NAPI实现了在网页中插件一些特别的元素，并可以和其它DOM元素一样通过JavaScript Binding由用户脚本控制。比如常见的Adobe Flash播放插件，和PDF阅读插件。甚至可以和系统应用程序交互。
&&&&&每个插件由一个特定的MIME Type来指定，由浏览器内核在解析时根据需要加载对应的插件。WebKit实现的模块图如下:
& & 对于插件开发者而言，只要遵循NAPI的规范，就可以实现跨浏览器的支持。Plugin Process同时将插件的独立于内核之外。在需要时调用插件的服务就可以了。
& & 插件在模块化上的作用非常明显，宿主在需要动态调用或组合各个插件就可以实现强大的功能，而且保证他们各自的核心功能不受影响。比如著名的GIMP，它的图像处理函数几乎都是以插件的形式存在的。还有多媒体播放器，解码器也是以插件的形式组织的。插件机制的核心就是接口的定义，而协作决定接口。只有构造出简洁有效的协作方式，才能保证插件的优势。
& & & 以下是NAPI相关的参考:
&&&&&&&&&&&1.&
&&&&&&&&&&&2.&
兼容并蓄 - WebKit的跨平台方案
& & & 跨平台是许多大型软件要解决的问题，其前提条件也是提炼出核心业务逻辑，保持它的一致性。而跨平台真正要变的是各种接口，对于浏览器来说主要是网络接口、图形接口、多媒体解等。
&&&&&WebKit的解决方案主要使用适配器模式。主要思想还是提取公共的业务逻辑封装在一个接口中，再由各个平台视需要实现不同的部分。
&&&&&以Image类为例，它的一个函数与平台相关，于是类的实现被放在了三个文件中Image.cpp, ImageMac.mm和ImageWin.cpp中。Image.cpp中实现了公共的部分，而ImageMac.mm中实现了Mac OS版本，而ImageWin.cpp则实现了Windows版本。如下图所示:
& & & & *WebKit将所有与平台相关的代码，放在platform目录，结构清楚。
&&&&&还有另一种实现方式，如多媒体元素的播放控件。首先是MediaPlayer提供了一部分公共的逻辑，对于与平台相关实现的部分，定义了一个MediaPlayerPrivateInterface，各平台继承自这个接口实现各自的逻辑。
重构 - 不断追求卓越
&&&&&好的设计很难一步到位，一定需要不断的演化。WebKit的演化也体现在它的代码上。无论&&程序员修炼之道&&作者推荐的&Don't repeat yourself&和Unix中SPOT原则，都是在强调不要有重复的逻辑实现。
&&&& 比如前面提到的Plugin Process，最初是放在Web Process中实现的，后来来演化到和UI Process、Web Process使用共同的独立进程的做法。这个过程可能很多的决策，考虑不同的需求、复杂度控制等等同题。
WebKit的开发者也会面临这样的问题，比如下面这段注释就清楚表明了作者将残余的重复列为一个优化项:
& & // FIXME: There is much code here that is duplicated in WebProcessMainMac.mm,&
& & // we should add a shared base class where&we can put everything.
&&&&& 而且提到应当使用一个新的共享基类来完成这个工作，这也是模块化工作的一部分：分工，以降低复杂度。
&& & 最后再以&&Unix编程艺术&&中提炼出的KISS原则来做个总结。模块化设计利用模块化在上层得出一个简洁清晰的逻辑关系，使得在每个层级的复杂度都是可控的，将不必要的复杂性隐藏起来。Keep It Simple, Stupid！
转载请注明出处:http://blog.csdn.net/horkychen
参考: 温煜 &&软件架构设计&&
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：600882次
积分：8457
积分：8457
排名：第736名
原创：178篇
转载：29篇
译文：40篇
评论：278条
新浪微博:Horky
微信:horkychen
Mail:horky.
文章：51篇
阅读：89868
文章：35篇
阅读：156798
(5)(1)(4)(5)(1)(1)(4)(2)(6)(1)(2)(2)(4)(5)(4)(11)(11)(2)(5)(5)(4)(9)(2)(11)(7)(20)(34)(31)(9)(1)(6)(4)(1)(1)(2)(3)(8)(1)(1)(1)(1)(1)(3)(2)(1)(1)(1)(1)(2)(2)(1)word里这个查找怎么不对劲?_百度知道
word里这个查找怎么不对劲?
语法规则解决通常的语法,涵盖了二十多个专业领域, 查找内容填上语法规则,现代机器翻译系统一般采用模块化设计。
要我来做的话我肯定去编辑--查找 里做 、 语法规则库和翻译模块三部分组成？。这些工作需要一个完整的系统支撑,还应具有一些良好的翻译辅助功能模块. 将第二段中的“语法规则”的字体设置为四号隶书机器翻译系统的构成及实现机器翻译属于人工智能的范畴;生成子模块针对分析后赋予确切词义的词汇进行短语合并,双向总词汇量达400多万条、语义和词法现象, 改善翻译质量.我替换为也是填上语法规则 但格式设置时四号隶书却在查找内容下面出现了.这样就没办法替换了啊我该怎么做呢,它利用计算机模拟人脑进行不同语言的转换处理、领域划分。目前,那么这个系统是由什么构成, 如友好易用的窗口界面模块, 将文章以句子为单位切分,即解决共性的语法现象;通译&quot,结合系统已有的知识(词典及规则)将原文转为译文,同时还包含对词汇的维护。通常;分析子模块将句子中孤立的单词当作单独的句子成分; 英汉翻译软件,并输出结果。一个好的机译系统除了必须具备以上三个关键部分外,整个翻译过程的实现就是这些功能模块协同工作的结果1,即解决独特的语法现象,存储单词原形(带规则变化)及各种语义信息、译文修改调整模块和外围输入&#47。
翻译模块的功能是从外部获取原文数据。切分子模块完成单词。该模块又可根据作用的不同细分为三个子模块, &quot、句型匹配和统一生成、调整?为了保证系统的易实现性和可扩充性、更新.,通过查词典得到每个词的词法信息、分析子模块和生成子模块,主要分为语法规则和惯用法规则、修改?它是如何实现自动翻译过程的呢;惯用法规则解决与具体单词有关的语法。词典知识库是翻译系统静态知识的来源、 语义特征及与其它词的搭配等。语法规则库是翻译系统的核心、添加,包括词的词性,基于传统机器翻译理论构筑的机译系统主要由词典知识库:切分子模块、语义和词法现象,可使规则库不断扩充, 建立单词与译文间的转换关系.可是问题出来了、标点和句子的分离;输出设备支持模块等。系统实现时采用程序与数据分离的方式
看不懂我说的啥意思的
直接帮忙做下了
. 将全文中的“语法规则”的字体设置为四号隶书
提问者采纳
在①中一定要光标在“替换为”的框里://f.jpg" target="_blank" title="点击查看大图" class="ikqb_img_alink"><img class="ikqb_img" src="http.hiphotos.hiphotos看图应该能理解怎么做了://f，点“格式”再选“字体”及后续步骤./zhidao/wh%3D450%2C600/sign=68bebfcda39f8/fadab4077eef598bd4b31c8701e47a://f。<a href="http.jpg" esrc="http./zhidao/pic/item//zhidao/wh%3D600%2C800/sign=57dfd72aa040c/fadab4077eef598bd4b31c8701e47a。注意一点
提问者评价
谢谢``也同样谢楼下那位```
其他类似问题
按默认排序
其他3条回答
还要再点一次下面的“格式-字体”，在字体窗口中，分别放在“查找内容”和“替换为”后面可能就清楚得多了，图文并茂这个操作的时候是要注意操作顺序的，再执行全部替换，很容易把人弄晕。首先在“查找内容”里面输入“语法规则”后。这个替换对话框设计的不好。我觉得它如果提供两个“格式”按钮，要不我就不提了的，紧接着点下面的“格式-字体”。不好意思刚才我提交时没有看到你的贴子（可能是正在被系统审查图片所以还没显示出来呢），这次要在字体窗口里面设上四号隶书。 ______楼上as_smoke朋友回答得好。然后。设置字体格式的操作必须注意顺序，把各种属性都清空；然后再在“替换为”里面输入“语法规则”后
不懂你什么意思
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁}