整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

JavaScript 模块的构建以及对应的打包工具

果你是 JavaScript 的新手,一些像 “module bundlers vs module loaders”、“Webpack vs Browserify” 和 “AMD vs.CommonJS” 这样的术语,很快让你不堪重负。

JavaScript 模块系统可能令人生畏,但理解它对 Web 开发人员至关重要。

在这篇文章中,我将以简单的言语(以及一些代码示例)为你解释这些术语。 希望这对你有会有帮助!

什么是模块?

好作者能将他们的书分成章节,优秀的程序员将他们的程序划分为模块。

就像书中的章节一样,模块只是文字片段(或代码,视情况而定)的集群。然而,好的模块是高内聚低松耦的,具有不同的功能,允许在必要时对它们进行替换、删除或添加,而不会扰乱整体功能。

为什么使用模块?

使用模块有利于扩展、相互依赖的代码库,这有很多好处。在我看来,最重要的是:

1)可维护性: 根据定义,模块是高内聚的。一个设计良好的模块旨在尽可能减少对代码库部分的依赖,这样它就可以独立地增强和改进,当模块与其他代码片段解耦时,更新单个模块要容易得多。

回到我们的书的例子,如果你想要更新你书中的一个章节,如果对一个章节的小改动需要你调整每一个章节,那将是一场噩梦。相反,你希望以这样一种方式编写每一章,即可以在不影响其他章节的情况下进行改进。

2)命名空间: 在 JavaScript 中,顶级函数范围之外的变量是全局的(这意味着每个人都可以访问它们)。因此,“名称空间污染”很常见,完全不相关的代码共享全局变量。

在不相关的代码之间共享全局变量在开发中是一个大禁忌。正如我们将在本文后面看到的,通过为变量创建私有空间,模块允许我们避免名称空间污染。

3)可重用性:坦白地说:我们将前写过的代码复制到新项目中。 例如,假设你从之前项目编写的一些实用程序方法复制到当前项目中。

这一切都很好,但如果你找到一个更好的方法来编写代码的某些部分,那么你必须记得回去在曾经使用过的其他项目更新它。

这显然是在浪费时间。如果有一个我们可以一遍又一遍地重复使用的模块,不是更容易吗?

如何创建模块?

有多种方法来创建模块,来看几个:

模块模式

模块模式用于模拟类的概念(因为 JavaScript 本身不支持类),因此我们可以在单个对象中存储公共和私有方法和变量——类似于在 Java 或 Python 等其他编程语言中使用类的方式。这允许我们为想要公开的方法创建一个面向公共的 API,同时仍然将私有变量和方法封装在闭包范围中。

有几种方法可以实现模块模式。在第一个示例中,将使用匿名闭包,将所有代码放在匿名函数中来帮助我们实现目标。(记住:在 JavaScript 中,函数是创建新作用域的唯一方法。)

例一:匿名闭包

(function () {
  // 将这些变量放在闭包范围内实现私有化
  
  var myGrades = [93, 95, 88, 0, 55, 91];
  
  var average = function() {
    var total = myGrades.reduce(function(accumulator, item) {
      return accumulator + item}, 0);
    
      return '平均分 ' + total / myGrades.length + '.';
  }

  var failing = function(){
    var failingGrades = myGrades.filter(function(item) {
      return item < 70;});
      
    return '挂机科了 ' + failingGrades.length + ' 次。';
  }

  console.log(failing()); // 挂机科了次

}());


使用这个结构,匿名函数就有了自己的执行环境或“闭包”,然后我们立即执行。这让我们可以从父(全局)命名空间隐藏变量。

这种方法的优点是,你可以在这个函数中使用局部变量,而不会意外地覆盖现有的全局变量,但仍然可以访问全局变量,就像这样:

    var global = '你好,我是一个全局变量。)';
    
   (function () {
      // 将这些变量放在闭包范围内实现私有化
      
      var myGrades = [93, 95, 88, 0, 55, 91];
      
      var average = function() {
        var total = myGrades.reduce(function(accumulator, item) {
          return accumulator + item}, 0);
        
          return '平均分 ' + total / myGrades.length + '.';
      }
    
      var failing = function(){
        var failingGrades = myGrades.filter(function(item) {
          return item < 70;});
          
        return '挂机科了 ' + failingGrades.length + ' 次。';
      }
    
      console.log(failing()); // 挂机科了次
      onsole.log(global); // 你好,我是一个全局变量。
    
    }());

注意,匿名函数的圆括号是必需的,因为以关键字 function 开头的语句通常被认为是函数声明(请记住,JavaScript 中不能使用未命名的函数声明)。因此,周围的括号将创建一个函数表达式,并立即执行这个函数,这还有另一种叫法 立即执行函数(IIFE)。如果你对这感兴趣,可以在这里了解到更多。

例二:全局导入

jQuery 等库使用的另一种流行方法是全局导入。它类似于我们刚才看到的匿名闭包,只是现在我们作为参数传入全局变量:

(function (globalVariable) {

  // 在这个闭包范围内保持变量的私有化
  var privateFunction = function() {
    console.log('Shhhh, this is private!');
  }

  // 通过 globalVariable 接口公开下面的方法
 // 同时将方法的实现隐藏在 function() 块中

  globalVariable.each = function(collection, iterator) {
    if (Array.isArray(collection)) {
      for (var i = 0; i < collection.length; i++) {
        iterator(collection[i], i, collection);
      }
    } else {
      for (var key in collection) {
        iterator(collection[key], key, collection);
      }
    }
  };

  globalVariable.filter = function(collection, test) {
    var filtered = [];
    globalVariable.each(collection, function(item) {
      if (test(item)) {
        filtered.push(item);
      }
    });
    return filtered;
  };

  globalVariable.map = function(collection, iterator) {
    var mapped = [];
    globalUtils.each(collection, function(value, key, collection) {
      mapped.push(iterator(value));
    });
    return mapped;
  };

  globalVariable.reduce = function(collection, iterator, accumulator) {
    var startingValueMissing = accumulator === undefined;

    globalVariable.each(collection, function(item) {
      if(startingValueMissing) {
        accumulator = item;
        startingValueMissing = false;
      } else {
        accumulator = iterator(accumulator, item);
      }
    });

    return accumulator;

  };

 }(globalVariable));

在这个例子中,globalVariable 是唯一的全局变量。与匿名闭包相比,这种方法的好处是可以预先声明全局变量,使得别人更容易阅读代码。

例三:对象接口

另一种方法是使用立即执行函数接口对象创建模块,如下所示:

var myGradesCalculate = (function () {
    
  // 将这些变量放在闭包范围内实现私有化
  var myGrades = [93, 95, 88, 0, 55, 91];

  // 通过接口公开这些函数,同时将模块的实现隐藏在function()块中

  return {
    average: function() {
      var total = myGrades.reduce(function(accumulator, item) {
        return accumulator + item;
        }, 0);
        
      return'平均分 ' + total / myGrades.length + '.';
    },

    failing: function() {
      var failingGrades = myGrades.filter(function(item) {
          return item < 70;
        });

      return '挂科了' + failingGrades.length + ' 次.';
    }
  }
})();

myGradesCalculate.failing(); // '挂科了 2 次.' 
myGradesCalculate.average(); // '平均分 70.33333333333333.'

正如您所看到的,这种方法允许我们通过将它们放在 return 语句中(例如算平均分和挂科数方法)来决定我们想要保留的变量/方法(例如 myGrades)以及我们想要公开的变量/方法。

例四:显式模块模式

这与上面的方法非常相似,只是它确保所有方法和变量在显式公开之前都是私有的:

var myGradesCalculate = (function () {
    
  // 将这些变量放在闭包范围内实现私有化
  var myGrades = [93, 95, 88, 0, 55, 91];
  
  var average = function() {
    var total = myGrades.reduce(function(accumulator, item) {
      return accumulator + item;
      }, 0);
      
    return'平均分 ' + total / myGrades.length + '.';
  };

  var failing = function() {
    var failingGrades = myGrades.filter(function(item) {
        return item < 70;
      });

    return '挂科了' + failingGrades.length + ' 次.';
  };

  // Explicitly reveal public pointers to the private functions 
  // that we want to reveal publicly

  return {
    average: average,
    failing: failing
  }
})();

myGradesCalculate.failing(); // '挂科了 2 次.' 
myGradesCalculate.average(); // '平均分 70.33333333333333.'

这可能看起来很多,但它只是模块模式的冰山一角。 以下是我在自己的探索中发现有用的一些资源:

  • Learning JavaScript Design Patterns:作者是 Addy Osmani,一本简洁又令人印象深刻的书籍,蕴藏着许多宝藏。
  • Adequately Good by Ben Cherry:包含模块模式的高级用法示例。
  • Blog of Carl Danley:模块模式概览,也是 JavaScript 许多设计模式的资源库。

CommonJS 和 AMD

所有这些方法都有一个共同点:使用单个全局变量将其代码包装在函数中,从而使用闭包作用域为自己创建一个私有名称空间。

虽然每种方法都有效且都有各自特点,但却都有缺点。

首先,作为开发人员,你需要知道加载文件的正确依赖顺序。例如,假设你在项目中使用 Backbone,因此你可以将 Backbone 的源代码 以<script> 脚本标签的形式引入到文件中。

但是,由于 Backbone 对 Underscore.js 有很强的依赖性,因此 Backbone 文件的脚本标记不能放在Underscore.js 文件之前。

作为一名开发人员,管理依赖关系并正确处理这些事情有时会令人头痛。

另一个缺点是它们仍然会导致名称空间冲突。例如,如果两个模块具有相同的名称怎么办?或者,如果有一个模块的两个版本,并且两者都需要,该怎么办?

幸运的是,答案是肯定的。

有两种流行且实用的方法:CommonJSAMD

CommonJS

CommonJS 是一个志愿者工作组,负责设计和实现用于声明模块的 JavaScript API。

CommonJS 模块本质上是一个可重用的 JavaScript,它导出特定的对象,使其可供其程序中需要的其他模块使用。 如果你已经使用 Node.js 编程,那么你应该非常熟悉这种格式。

使用 CommonJS,每个 JavaScript 文件都将模块存储在自己独立的模块上下文中(就像将其封装在闭包中一样)。 在此范围内,我们使用 module.exports 导出模块,或使用 require 来导入模块。

在定义 CommonJS 模块时,它可能是这样的:

function myModule() {
  this.hello = function() {
    return 'hello!';
  }
   
  this.goodbye = function() {
    return 'goodbye!';
  }
}

module.exports = myModule;

我们使用特殊的对象模块,并将函数的引用放入 module.exports 中。这让 CommonJS 模块系统知道我们想要公开什么,以便其他文件可以使用它。

如果想使用 myModule,只需要使用 require 方法就可以,如下:

var myModule = require('myModule');

var myModuleInstance = new myModule();
myModuleInstance.hello(); // 'hello!'
myModuleInstance.goodbye(); // 'goodbye!'

与前面讨论的模块模式相比,这种方法有两个明显的好处:

  1. 避免全局命名空间污染
  2. 依赖关系更加明确

另外需要注意的是,CommonJS 采用服务器优先方法并同步加载模块。 这很重要,因为如果我们需要三个其他模块,它将逐个加载它们。

现在,它在服务器上运行良好,但遗憾的是,在为浏览器编写 JavaScript 时使用起来更加困难。 可以这么说,从网上读取模块比从磁盘读取需要更长的时间。 只要加载模块的脚本正在运行,它就会阻止浏览器运行其他任何内容,直到完成加载,这是因为 JavaScript 是单线程且 CommonJS 是同步加载的。

AMD

CommonJS一切都很好,但是如果我们想要异步加载模块呢? 答案是 异步模块定义,简称 AMD

使用 AMD 的加载模块如下:

define(['myModule', 'myOtherModule'], function(myModule, myOtherModule) {
  console.log(myModule.hello());
});

define 函数的第一个参数是一个数组,数组中是依赖的各种模块。这些依赖模块在后台(以非阻塞的方式)加载进来,一旦加载完毕,define 函数就会调用第二个参数,即回调函数执行操作。

接下来,回调函数接收参数,即依赖模块 - 示例中就是 myModulemyOtherModule - 允许函数使用这些依赖项, 最后,所依赖的模块本身也必须使用 define 关键字来定义。例如,myModule如下所示:

define([], function() {

  return {
    hello: function() {
      console.log('hello');
    },
    goodbye: function() {
      console.log('goodbye');
    }
  };
});

因此,与 CommonJS 不同,AMD 采用浏览器优先的方法和异步行为来完成工作。 (注意,有很多人坚信在开始运行代码时动态加载文件是不利的,我们将在下一节关于模块构建的内容中探讨更多内容)。

除了异步性,AMD 的另一个好处是模块可以是对象,函数,构造函数,字符串,JSON 和许多其他类型,而CommonJS 只支持对象作为模块。

也就是说,和CommonJS相比,AMD不兼容io、文件系统或者其他服务器端的功能特性,而且函数包装语法与简单的require 语句相比有点冗长。

UMD

对于同时支持 AMD 和 CommonJS 特性的项目,还有另一种格式:通用模块定义(Universal Module Definition, UMD)。

UMD 本质上创造了一种使用两者之一的方法,同时也支持全局变量定义。因此,UMD 模块能够同时在客户端和服务端同时工作。

简单看一下 UMD 是怎样工作的:

(function (root, factory) {
  if (typeof define === 'function' && define.amd) {
      // AMD
    define(['myModule', 'myOtherModule'], factory);
  } else if (typeof exports === 'object') {
      // CommonJS
    module.exports = factory(require('myModule'), require('myOtherModule'));
  } else {
    // Browser globals (Note: root is window)
    root.returnExports = factory(root.myModule, root.myOtherModule);
  }
}(this, function (myModule, myOtherModule) {
  // Methods
  function notHelloOrGoodbye(){}; // A private method
  function hello(){}; // A public method because it's returned (see below)
  function goodbye(){}; // A public method because it's returned (see below)

  // Exposed public methods
  return {
      hello: hello,
      goodbye: goodbye
  }
}));

Github 上 enlightening repo 里有更多关于 UMD 的例子。

Native JS

你可能已经注意到,上面的模块都不是 JavaScript 原生的。相反,我们已经创建了通过使用模块模式、CommonJS 或 AMD 来模拟模块系统的方法。

幸运的是,TC39(定义 ECMAScript 的语法和语义的标准组织)一帮聪明的人已经引入了ECMAScript 6(ES6)的内置模块。

ES6 为导入导出模块提供了很多不同的可能性,已经有许多其他人花时间解释这些,下面是一些有用的资源:

  • jsmodules.io
  • exploringjs.com

与 CommonJS 或 AMD 相比,ES6 模块最大的优点在于它能够同时提供两方面的优势:简明的声明式语法和异步加载,以及对循环依赖项的更好支持。

也许我个人最喜欢的 ES6 模块功能是它的导入模块是导出时模块的实时只读视图。(相比起 CommonJS,导入的是导出模块的拷贝副本,因此也不是实时的)。

下面是一个例子:

// lib/counter.js

var counter = 1;

function increment() {
  counter++;
}

function decrement() {
  counter--;
}

module.exports = {
  counter: counter,
  increment: increment,
  decrement: decrement
};


// src/main.js

var counter = require('../../lib/counter');

counter.increment();
console.log(counter.counter); // 1

在这个例子中,我们基本上创建了两个模块的对象:一个用于导出它,一个在我们需要的时候引入。

此外,在 main.js 中的对象目前是与原始模块是相互独立的,这就是为什么即使我们执行 increment 方法,它仍然返回 1,因为引入的变量和最初导入的变量是毫无关联的。需要改变你引入的对象唯一的方式是手动执行增加:

counter.counter++;
console.log(counter.counter); // 2

另一方面,ES6创建了我们导入的模块的实时只读视图:

// lib/counter.js
export let counter = 1;

export function increment() {
  counter++;
}

export function decrement() {
  counter--;
}


// src/main.js
import * as counter from '../../counter';

console.log(counter.counter); // 1
counter.increment();

console.log(counter.counter); // 2

超酷?我发现这一点是因为ES6允许你可以把你定义的模块拆分成更小的模块而不用删减功能,然后你还能反过来把它们合成到一起, 完全没问题。

什么是模块打包?

总体上看,模块打包只是将一组模块(及其依赖项)以正确的顺序拼接到一个文件(或一组文件)中的过程。正如 Web开发的其它方方面面,棘手的问题总是潜藏在具体的细节里。

为什么需要打包?

将程序划分为模块时,通常会将这些模块组织到不同的文件和文件夹中。 有可能,你还有一组用于正在使用的库的模块,如 Underscore 或 React。

因此,每个文件都必须以一个 <script> 标签引入到主 HTML 文件中,然后当用户访问你的主页时由浏览器加载进来。 每个文件使用 <script> 标签引入,意味着浏览器不得不分别逐个的加载它们。

这对于页面加载时间来说简直是噩梦。

为了解决这个问题,我们将所有文件打包或“拼接”到一个大文件(或视情况而定的几个文件),以减少请求的数量。 当你听到开发人员谈论“构建步骤”或“构建过程”时,这就是他们所谈论的内容。

另一种加速构建操作的常用方法是“缩减”打包代码。 缩减是从源代码中移除不必要的字符(例如,空格,注释,换行符等)的过程,以便在不改变代码功能的情况下减少内容的整体大小。

较少的数据意味着浏览器处理时间会更快,从而减少了下载文件所需的时间。 如果你见过具有 “min” 扩展名的文件,如 “underscore-min.js” ,可能会注意到与完整版相比,缩小版本非常小(不过很难阅读)。

除了捆绑和/或加载模块之外,模块捆绑器还提供了许多其他功能,例如在进行更改时生成自动重新编译代码或生成用于调试的源映射。

构建工具(如 Gulp 和 Grunt)能为开发者直接进行拼接和缩减,确保为开发人员提供可读代码,同时有利于浏览器执行的代码。

打包模块有哪些不同的方法?

当你使用一种标准模块模式(上部分讨论过)来定义模块时,拼接和缩减文件非常有用。 你真正在做的就是将一堆普通的 JavaScript 代码捆绑在一起。

但是,如果你坚持使用浏览器无法解析的非原生模块系统(如 CommonJS 或 AMD(甚至是原生 ES6模块格式)),则需要使用专门工具将模块转换为排列正确、浏览器可解析的代码。 这就是 Browserify,RequireJS,Webpack 和其他“模块打包工具”或“模块加载工具”的用武之地。

除了打包和/或加载模块之外,模块打包器还提供了许多其他功能,例如在进行更改时生成自动重新编译代码或生成用于调试的源映射。

下面是一些常见的模块打包方法:

打包 CommonJS

正如前面所知道的,CommonJS以同步方式加载模块,这没有什么问题,只是它对浏览器不实用。我提到过有一个解决方案——其中一个是一个名为 Browserify 的模块打包工具。Browserify 是一个为浏览器编译 CommonJS模块的工具。

例如,有个 main.js 文件,它导入一个模块来计算一组数字的平均值:

var myDependency = require(‘myDependency’);

var myGrades = [93, 95, 88, 0, 91];

var myAverageGrade = myDependency.average(myGrades);

在这种情况下,我们有一个依赖项(myDependency),使用下面的命令,Browserify 以 main.js 为入口把所有依赖的模块递归打包成一个文件:

browserify main.js -o bundle.js

Browserify 通过跳入文件分析每一个依赖的 抽象语法树(AST),以便遍历项目的整个依赖关系图。一旦确定了依赖项的结构,就把它们按正确的顺序打包到一个文件中。然后,在 html 里插入一个用于引入 “bundle.js” 的 <script> 标签,从而确保你的源代码在一个 HTTP 请求中完成下载。

类似地,如果有多个文件且有多个依赖时,只需告诉 Browserify 的入口文件路径即可。最后打包后的文件可以通过 Minify-JS 之类的工具压缩打包后的代码。

打包 AMD

如果你正在使用 AMD,你需要使用像 RequireJS 或者 Curl 这样的 AMD 加载器。模块加载器(与模块打包工具不同)会动态加载程序需要运行的模块。

提醒一下,AMD 与 CommonJS 的主要区别之一是它以异步方式加载模块。 从这个意义上说,对于 AMD,从技术上讲,实际上并不需要构建步骤,因为异步加载模块意味着在运行过程中逐步下载那些程序所需要的文件,而不是用户刚进入页面就一下把所有文件都下载下来。

但实际上,对于每个用户操作而言,随着时间的推移,大容量请求的开销在生产中没有多大意义。 大多数 Web 开发人员仍然使用构建工具打包和压缩 AMD 模块以获得最佳性能,例如使用 RequireJS 优化器,r.js 等工具。

总的来说,AMD 和 CommonJS 在打包方面的区别在于:在开发期间,AMD 可以省去任何构建过程。当然,在代码上线前,要使用优化工具(如 r.js)进行优化。

Webpack

就打包工具而言,Webpack 是一个新事物。它被设计成与你使用的模块系统无关,允许开发人员在适当的情况下使用 CommonJS、AMD 或 ES6。

你可能想知道,为什么我们需要 Webpack,而我们已经有了其他打包工具了,比如 Browserify 和 RequireJS,它们可以完成工作,并且做得非常好。首先,Webpack 提供了一些有用的特性,比如 “代码分割”(code splitting) —— 一种将代码库分割为“块(chunks)”的方式,从而能实现按需加载。

例如,如果你的 Web 应用程序,其中只需要某些代码,那么将整个代码库都打包进一个大文件就不是很高效。 在这种情况下,可以使用代码分割,将需要的部分代码抽离在"打包块",在执行按需加载,从而避免在最开始就遇到大量负载的麻烦。

代码分割只是 Webpack 提供的众多引人注目的特性之一,网上有很多关于 “Webpack 与 Browserify 谁更好” 的激烈讨论。以下是一些客观冷静的讨论,帮助我稍微理清了头绪:

  • https://gist.github.com/subst...点击预览
  • http://mattdesl.svbtle.com/br...
  • http://blog.namangoel.com/bro...

ES6 模块

当前 JS 模块规范(CommonJS, AMD) 与 ES6 模块之间最重要的区别是 ES6 模块的设计考虑到了静态分析。这意味着当你导入模块时,导入的模块在编译阶段也就是代码开始运行之前就被解析了。这允许我们在运行程序之前移,移除那些在导出模块中不被其它模块使用的部分。移除不被使用的模块能节省空间,且有效地减少浏览器的压力。

一个常见的问题,使用一些工具,如 Uglify.js ,缩减代码时,有一个死码删除的处理,它和 ES6 移除没用的模块又有什么不同呢?只能说 “视情况而定”。

死码消除(Dead codeelimination)是一种编译器原理中编译最优化技术,它的用途是移除对程序运行结果没有任何影响的代码。移除这类的代码有两种优点,不但可以减少程序的大小,还可以避免程序在运行中进行不相关的运算行为,减少它运行的时间。不会被运行到的代码(unreachable code)以及只会影响到无关程序运行结果的变量(Dead Variables),都是死码(Dead code)的范畴。

有时,在 UglifyJS 和 ES6 模块之间死码消除的工作方式完全相同,有时则不然。如果你想验证一下, Rollup’s wiki 里有个很好的示例。

ES6 模块的不同之处在于死码消除的不同方法,称为“tree shaking”。“tree shaking” 本质上是死码消除反过程。它只包含包需要运行的代码,而非排除不需要的代码。来看个例子:

假设有一个带有多个函数的 utils.js 文件,每个函数都用 ES6 的语法导出:

export function each(collection, iterator) {
  if (Array.isArray(collection)) {
    for (var i = 0; i < collection.length; i++) {
      iterator(collection[i], i, collection);
    }
  } else {
    for (var key in collection) {
      iterator(collection[key], key, collection);
    }
  }
 }

export function filter(collection, test) {
  var filtered = [];
  each(collection, function(item) {
    if (test(item)) {
      filtered.push(item);
    }
  });
  return filtered;
}

export function map(collection, iterator) {
  var mapped = [];
  each(collection, function(value, key, collection) {
    mapped.push(iterator(value));
  });
  return mapped;
}

export function reduce(collection, iterator, accumulator) {
    var startingValueMissing = accumulator === undefined;

    each(collection, function(item) {
      if(startingValueMissing) {
        accumulator = item;
        startingValueMissing = false;
      } else {
        accumulator = iterator(accumulator, item);
      }
    });

    return accumulator;
}

接着,假设我们不知道要在程序中使用什么 utils.js 中的哪个函数,所以我们将上述的所有模块导入main.js中,如下所示:

import * as Utils from ‘./utils.js’;

最终,我们只用到的 each 方法:

import * as Utils from ‘./utils.js’;

Utils.each([1, 2, 3], function(x) { console.log(x) });

“tree shaken” 版本的 main.js 看起来如下(一旦模块被加载后):

function each(collection, iterator) {
  if (Array.isArray(collection)) {
    for (var i = 0; i < collection.length; i++) {
      iterator(collection[i], i, collection);
    }
  } else {
    for (var key in collection) {
      iterator(collection[key], key, collection);
    }
  }
 };

each([1, 2, 3], function(x) { console.log(x) });

注意:只导出我们使用的 each 函数。

同时,如果决定使用 filte r函数而不是每个函数,最终会看到如下的结果:

import * as Utils from ‘./utils.js’;

Utils.filter([1, 2, 3], function(x) { return x === 2 });

tree shaken 版本如下:

function each(collection, iterator) {
  if (Array.isArray(collection)) {
    for (var i = 0; i < collection.length; i++) {
      iterator(collection[i], i, collection);
    }
  } else {
    for (var key in collection) {
      iterator(collection[key], key, collection);
    }
  }
 };

function filter(collection, test) {
  var filtered = [];
  each(collection, function(item) {
    if (test(item)) {
      filtered.push(item);
    }
  });
  return filtered;
};

filter([1, 2, 3], function(x) { return x === 2 });

此时,each 和 filter 函数都被包含进来。这是因为 filter 在定义时使用了 each。因此也需要导出该函数模块以保证程序正常运行。

构建 ES6 模块

我们知道 ES6 模块的加载方式与其他模块格式不同,但我们仍然没有讨论使用 ES6 模块时的构建步骤。

遗憾的是,因为浏览器对 ES6模 块的原生支持还不够完善,所以现阶段还需要我们做一些补充工作。

下面是几个在浏览器中 构建/转换 ES6 模块的方法,其中第一个是目前最常用的方法:

  1. 使用转换器(例如 Babel 或 Traceur)以 CommonJS、AMD 或 UMD 格式将 ES6 代码转换为 ES5 代码,然后再通过 Browserify 或 Webpack 一类的构建工具来进行构建。
  2. 使用 Rollup.js,这其实和上面差不多,只是 Rollup 捎带 ES6 模块的功能,在打包之前静态分析ES6 代码和依赖项。 它利用 “tree shaking” 技术来优化你的代码。 总言,当您使用ES6模块时,Rollup.js 相对于 Browserify 或 Webpack 的主要好处是 tree shaking 能让打包文件更小。 需要注意的是,Rollup提 供了几种格式来的打包代码,包括 ES6,CommonJS,AMD,UMD 或 IIFE。 IIFE 和 UMD 捆绑包可以直接在浏览器中工作,但如果你选择打包 AMD,CommonJS 或 ES6,需需要寻找能将代码转成浏览器能理解运行的代码的方法(例如,使用 Browserify, Webpack,RequireJS等)。

小心踩坑

作为 web 开发人员,我们必须经历很多困难。转换语法优雅的ES6代码以便在浏览器里运行并不总是容易的。

问题是,什么时候 ES6 模块可以在浏览器中运行而不需要这些开销?

答案是:“尽快”。

ECMAScript 目前有一个解决方案的规范,称为 ECMAScript 6 module loader API。简而言之,这是一个纲领性的、基于 Promise 的 API,它支持动态加载模块并缓存它们,以便后续导入不会重新加载模块的新版本。

它看起来如下:

// myModule.js

export class myModule {
  constructor() {
    console.log('Hello, I am a module');
  }

  hello() {
    console.log('hello!');
  }

  goodbye() {
    console.log('goodbye!');
  }
}


 // main.js
System.import(‘myModule’).then(function(myModule) {
  new myModule.hello();
});

// ‘hello!’

你亦可直接对 script 标签指定 “type=module” 来定义模块,如:

<script type="module">
  // loads the 'myModule' export from 'mymodule.js'
  import { hello } from 'mymodule';

  new Hello(); // 'Hello, I am a module!'
</script>

更加详细的介绍也可以在 Github 上查看:es-module-loader

此外,如果您想测试这种方法,请查看 SystemJS,它建立在 ES6 Module Loader polyfill 之上。 SystemJS 在浏览器和 Node 中动态加载任何模块格式(ES6模块,AMD,CommonJS 或 全局脚本)。

它跟踪“模块注册表”中所有已加载的模块,以避免重新加载先前已加载过的模块。 更不用说它还会自动转换ES6模块(如果只是设置一个选项)并且能够从任何其他类型加载任何模块类型!

有了原生的 ES6 模块后,还需要模块打包吗?

对于日益普及的 ES6 模块,下面有一些有趣的观点:

HTTP/2 会让模块打包过时吗?

对于 HTTP/1,每个TCP连接只允许一个请求。这就是为什么加载多个资源需要多个请求。有了 HTTP/2,一切都变了。HTTP/2 是完全多路复用的,这意味着多个请求和响应可以并行发生。因此,我们可以在一个连接上同时处理多个请求。

由于每个 HTTP 请求的成本明显低于HTTP/1,因此从长远来看,加载一组模块不会造成很大的性能问题。一些人认为这意味着模块打包不再是必要的,这当然有可能,但这要具体情况具体分析了。

例如,模块打包还有 HTTP/2 没有好处,比如移除冗余的导出模块以节省空间。 如果你正在构建一个性能至关重要的网站,那么从长远来看,打包可能会为你带来增量优势。 也就是说,如果你的性能需求不是那么极端,那么通过完全跳过构建步骤,可以以最小的成本节省时间。

总的来说,绝大多数网站都用上 HTTP/2 的那个时候离我们现在还很远。我预测构建过程将会保留,至少在近期内。

CommonJS、AMD 与 UMD 会被淘汰吗?

一旦 ES6 成为模块标准,我们还需要其他非原生模块规范吗?

我觉得还有。

Web 开发遵守一个标准方法进行导入和导出模块,而不需要中间构建步骤——网页开发长期受益于此。但 ES6 成为模块规范需要多长时间呢?

机会是有,但得等一段时间 。

再者,众口难调,所以“一个标准的方法”可能永远不会成为现实。

总结

希望这篇文章能帮你理清一些开发者口中的模块和模块打包的相关概念,共进步。




目前,教学、教研各种内容线上沉淀、展示丰富多彩,但线上内容“线下化”能力不足或过分依赖人力,比如,线上练习题组卷后以PDF形式分发给学生,家长希望将考试、练习题目打印后,学生带到学校去做(高中生使用手机等电子设备的时间有限),线上各类分析报告以PDF形式分享给学生/家长等。


从业务方面看,不同业务线的多个业务场景都有输出PDF的诉求,如果各业务线自己设计、实现符合自身业务场景的具体方案,除调研、开发工作量较大之外,还会有重复调研,踩坑的情况。


从技术角度看,线上内容转PDF的内容源头来自于H5富文本内容,业界内以此为基础的PDF生成方案多种多样,也各有优劣,比如:


方案对比-表格-1


因此,我们综合了各种PDF生成方案并总结了在探索讲义生成PDF过程中的经验,抽象出了一套通用的,可复用的能力供各业务线快速利用,基本方案和优劣如下:


最终方案-表格-2


目 标




旨在提供一套以H5为载体的PDF通用生成方案,这套方案有如下特点:

  1. 通用性强:能够处理各类H5页面,从分页到生成,做到一套方案,多般兼容。
  2. 扩展性、配置性强:各场景可根据自己的需要自定义页眉、页脚、页码,水印,背景等配置,做到输出形式丰富多彩。
  3. 方便易接入:各业务场景只需关注要展现的内容,无需关注分页,PDF生成等背后的处理 ,为需要产出PDF的业务场景提效赋能;整体来看,调研、设计、开发(+踩坑)一整套 H5 转 PDF的能力至少需要近 30人/日,我们希望这套通用能力的接入成本控制在 7人/日左右;在很多场景接入后,从实际反馈来看,平均只需要 2-3 人/日就接入了。
  4. 质量高:保证输出PDF中内容的展示与H5中无异,各种复杂公式的展示也丝毫无差错。
  5. 性能好:保证 1 分钟内能处理 100+ 的 20页左右的PDF生成任务
  6. 稳定性高:保证有各种兜底策略妥善处理各类异常,同时能够通过限流方案应对突发流量,保证服务稳定。


这套方案可分为两个核心部分,页面展示侧 - Medusa,PDF生成侧 - Hydra


页面展示侧 - Medusa




我们页面展示侧的通用能力——Medusa,是基于Paged.js的二次封装,并以NPM包形式提供给业务方使用。Medusa可对任何HTML进行分页、并根据配置添加页眉、页脚等,最终将处理后的HTML渲染到页面中。Medusa封装并简化了对PDF格式的配置,可覆盖绝大多数业务场景,使得各业务场景将更多精力投入其自身业务逻辑的开发。


之所以选择Pagedjs为基础开发我们自己的SDK,是因为它是目前我们能找到的唯一开源的、具有HTML内容分页,样式处理的前端库,同时我们也在讲义中经过了长期的摸索与沉淀。


接下来将详细介绍Paged.js原理、Medusa支持的功能与使用方法。


一 Paged.js是如何工作的




Paged.js包含了 3 个大模块

  • Chunker(负责HTML内容分页)
  • Polisher (负责CSS样式处理)
  • Previewer (负责预览呈现Chunker和Polisher处理后的内容)

这里将主要介绍 Previewer 和 Chunker,因为我们的二次开发和维护不涉及到Polisher。


Previewer

Previewer 的工作非常简单,但我们会主要利用它封装我们的Medusa,初始化一个Previewer对象,Previewer初始化了Chunker和Polisher对象:


Medusa-代码-1


再调用Previewer的preview()方法,preview()方法做了两件事:

  1. 通过Polisher处理样式内容
  2. 通过Chunker处理需要分页的HTML内容,如果没有指定需要分页的HTML,则会处理整个Body的内容

Medusa-代码-2


当chunker.flow结束,即可在浏览器看到整个页面处理完之后的样子。


Chunker


首先,Chunker解析、预处理需要分页的HTML,为其添加一些必要的属性


Medusa-代码-3


然后创建容纳所有页(pages)的容器,并挂载到renderTo容器下(默认Body),以备组织后续的所有页:



Medusa-代码-4


接着,chunker创建了一个page模版,以便增加页面使用:


Medusa-代码-5


其中,TEMPLATE是Pagedjs内部创建页面时所使用的基础模版。


Medusa-代码-6


接下来,chunker进入了渲染+分页过程(这个过程我们不会在二次开发中做修改,但需要了解其基本思路以便在出问题时能有解决思路),这个过程在循环一个迭代器(*layout),迭代器一直在做3件事:


  1. 将内容添加到模版内容区域的容器中 -> 渲染。
  2. 探测overflow,找到overflow的offset并创建BreakToken (探测overflow过程中很多处都用到了迭代器,此处为了说明思路,简化了相关代码)。


原则:

寻找overflow时会将尽可能多的内容节点插入内容区域,这里,“尽可能多”分为几种情况,比如:

  • 没有剩余节点需要再添加了
  • 达到了一页所能承载的最大字符数;刚开始的时候,如果没有指定每页的最大字符数,Pagedjs会给一个默认值为 1500 的每页最大字符用做判断,在之后会记录分隔好的每一页中的字符数,并取最近4页 (少于4页取全部)的平均值作为之后分页的判断条件,这里,Pagedjs相当于对每一页中能够承载的内容做了一个简单的预测,这个算法对于比较规律的内容做分页时还是比较简单高效的。

步骤:

Pagedjs遵循了如下步骤去寻找overflow:

两个前置条件:

  • 内容区域盒子边界已经确定,下面以contentArea.right 和 contentArea.bottom 分别代指其右边界和下边界。
  • 处理过程中每个节点的边界可以计算(对于文字节点,Pagedjs中使用了Range对象为其创建边界),下面以 node.left、 node.right、node.top 和 node.bottom 分别代指节点的左、右、上、下边界。

i. 从需要处理的内容第一个节点开始,判断是否 node.left >= contentArea.right || node.top >= contentArea.bottom


Medusa-代码-7


ii.如果不满足,则判断 node.right <= contentArea.right && node.bottom <= contentArea.bottom


Medusa-代码-8


iii.如果不满足,那说明有子节点overflow了,则继续深入其子节点查找即可。


3.使用模版添加新的页面,并从BreakToken处继续上述动作。


二 Medusa支持的功能及使用方法




基于Paged.js,Medusa支持了如下功能,并为业务方提供了更加简洁、定制化的配置。


  1. 动态页面分页能力
  2. 单页模版配置 -> 生成能力
  3. 前、后置静态页面生成、与分页后的动态页面拼接能力
  4. 页面处理成功后,通知PDF生成服务(Hydra)执行任务


下方是调用Medusa的代码示例:


Medusa-代码-9


1.1 动态页面分页能力

Medusa核心功能,可将连续的HTML页面转化成一页页PDF样式的HTML。


1.2 单页模版配置 -> 生成能力


通过Grid布局,Paged.js将一个单页模版分为多个区域,整体分为2个大的部分:

  1. base 页面基础配置:每个PDF纸型、水印,内容区域的宽高、margin与padding等等
  2. surround 页面周围区域:如页眉、页脚等配置


业务方通过简单的配置,即可还原UI设计稿中的PDF样式,例子如下图:



1.2.1 base

页面基础配置是对每页的。支持纸型或页面宽高、内容区域margin、padding、背景及水印的设置。



在封装Medusa时,Medusa将读取传入的页面模版配置、静态页内容配置,并将样式上的配置解析并转化为Previewer可理解的样式内容,比如页面宽高的设置:


Medusa-代码-10


将被转化为:


Medusa-代码-11


1.2.2 surround


  1. 可以看到图中的16种不同位置的surround区域。通过设置position,可将业务方自定义的元素渲染到对应的位置上。



2. 目前支持3种类型的surround item:

  • text 文字
  • img 图片
  • pageNum (动态获取)当前页码


example:


Medusa-代码-12


1.3 前/后置静态页面


业务方可通过如下方式配置静态页面的具体内容:


Medusa-代码-13


其中,传入的React JSX Element将会被这样处理:


Medusa-代码-14


处理完成后,将HTML String拼接到页面模版中,再插入分页后内容的前后。


PDF生成侧 - Hydra:




页面展示侧为PDF生成做好了页面的准备,对于PDF生成侧,需要做的工作就更纯粹了,业务方除了请求生成PDF,定期检查PDF生成的进度,无需做任何额外工作。


1.整体流程:

PDF生成是CPU和内存密集型的,由于页面内容的不确定性,也意味着页面渲染时间与生成PDF的时间都是不确定的,因此整体PDF生成的链路被设计成是异步的,如下图:



整体流程上,业务方在请求生成PDF时,会先在后端做一条记录,后端再将任务发送给Node服务,即Hydra;


在生成PDF时, 第 1 步是做页面上的准备,一个生成任务可能有多个URL页面需要生成PDF,所以我们预先启动对应URL数量的PPTR Page,页面都启动完成后,进入下一步;


第 2 步:渲染页面,这个过程中,如果请求是包含多个URL的,这些页面会同步渲染,在所有页面渲染完成后,进入下一步。


第 2.5 步,如果是需要生成连续页码的一整个PDF,还会做额外的一个动作:页码矫正,通过页码矫正,可以将同步渲染的每个页面,按照其之前页面的页码数修正,以保证整体PDF的页码的连贯。


第 3 步,通过PPTR Page的能力将页面转换为PDF buffer,如有必要,再将生成的PDF buffer拼接到一起生成一整个PDF,或者将每个PDF buffer都生成一个PDF,压缩成zip文件。


第 4 步,文件上传OSS,最终返回OSS CDN链接。


2.请求生成PDF:


业务侧请求将对应页面生成PDF的时,只需传入如下字段:


Hydra-代码-1


3.PDF生成过程:


正如在整体流程中所述,PDF生成侧,我们借助 PPTR 的能力打开页面并生成PDF流。


在页面调用 Medusa 分页、组装能力时,所有内容分页组装完成后会向body中插入了一个额外的DOM以标识该页面处理完成:


Hydra-代码-2


这是为了 Hydra 感知页面渲染完成所做的准备,当生成服务的 PPTR 等到该DOM出现时,则表示页面成功渲染并处理完成了:


Hydra-代码-3


此后,在上面已经提到过,对于需要将多个页面生成的PDF拼接成一个PDF的情况,在生成PDF之前需要做一个重要的动作,即页码矫正,原因如下:


  1. 每个页面无法感知其他页面情况的,如:第二个页面不知道第一个页面会生成多少页的PDF。
  2. 它们的页码需要是连续的。


并且我们不希望页面的处理是串行的,因为串行势必导致速度较慢,生成时间长。


这个问题的解决方案如下:

1. 对于每个页面都启用一个page,并同时处理

2. 每个页面处理完成后(pdfLastDOM出现),通过Page.$eval()来统计页数并记录:

Hydra-代码-4


3. 计算出页面中分页之后每一个页面的起始页码,以及所有页面的页码总和

4. 再修改页码容器样式的 counterReset 值即可,其后续页码可自递增。


Hydra-代码-5


5. 之后,再通过 Medusa 在页面window对象中Polyfill的相关配置,比如需要生成的PDF的单页宽、高以生成PDF流。


Hydra-代码-6


6. 最后如有必要,通过pdf-lib拼接这些 pdfBuffer 即可。


Hydra-代码-7


7. PDF生成完成后,上传OSS并返回URL链接


4.性能、稳定性保证:


在整体方案落地前,我们对服务进行了多次性能测试:


以下载题目为例,在4个容器,每个容器 3C 12G 的配置下的并行处理能力如下:


对于 20 道题目,每个PDF生成任务在 15 页左右,平均 1 分钟内能完成 280 个任务的处理。

对于 40 道题目,每个PDF生成任务在 30 页左右,平均 1 分钟内能完成 105 个任务的处理。

对于 60 到题目,每个PDF生成任务在 40 页左右,平均 1 分钟内能完成 54 个任务的处理。


同时,根据 Hydra 服务的整体的处理能力,后端通过任务队列的形式帮助我们保证服务不被瞬间的突刺流量击垮。


已接入/正在接入的相关业务线及场景:




目前,公司有 5 大业务线,8 个场景已经完全接入我们的能力用于 H5 转 PDF,如下是错题本、内容资料库接入后生成的PDF样例:


错题本:




内容资料库试卷:




未来展望




目前整体的PDF生成方案已经能够满足大多数场景和内容,但依然有可改进空间。


HTML的流式布局要求我们必须手动的对内容分页,才能添加页眉,页脚等(即Mdusa做的工作),正因为如此,在处理复杂的内容时,可能会出现一些问题:比如,遇到复杂表格时,由于表格可能会有多种多样的行、列合并,同时表格单元格内的内容也可以多种多样,在分页过程中,Medusa内部的PagedJS并不能完美的处理对于长、且复杂的表格的分割,因此可能遇到分割后表格单元格缺失、错乱或宽高错误的问题,这些问题在讲义中体现较明显。


我们仍在持续关注与研究复杂DOM内容的分割问题,会尝试加以优化和改进PagedJS的能力,同时,我们也以另外一种思路设计了自己的DOM分页器方案,但经过评估,由于实现比较复杂,成本较高,暂时没有投入开发资源。


不过,我们相信,未来我们一定能以更完美的方式分割DOM以生成更高质量的PDF。


作者:高源、陈欣博

来源:微信公众号:高途技术

出处:https://mp.weixin.qq.com/s/c_N7jdNklrNFKR_Cub2Tgg

般商业网站都有一个语言的需求,就是为了照顾使用正体中文的国人,会特地提供一个切换到正体中文的选项(或曰“繁体中文”)。传统做法是在服务端完成的,即通过某些控件或者过滤器转换文本语言。这里笔者介绍一种简单可行的方法,不是在服务端而是利用前端的 JavaScript 就可以切换正体中文。

由于页面假设设定均使用 Unicode 字符集,于是一般不用考虑 GB2312/BIG5 字符集问题,伟大的 Unicode 字符集已经涵盖了繁体字的字符了(UTF-8 编码)。

怎么在页面调用这个功能呢?很简单,首先引入下面 Js(注意还依赖 Function.prototype.delegate(), 下面会提及):

;(function(){
	var 简化中文 = '啊阿埃挨哎唉哀皑癌蔼矮艾碍爱隘鞍氨安俺按暗岸胺案肮昂盎凹敖熬翱袄傲奥懊澳芭捌扒叭吧笆八疤巴拔跋靶把耙坝霸罢爸白柏百摆佰败拜稗斑班搬扳般颁板版扮拌伴瓣半办绊邦帮梆榜膀绑棒磅蚌镑傍谤苞胞包褒剥薄雹保堡饱宝抱报暴豹鲍爆杯碑悲卑北辈背贝钡倍狈备惫焙被奔苯本笨崩绷甭泵蹦迸逼鼻比鄙笔彼碧蓖蔽毕毙毖币庇痹闭敝弊必辟壁臂避陛鞭边编贬扁便变卞辨辩辫遍标彪膘表鳖憋别瘪彬斌濒滨宾摈兵冰柄丙秉饼炳病并玻菠播拨钵波博勃搏铂箔伯帛舶脖膊渤泊驳捕卜哺补埠不布步簿部怖擦猜裁材才财睬踩采彩菜蔡餐参蚕残惭惨灿苍舱仓沧藏操糙槽曹草厕策侧册测层蹭插叉茬茶查碴搽察岔差诧拆柴豺搀掺蝉馋谗缠铲产阐颤昌猖场尝常长偿肠厂敞畅唱倡超抄钞朝嘲潮巢吵炒车扯撤掣彻澈郴臣辰尘晨忱沉陈趁衬撑称城橙成呈乘程惩澄诚承逞骋秤吃痴持匙池迟弛驰耻齿侈尺赤翅斥炽充冲冲虫崇宠抽酬畴踌稠愁筹仇绸瞅丑臭初出橱厨躇锄雏滁除楚础储矗搐触处揣川穿椽传船喘串疮窗幢床闯创吹炊捶锤垂春椿醇唇淳纯蠢戳绰疵茨磁雌辞慈瓷词此刺赐次聪葱囱匆从丛凑粗醋簇促蹿篡窜摧崔催脆瘁粹淬翠村存寸磋撮搓措挫错搭达答瘩打大呆歹傣戴带殆代贷袋待逮怠耽担丹单郸掸胆旦氮但惮淡诞弹蛋当挡党荡档刀捣蹈倒岛祷导到稻悼道盗德得的蹬灯登等瞪凳邓堤低滴迪敌笛狄涤翟嫡抵底地蒂第帝弟递缔颠掂滇碘点典靛垫电佃甸店惦奠淀殿碉叼雕凋刁掉吊钓调跌爹碟蝶迭谍叠丁盯叮钉顶鼎锭定订丢东冬董懂动栋侗恫冻洞兜抖斗陡豆逗痘都督毒犊独读堵睹赌杜镀肚度渡妒端短锻段断缎堆兑队对墩吨蹲敦顿囤钝盾遁掇哆多夺垛躲朵跺舵剁惰堕蛾峨鹅俄额讹娥恶厄扼遏鄂饿恩而儿耳尔饵洱二贰发罚筏伐乏阀法珐藩帆番翻樊矾钒繁凡烦反返范贩犯饭泛坊芳方肪房防妨仿访纺放菲非啡飞肥匪诽吠肺废沸费芬酚吩氛分纷坟焚汾粉奋份忿愤粪丰封枫蜂峰锋风疯烽逢冯缝讽奉凤佛否夫敷肤孵扶拂辐幅氟符伏俘服浮涪福袱弗甫抚辅俯釜斧脯腑府腐赴副覆赋复傅付阜父腹负富讣附妇缚咐噶嘎该改概钙盖溉干甘杆柑竿肝赶感秆敢赣冈刚钢缸肛纲岗港杠篙皋高膏羔糕搞镐稿告哥歌搁戈鸽胳疙割革葛格蛤阁隔铬个各给根跟耕更庚羹埂耿梗工攻功恭龚供躬公宫弓巩汞拱贡共钩勾沟苟狗垢构购够辜菇咕箍估沽孤姑鼓古蛊骨谷股故顾固雇刮瓜剐寡挂褂乖拐怪棺关官冠观管馆罐惯灌贯光广逛瑰规圭硅归龟闺轨鬼诡癸桂柜跪贵刽辊滚棍锅郭国果裹过哈骸孩海氦亥害骇酣憨邯韩含涵寒函喊罕翰撼捍旱憾悍焊汗汉夯杭航壕嚎豪毫郝好耗号浩呵喝荷菏核禾和何合盒貉阂河涸赫褐鹤贺嘿黑痕很狠恨哼亨横衡恒轰哄烘虹鸿洪宏弘红喉侯猴吼厚候后呼乎忽瑚壶葫胡蝴狐糊湖弧虎唬护互沪户花哗华猾滑画划化话槐徊怀淮坏欢环桓还缓换患唤痪豢焕涣宦幻荒慌黄磺蝗簧皇凰惶煌晃幌恍谎灰挥辉徽恢蛔回毁悔慧卉惠晦贿秽会烩汇讳诲绘荤昏婚魂浑混豁活伙火获或惑霍货祸击圾基机畸稽积箕肌饥迹激讥鸡姬绩缉吉极棘辑籍集及急疾汲即嫉级挤几脊己蓟技冀季伎祭剂悸济寄寂计记既忌际妓继纪嘉枷夹佳家加荚颊贾甲钾假稼价架驾嫁歼监坚尖笺间煎兼肩艰奸缄茧检柬碱硷拣捡简俭剪减荐槛鉴践贱见键箭件健舰剑饯渐溅涧建僵姜将浆江疆蒋桨奖讲匠酱降蕉椒礁焦胶交郊浇骄娇嚼搅铰矫侥脚狡角饺缴绞剿教酵轿较叫窖揭接皆秸街阶截劫节茎睛晶鲸京惊精粳经井警景颈静境敬镜径痉靖竟竞净炯窘揪究纠玖韭久灸九酒厩救旧臼舅咎就疚鞠拘狙疽居驹菊局咀矩举沮聚拒据巨具距踞锯俱句惧炬剧捐鹃娟倦眷卷绢撅攫抉掘倔爵桔杰捷睫竭洁结解姐戒藉芥界借介疥诫届巾筋斤金今津襟紧锦仅谨进靳晋禁近烬浸尽劲荆兢觉决诀绝均菌钧军君峻俊竣浚郡骏喀咖卡咯开揩楷凯慨刊堪勘坎砍看康慷糠扛抗亢炕考拷烤靠坷苛柯棵磕颗科壳咳可渴克刻客课肯啃垦恳坑吭空恐孔控抠口扣寇枯哭窟苦酷库裤夸垮挎跨胯块筷侩快宽款匡筐狂框矿眶旷况亏盔岿窥葵奎魁傀馈愧溃坤昆捆困括扩廓阔垃拉喇蜡腊辣啦莱来赖蓝婪栏拦篮阑兰澜谰揽览懒缆烂滥琅榔狼廊郎朗浪捞劳牢老佬姥酪烙涝勒乐雷镭蕾磊累儡垒擂肋类泪棱楞冷厘梨犁黎篱狸离漓理李里鲤礼莉荔吏栗丽厉励砾历利傈例俐痢立粒沥隶力璃哩俩联莲连镰廉怜涟帘敛脸链恋炼练粮凉梁粱良两辆量晾亮谅撩聊僚疗燎寥辽潦了撂镣廖料列裂烈劣猎琳林磷霖临邻鳞淋凛赁吝拎玲菱零龄铃伶羚凌灵陵岭领另令溜琉榴硫馏留刘瘤流柳六龙聋咙笼窿隆垄拢陇楼娄搂篓漏陋芦卢颅庐炉掳卤虏鲁麓碌露路赂鹿潞禄录陆戮驴吕铝侣旅履屡缕虑氯律率滤绿峦挛孪滦卵乱掠略抡轮伦仑沦纶论萝螺罗逻锣箩骡裸落洛骆络妈麻玛码蚂马骂嘛吗埋买麦卖迈脉瞒馒蛮满蔓曼慢漫谩芒茫盲氓忙莽猫茅锚毛矛铆卯茂冒帽貌贸么玫枚梅酶霉煤没眉媒镁每美昧寐妹媚门闷们萌蒙檬盟锰猛梦孟眯醚靡糜迷谜弥米秘觅泌蜜密幂棉眠绵冕免勉娩缅面苗描瞄藐秒渺庙妙蔑灭民抿皿敏悯闽明螟鸣铭名命谬摸摹蘑模膜磨摩魔抹末莫墨默沫漠寞陌谋牟某拇牡亩姆母墓暮幕募慕木目睦牧穆拿哪呐钠那娜纳氖乃奶耐奈南男难囊挠脑恼闹淖呢馁内嫩能妮霓倪泥尼拟你匿腻逆溺蔫拈年碾撵捻念娘酿鸟尿捏聂孽啮镊镍涅您柠狞凝宁拧泞牛扭钮纽脓浓农弄奴努怒女暖虐疟挪懦糯诺哦欧鸥殴藕呕偶沤啪趴爬帕怕琶拍排牌徘湃派攀潘盘磐盼畔判叛乓庞旁耪胖抛咆刨炮袍跑泡呸胚培裴赔陪配佩沛喷盆砰抨烹澎彭蓬棚硼篷膨朋鹏捧碰坯砒霹批披劈琵毗啤脾疲皮匹痞僻屁譬篇偏片骗飘漂瓢票撇瞥拼频贫品聘乒坪苹萍平凭瓶评屏坡泼颇婆破魄迫粕剖扑铺仆莆葡菩蒲埔朴圃普浦谱曝瀑期欺栖戚妻七凄漆柒沏其棋奇歧畦崎脐齐旗祈祁骑起岂乞企启契砌器气迄弃汽泣讫掐洽牵扦钎铅千迁签仟谦乾黔钱钳前潜遣浅谴堑嵌欠歉枪呛腔羌墙蔷强抢橇锹敲悄桥瞧乔侨巧鞘撬翘峭俏窍切茄且怯窃钦侵亲秦琴勤芹擒禽寝沁青轻氢倾卿清擎晴氰情顷请庆琼穷秋丘邱球求囚酋泅趋区蛆曲躯屈驱渠取娶龋趣去圈颧权醛泉全痊拳犬券劝缺炔瘸却鹊榷确雀裙群然燃冉染瓤壤攘嚷让饶扰绕惹热壬仁人忍韧任认刃妊纫扔仍日戎茸蓉荣融熔溶容绒冗揉柔肉茹蠕儒孺如辱乳汝入褥软阮蕊瑞锐闰润若弱撒洒萨腮鳃塞赛三叁伞散桑嗓丧搔骚扫嫂瑟色涩森僧莎砂杀刹沙纱傻啥煞筛晒珊苫杉山删煽衫闪陕擅赡膳善汕扇缮墒伤商赏晌上尚裳梢捎稍烧芍勺韶少哨邵绍奢赊蛇舌舍赦摄射慑涉社设砷申呻伸身深娠绅神沈审婶甚肾慎渗声生甥牲升绳省盛剩胜圣师失狮施湿诗尸虱十石拾时什食蚀实识史矢使屎驶始式示士世柿事拭誓逝势是嗜噬适仕侍释饰氏市恃室视试收手首守寿授售受瘦兽蔬枢梳殊抒输叔舒淑疏书赎孰熟薯暑曙署蜀黍鼠属术述树束戍竖墅庶数漱恕刷耍摔衰甩帅栓拴霜双爽谁水睡税吮瞬顺舜说硕朔烁斯撕嘶思私司丝死肆寺嗣四伺似饲巳松耸怂颂送宋讼诵搜艘擞嗽苏酥俗素速粟僳塑溯宿诉肃酸蒜算虽隋随绥髓碎岁穗遂隧祟孙损笋蓑梭唆缩琐索锁所塌他它她塔獭挞蹋踏胎苔抬台泰酞太态汰坍摊贪瘫滩坛檀痰潭谭谈坦毯袒碳探叹炭汤塘搪堂棠膛唐糖倘躺淌趟烫掏涛滔绦萄桃逃淘陶讨套特藤腾疼誊梯剔踢锑提题蹄啼体替嚏惕涕剃屉天添填田甜恬舔腆挑条迢眺跳贴铁帖厅听烃汀廷停亭庭挺艇通桐酮瞳同铜彤童桶捅筒统痛偷投头透凸秃突图徒途涂屠土吐兔湍团推颓腿蜕褪退吞屯臀拖托脱鸵陀驮驼椭妥拓唾挖哇蛙洼娃瓦袜歪外豌弯湾玩顽丸烷完碗挽晚皖惋宛婉万腕汪王亡枉网往旺望忘妄威巍微危韦违桅围唯惟为潍维苇萎委伟伪尾纬未蔚味畏胃喂魏位渭谓尉慰卫瘟温蚊文闻纹吻稳紊问嗡翁瓮挝蜗涡窝我斡卧握沃巫呜钨乌污诬屋无芜梧吾吴毋武五捂午舞伍侮坞戊雾晤物勿务悟误昔熙析西硒矽晰嘻吸锡牺稀息希悉膝夕惜熄烯溪汐犀檄袭席习媳喜铣洗系隙戏细瞎虾匣霞辖暇峡侠狭下厦夏吓掀锨先仙鲜纤咸贤衔舷闲涎弦嫌显险现献县腺馅羡宪陷限线相厢镶香箱襄湘乡翔祥详想响享项巷橡像向象萧硝霄削哮嚣销消宵淆晓小孝校肖啸笑效楔些歇蝎鞋协挟携邪斜胁谐写械卸蟹懈泄泻谢屑薪芯锌欣辛新忻心信衅星腥猩惺兴刑型形邢行醒幸杏性姓兄凶胸匈汹雄熊休修羞朽嗅锈秀袖绣墟戌需虚嘘须徐许蓄酗叙旭序畜恤絮婿绪续轩喧宣悬旋玄选癣眩绚靴薛学穴雪血勋熏循旬询寻驯巡殉汛训讯逊迅压押鸦鸭呀丫芽牙蚜崖衙涯雅哑亚讶焉咽阉烟淹盐严研蜒岩延言颜阎炎沿奄掩眼衍演艳堰燕厌砚雁唁彦焰宴谚验殃央鸯秧杨扬佯疡羊洋阳氧仰痒养样漾邀腰妖瑶摇尧遥窑谣姚咬舀药要耀椰噎耶爷野冶也页掖业叶曳腋夜液一壹医揖铱依伊衣颐夷遗移仪胰疑沂宜姨彝椅蚁倚已乙矣以艺抑易邑屹亿役臆逸肄疫亦裔意毅忆义益溢诣议谊译异翼翌绎茵荫因殷音阴姻吟银淫寅饮尹引隐印英樱婴鹰应缨莹萤营荧蝇迎赢盈影颖硬映哟拥佣臃痈庸雍踊蛹咏泳涌永恿勇用幽优悠忧尤由邮铀犹油游酉有友右佑釉诱又幼迂淤于盂榆虞愚舆余俞逾鱼愉渝渔隅予娱雨与屿禹宇语羽玉域芋郁吁遇喻峪御愈欲狱育誉浴寓裕预豫驭鸳渊冤元垣袁原援辕园员圆猿源缘远苑愿怨院曰约越跃钥岳粤月悦阅耘云郧匀陨允运蕴酝晕韵孕匝砸杂栽哉灾宰载再在咱攒暂赞赃脏葬遭糟凿藻枣早澡蚤躁噪造皂灶燥责择则泽贼怎增憎曾赠扎喳渣札轧铡闸眨栅榨咋乍炸诈摘斋宅窄债寨瞻毡詹粘沾盏斩辗崭展蘸栈占战站湛绽樟章彰漳张掌涨杖丈帐账仗胀瘴障招昭找沼赵照罩兆肇召遮折哲蛰辙者锗蔗这浙珍斟真甄砧臻贞针侦枕疹诊震振镇阵蒸挣睁征狰争怔整拯正政帧症郑证芝枝支吱蜘知肢脂汁之织职直植殖执值侄址指止趾只旨纸志挚掷至致置帜峙制智秩稚质炙痔滞治窒中盅忠钟衷终种肿重仲众舟周州洲诌粥轴肘帚咒皱宙昼骤珠株蛛朱猪诸诛逐竹烛煮拄瞩嘱主著柱助蛀贮铸筑住注祝驻抓爪拽专砖转撰赚篆桩庄装妆撞壮状椎锥追赘坠缀谆准捉拙卓桌琢茁酌啄着灼浊兹咨资姿滋淄孜紫仔籽滓子自渍字鬃棕踪宗综总纵邹走奏揍租足卒族祖诅阻组钻纂嘴醉最罪尊遵昨左佐柞做作坐座';
	var 正体中文 = '啊阿埃挨哎唉哀皚癌藹矮艾礙愛隘鞍氨安俺按暗岸胺案肮昂盎凹敖熬翺襖傲奧懊澳芭捌扒叭吧笆八疤巴拔跋靶把耙壩霸罷爸白柏百擺佰敗拜稗斑班搬扳般頒板版扮拌伴瓣半辦絆邦幫梆榜膀綁棒磅蚌鎊傍謗苞胞包褒剝薄雹保堡飽寶抱報暴豹鮑爆杯碑悲卑北輩背貝鋇倍狽備憊焙被奔苯本笨崩繃甭泵蹦迸逼鼻比鄙筆彼碧蓖蔽畢斃毖幣庇痹閉敝弊必辟壁臂避陛鞭邊編貶扁便變卞辨辯辮遍標彪膘表鼈憋別癟彬斌瀕濱賓擯兵冰柄丙秉餅炳病並玻菠播撥缽波博勃搏鉑箔伯帛舶脖膊渤泊駁捕蔔哺補埠不布步簿部怖擦猜裁材才財睬踩采彩菜蔡餐參蠶殘慚慘燦蒼艙倉滄藏操糙槽曹草廁策側冊測層蹭插叉茬茶查碴搽察岔差詫拆柴豺攙摻蟬饞讒纏鏟産闡顫昌猖場嘗常長償腸廠敞暢唱倡超抄鈔朝嘲潮巢吵炒車扯撤掣徹澈郴臣辰塵晨忱沈陳趁襯撐稱城橙成呈乘程懲澄誠承逞騁秤吃癡持匙池遲弛馳恥齒侈尺赤翅斥熾充衝沖蟲崇寵抽酬疇躊稠愁籌仇綢瞅醜臭初出櫥廚躇鋤雛滁除楚礎儲矗搐觸處揣川穿椽傳船喘串瘡窗幢床闖創吹炊捶錘垂春椿醇唇淳純蠢戳綽疵茨磁雌辭慈瓷詞此刺賜次聰蔥囪匆從叢湊粗醋簇促躥篡竄摧崔催脆瘁粹淬翠村存寸磋撮搓措挫錯搭達答瘩打大呆歹傣戴帶殆代貸袋待逮怠耽擔丹單鄲撣膽旦氮但憚淡誕彈蛋當擋黨蕩檔刀搗蹈倒島禱導到稻悼道盜德得的蹬燈登等瞪凳鄧堤低滴迪敵笛狄滌翟嫡抵底地蒂第帝弟遞締顛掂滇碘點典靛墊電佃甸店惦奠澱殿碉叼雕凋刁掉吊釣調跌爹碟蝶叠諜疊丁盯叮釘頂鼎錠定訂丟東冬董懂動棟侗恫凍洞兜抖鬥陡豆逗痘都督毒犢獨讀堵睹賭杜鍍肚度渡妒端短鍛段斷緞堆兌隊對墩噸蹲敦頓囤鈍盾遁掇哆多奪垛躲朵跺舵剁惰墮蛾峨鵝俄額訛娥惡厄扼遏鄂餓恩而兒耳爾餌洱二貳發罰筏伐乏閥法琺藩帆番翻樊礬釩繁凡煩反返範販犯飯泛坊芳方肪房防妨仿訪紡放菲非啡飛肥匪誹吠肺廢沸費芬酚吩氛分紛墳焚汾粉奮份忿憤糞豐封楓蜂峰鋒風瘋烽逢馮縫諷奉鳳佛否夫敷膚孵扶拂輻幅氟符伏俘服浮涪福袱弗甫撫輔俯釜斧脯腑府腐赴副覆賦複傅付阜父腹負富訃附婦縛咐噶嘎該改概鈣蓋溉幹甘杆柑竿肝趕感稈敢贛岡剛鋼缸肛綱崗港杠篙臯高膏羔糕搞鎬稿告哥歌擱戈鴿胳疙割革葛格蛤閣隔鉻個各給根跟耕更庚羹埂耿梗工攻功恭龔供躬公宮弓鞏汞拱貢共鈎勾溝苟狗垢構購夠辜菇咕箍估沽孤姑鼓古蠱骨谷股故顧固雇刮瓜剮寡挂褂乖拐怪棺關官冠觀管館罐慣灌貫光廣逛瑰規圭矽歸龜閨軌鬼詭癸桂櫃跪貴劊輥滾棍鍋郭國果裹過哈骸孩海氦亥害駭酣憨邯韓含涵寒函喊罕翰撼捍旱憾悍焊汗漢夯杭航壕嚎豪毫郝好耗號浩呵喝荷菏核禾和何合盒貉閡河涸赫褐鶴賀嘿黑痕很狠恨哼亨橫衡恒轟哄烘虹鴻洪宏弘紅喉侯猴吼厚候後呼乎忽瑚壺葫胡蝴狐糊湖弧虎唬護互滬戶花嘩華猾滑畫劃化話槐徊懷淮壞歡環桓還緩換患喚瘓豢煥渙宦幻荒慌黃磺蝗簧皇凰惶煌晃幌恍謊灰揮輝徽恢蛔回毀悔慧卉惠晦賄穢會燴彙諱誨繪葷昏婚魂渾混豁活夥火獲或惑霍貨禍擊圾基機畸稽積箕肌饑迹激譏雞姬績緝吉極棘輯籍集及急疾汲即嫉級擠幾脊己薊技冀季伎祭劑悸濟寄寂計記既忌際妓繼紀嘉枷夾佳家加莢頰賈甲鉀假稼價架駕嫁殲監堅尖箋間煎兼肩艱奸緘繭檢柬堿鹼揀撿簡儉剪減薦檻鑒踐賤見鍵箭件健艦劍餞漸濺澗建僵姜將漿江疆蔣槳獎講匠醬降蕉椒礁焦膠交郊澆驕嬌嚼攪鉸矯僥腳狡角餃繳絞剿教酵轎較叫窖揭接皆稭街階截劫節莖睛晶鯨京驚精粳經井警景頸靜境敬鏡徑痙靖竟競淨炯窘揪究糾玖韭久灸九酒廄救舊臼舅咎就疚鞠拘狙疽居駒菊局咀矩舉沮聚拒據巨具距踞鋸俱句懼炬劇捐鵑娟倦眷卷絹撅攫抉掘倔爵桔傑捷睫竭潔結解姐戒藉芥界借介疥誡屆巾筋斤金今津襟緊錦僅謹進靳晉禁近燼浸盡勁荊兢覺決訣絕均菌鈞軍君峻俊竣浚郡駿喀咖卡咯開揩楷凱慨刊堪勘坎砍看康慷糠扛抗亢炕考拷烤靠坷苛柯棵磕顆科殼咳可渴克刻客課肯啃墾懇坑吭空恐孔控摳口扣寇枯哭窟苦酷庫褲誇垮挎跨胯塊筷儈快寬款匡筐狂框礦眶曠況虧盔巋窺葵奎魁傀饋愧潰坤昆捆困括擴廓闊垃拉喇蠟臘辣啦萊來賴藍婪欄攔籃闌蘭瀾讕攬覽懶纜爛濫琅榔狼廊郎朗浪撈勞牢老佬姥酪烙澇勒樂雷鐳蕾磊累儡壘擂肋類淚棱楞冷厘梨犁黎籬狸離漓理李裏鯉禮莉荔吏栗麗厲勵礫曆利傈例俐痢立粒瀝隸力璃哩倆聯蓮連鐮廉憐漣簾斂臉鏈戀煉練糧涼梁粱良兩輛量晾亮諒撩聊僚療燎寥遼潦了撂鐐廖料列裂烈劣獵琳林磷霖臨鄰鱗淋凜賃吝拎玲菱零齡鈴伶羚淩靈陵嶺領另令溜琉榴硫餾留劉瘤流柳六龍聾嚨籠窿隆壟攏隴樓婁摟簍漏陋蘆盧顱廬爐擄鹵虜魯麓碌露路賂鹿潞祿錄陸戮驢呂鋁侶旅履屢縷慮氯律率濾綠巒攣孿灤卵亂掠略掄輪倫侖淪綸論蘿螺羅邏鑼籮騾裸落洛駱絡媽麻瑪碼螞馬罵嘛嗎埋買麥賣邁脈瞞饅蠻滿蔓曼慢漫謾芒茫盲氓忙莽貓茅錨毛矛鉚卯茂冒帽貌貿麽玫枚梅酶黴煤沒眉媒鎂每美昧寐妹媚門悶們萌蒙檬盟錳猛夢孟眯醚靡糜迷謎彌米秘覓泌蜜密冪棉眠綿冕免勉娩緬面苗描瞄藐秒渺廟妙蔑滅民抿皿敏憫閩明螟鳴銘名命謬摸摹蘑模膜磨摩魔抹末莫墨默沫漠寞陌謀牟某拇牡畝姆母墓暮幕募慕木目睦牧穆拿哪呐鈉那娜納氖乃奶耐奈南男難囊撓腦惱鬧淖呢餒內嫩能妮霓倪泥尼擬你匿膩逆溺蔫拈年碾攆撚念娘釀鳥尿捏聶孽齧鑷鎳涅您檸獰凝甯擰濘牛扭鈕紐膿濃農弄奴努怒女暖虐瘧挪懦糯諾哦歐鷗毆藕嘔偶漚啪趴爬帕怕琶拍排牌徘湃派攀潘盤磐盼畔判叛乓龐旁耪胖抛咆刨炮袍跑泡呸胚培裴賠陪配佩沛噴盆砰抨烹澎彭蓬棚硼篷膨朋鵬捧碰坯砒霹批披劈琵毗啤脾疲皮匹痞僻屁譬篇偏片騙飄漂瓢票撇瞥拼頻貧品聘乒坪蘋萍平憑瓶評屏坡潑頗婆破魄迫粕剖撲鋪仆莆葡菩蒲埔樸圃普浦譜曝瀑期欺棲戚妻七淒漆柒沏其棋奇歧畦崎臍齊旗祈祁騎起豈乞企啓契砌器氣迄棄汽泣訖掐洽牽扡釺鉛千遷簽仟謙乾黔錢鉗前潛遣淺譴塹嵌欠歉槍嗆腔羌牆薔強搶橇鍬敲悄橋瞧喬僑巧鞘撬翹峭俏竅切茄且怯竊欽侵親秦琴勤芹擒禽寢沁青輕氫傾卿清擎晴氰情頃請慶瓊窮秋丘邱球求囚酋泅趨區蛆曲軀屈驅渠取娶齲趣去圈顴權醛泉全痊拳犬券勸缺炔瘸卻鵲榷確雀裙群然燃冉染瓤壤攘嚷讓饒擾繞惹熱壬仁人忍韌任認刃妊紉扔仍日戎茸蓉榮融熔溶容絨冗揉柔肉茹蠕儒孺如辱乳汝入褥軟阮蕊瑞銳閏潤若弱撒灑薩腮鰓塞賽三三傘散桑嗓喪搔騷掃嫂瑟色澀森僧莎砂殺刹沙紗傻啥煞篩曬珊苫杉山刪煽衫閃陝擅贍膳善汕扇繕墒傷商賞晌上尚裳梢捎稍燒芍勺韶少哨邵紹奢賒蛇舌舍赦攝射懾涉社設砷申呻伸身深娠紳神沈審嬸甚腎慎滲聲生甥牲升繩省盛剩勝聖師失獅施濕詩屍虱十石拾時什食蝕實識史矢使屎駛始式示士世柿事拭誓逝勢是嗜噬適仕侍釋飾氏市恃室視試收手首守壽授售受瘦獸蔬樞梳殊抒輸叔舒淑疏書贖孰熟薯暑曙署蜀黍鼠屬術述樹束戍豎墅庶數漱恕刷耍摔衰甩帥栓拴霜雙爽誰水睡稅吮瞬順舜說碩朔爍斯撕嘶思私司絲死肆寺嗣四伺似飼巳松聳慫頌送宋訟誦搜艘擻嗽蘇酥俗素速粟僳塑溯宿訴肅酸蒜算雖隋隨綏髓碎歲穗遂隧祟孫損筍蓑梭唆縮瑣索鎖所塌他它她塔獺撻蹋踏胎苔擡台泰酞太態汰坍攤貪癱灘壇檀痰潭譚談坦毯袒碳探歎炭湯塘搪堂棠膛唐糖倘躺淌趟燙掏濤滔縧萄桃逃淘陶討套特藤騰疼謄梯剔踢銻提題蹄啼體替嚏惕涕剃屜天添填田甜恬舔腆挑條迢眺跳貼鐵帖廳聽烴汀廷停亭庭挺艇通桐酮瞳同銅彤童桶捅筒統痛偷投頭透凸禿突圖徒途塗屠土吐兔湍團推頹腿蛻褪退吞屯臀拖托脫鴕陀馱駝橢妥拓唾挖哇蛙窪娃瓦襪歪外豌彎灣玩頑丸烷完碗挽晚皖惋宛婉萬腕汪王亡枉網往旺望忘妄威巍微危韋違桅圍唯惟爲濰維葦萎委偉僞尾緯未蔚味畏胃餵魏位渭謂尉慰衛瘟溫蚊文聞紋吻穩紊問嗡翁甕撾蝸渦窩我斡臥握沃巫嗚鎢烏汙誣屋無蕪梧吾吳毋武五捂午舞伍侮塢戊霧晤物勿務悟誤昔熙析西硒矽晰嘻吸錫犧稀息希悉膝夕惜熄烯溪汐犀檄襲席習媳喜銑洗系隙戲細瞎蝦匣霞轄暇峽俠狹下廈夏嚇掀鍁先仙鮮纖鹹賢銜舷閑涎弦嫌顯險現獻縣腺餡羨憲陷限線相廂鑲香箱襄湘鄉翔祥詳想響享項巷橡像向象蕭硝霄削哮囂銷消宵淆曉小孝校肖嘯笑效楔些歇蠍鞋協挾攜邪斜脅諧寫械卸蟹懈泄瀉謝屑薪芯鋅欣辛新忻心信釁星腥猩惺興刑型形邢行醒幸杏性姓兄凶胸匈洶雄熊休修羞朽嗅鏽秀袖繡墟戌需虛噓須徐許蓄酗敘旭序畜恤絮婿緒續軒喧宣懸旋玄選癬眩絢靴薛學穴雪血勳熏循旬詢尋馴巡殉汛訓訊遜迅壓押鴉鴨呀丫芽牙蚜崖衙涯雅啞亞訝焉咽閹煙淹鹽嚴研蜒岩延言顔閻炎沿奄掩眼衍演豔堰燕厭硯雁唁彥焰宴諺驗殃央鴦秧楊揚佯瘍羊洋陽氧仰癢養樣漾邀腰妖瑤搖堯遙窯謠姚咬舀藥要耀椰噎耶爺野冶也頁掖業葉曳腋夜液一壹醫揖銥依伊衣頤夷遺移儀胰疑沂宜姨彜椅蟻倚已乙矣以藝抑易邑屹億役臆逸肄疫亦裔意毅憶義益溢詣議誼譯異翼翌繹茵蔭因殷音陰姻吟銀淫寅飲尹引隱印英櫻嬰鷹應纓瑩螢營熒蠅迎贏盈影穎硬映喲擁傭臃癰庸雍踴蛹詠泳湧永恿勇用幽優悠憂尤由郵鈾猶油遊酉有友右佑釉誘又幼迂淤于盂榆虞愚輿余俞逾魚愉渝漁隅予娛雨與嶼禹宇語羽玉域芋郁籲遇喻峪禦愈欲獄育譽浴寓裕預豫馭鴛淵冤元垣袁原援轅園員圓猿源緣遠苑願怨院曰約越躍鑰嶽粵月悅閱耘雲鄖勻隕允運蘊醞暈韻孕匝砸雜栽哉災宰載再在咱攢暫贊贓髒葬遭糟鑿藻棗早澡蚤躁噪造皂竈燥責擇則澤賊怎增憎曾贈紮喳渣劄軋鍘閘眨柵榨咋乍炸詐摘齋宅窄債寨瞻氈詹粘沾盞斬輾嶄展蘸棧占戰站湛綻樟章彰漳張掌漲杖丈帳賬仗脹瘴障招昭找沼趙照罩兆肇召遮折哲蟄轍者鍺蔗這浙珍斟真甄砧臻貞針偵枕疹診震振鎮陣蒸掙睜征猙爭怔整拯正政幀症鄭證芝枝支吱蜘知肢脂汁之織職直植殖執值侄址指止趾只旨紙志摯擲至致置幟峙制智秩稚質炙痔滯治窒中盅忠鍾衷終種腫重仲衆舟周州洲謅粥軸肘帚咒皺宙晝驟珠株蛛朱豬諸誅逐竹燭煮拄矚囑主著柱助蛀貯鑄築住注祝駐抓爪拽專磚轉撰賺篆樁莊裝妝撞壯狀椎錐追贅墜綴諄准捉拙卓桌琢茁酌啄著灼濁茲咨資姿滋淄孜紫仔籽滓子自漬字鬃棕蹤宗綜總縱鄒走奏揍租足卒族祖詛阻組鑽纂嘴醉最罪尊遵昨左佐柞做作坐座';
	/**
	 * 默认是否正体中文:true为正体;false简体。 HTTP
	 * 头读取:Request.ServerVariables("http_accept_language")
	 * 
	 * @return {Boolean}
	 */
	function getClientLanguage() {
		var s = navigator.userLanguage || navigator.language;
		switch (s.toLowerCase()) {
		case 'zh-cn':
			return false;
		case 'zh-tw':
			return true;
		default:
			return null;
		}
	}
	
	/**
	 * 转换对象,使用递归,逐层剥到文本
	 * @param {HTMLElement} obj 从document.body开始,
	 */
	function translate(el, coverntFn){
		el = el.childNodes;
		var node;
		for (var i = 0, j = el.length; i < j; i++) {
			node = el.item(i);
// || (node == $$.big5.el)
			if (("||BR|HR|TEXTAREA|".indexOf("|" + node.tagName + "|")) > 0)continue;
			
			if(node.title){
				node.title = coverntFn(node.title);
			}else if(node.alt){
				node.alt = coverntFn(node.alt);
			}else if(node.tagName == "INPUT" && node.value != "" && node.type != "text" && node.type != "hidden"){
				node.value = coverntFn(node.value);
			}else if(node.nodeType == 3){
				node.data = coverntFn(node.data);
			}else{
				arguments.callee(node, coverntFn);
			}		
		}
	}
	
	function translateText(text, isBig5) {
		var str = [], _char, charIndex, result;
		for (var i = 0, j = text.length; i < j; i++) {
			_char = text.charAt(i);
			charIndex = isBig5 ? 简化中文.indexOf(_char) : 正体中文.indexOf(_char); 
			result = isBig5 ? 正体中文.charAt(charIndex) : 简化中文.charAt(charIndex);
			str.push(charIndex != -1 ? result : _char);
		}
		return str.join('');
	}
	var traditionalized = translateText.delegate(null, true), simplized = translateText.delegate(null, false);
	
	var cookieName = 'ChineseType';
	
	// 转换为正体中文(繁体中文)
	window.toChinese = function(el) {
		el.addCls('selected');
		document.querySelector(".simpleChinese").removeCls('selected');
		translate(document.body, traditionalized)
		Cookie.set(cookieName, true);
	}
	// 转换为简体中文
	window.toSimpleChinese = function(el) {
		el.addCls('selected');
		document.querySelector(".Chinese").removeCls('selected');
		translate(document.body, simplized);
		Cookie.set(cookieName, false);
	}
	
	var Cookie = {
	 set: function (name, val) {
	 var exp = new Date();
	 exp.setDate(exp.getDate() + 600 * 1000);
	 document.cookie = name + "=" + escape(val) + ";expires=" + exp.toGMTString();
	 }, del: function (name) {
	 document.cookie = name + "=;expires=" + (new Date(0)).toGMTString();
	 }, get: function (name) {
	 var cookieArray = document.cookie.match(new RegExp("(^| )" + name + "=([^;]*)(;|$)"));
	 if (cookieArray != null) return unescape(cookieArray[2]);
	 else return null;
	 }
	};
	
	var value = Cookie.get(cookieName);
	if( value == null && getClientLanguage() || value == 'true') {		
		// 没有检查出 cookie 则为第一次运行。
		// cookie保留了用户选择的正体,将原来的简化字转换为默认的正体!
		window.toChinese(document.querySelector(".Chinese"));
	} else if(value == null && !getClientLanguage() || value == 'false') {
		// 虽然第一次运行,但对方正是简体中文,不用转。
		// 原来已经是简体,无须转换。
	}
})();

然后绑定按钮事件,我们简单地使用 onclick 绑定来全局函数 window.toChinese(el)、window.toSimpleChinese(el)。el 是按钮元素。

	// 转换为正体中文(繁体中文)
	window.toChinese = function(el) {
		el.addCls('selected');
		document.querySelector(".simpleChinese").removeCls('selected');
		translate(document.body, traditionalized)
		Cookie.set(cookieName, true);
	}
	// 转换为简体中文
	window.toSimpleChinese = function(el) {
		el.addCls('selected');
		document.querySelector(".Chinese").removeCls('selected');
		translate(document.body, simplized);
		Cookie.set(cookieName, false);
	}

js 代码中比较长的两个字符串变量分别是简体中文和繁体中文,他们之间的切换没有什么神奇之处,只是所有文本经过这些变量一一对应即可。当然这里只是常用的繁简对应,而且是机械的,有些特殊的翻译需要联系上下文的,那种高级转换不在此讨论之列。

首先我们看看变量函数 translate,执行它会通过递归遍历完整个 DOM(可以说比较笨的方法)

/**
	 * 转换对象,使用递归,逐层剥到文本
	 * @param {HTMLElement} obj 从document.body开始,
	 */
	function translate(el, coverntFn){
		el = el.childNodes;
		var node;
		for (var i = 0, j = el.length; i < j; i++) {
			node = el.item(i);
// || (node == $$.big5.el)
			if (("||BR|HR|TEXTAREA|".indexOf("|" + node.tagName + "|")) > 0)continue;
			
			if(node.title){
				node.title = coverntFn(node.title);
			}else if(node.alt){
				node.alt = coverntFn(node.alt);
			}else if(node.tagName == "INPUT" && node.value != "" && node.type != "text" && node.type != "hidden"){
				node.value = coverntFn(node.value);
			}else if(node.nodeType == 3){
				node.data = coverntFn(node.data);
			}else{
				arguments.callee(node, coverntFn);
			}		
		}
	}

转换 DOM 内容,我们第一时间想到的可能是 el.innerHTML,但其实大可不必,而且递归的时候 innerHTML 不太方便。不妨再想想看,我们其实只需要对文本转换即可,DOM API 能够判断 文本节点(node.nodeType == 3),然后可读可写的 data 属性就是设置文本的(textNode.data),由此我们就可以完成到繁体的切换。节点其他属性 title、alt、value 亦是同样原理。另外,if (("||BR|HR|TEXTAREA|".indexOf("|" + node.tagName + "|")) > 0)continue; 是排除某些节点的方法,其思路比较特别,可以多观摩下。

至于 coverntFn 是一函数参数。通过根函数 translateText(text, isBig5) 新生成两个函数 :var traditionalized = translateText.delegate(null, true), simplized = translateText.delegate(null, false);

	function translateText(text, isBig5) {
		var str = [], _char, charIndex, result;
		for (var i = 0, j = text.length; i < j; i++) {
			_char = text.charAt(i);
			charIndex = isBig5 ? 简化中文.indexOf(_char) : 正体中文.indexOf(_char); 
			result = isBig5 ? 正体中文.charAt(charIndex) : 简化中文.charAt(charIndex);
			str.push(charIndex != -1 ? result : _char);
		}
		return str.join('');
	}
	var traditionalized = translateText.delegate(null, true), simplized = translateText.delegate(null, false);

Function.prototype.delegate() 方法如下。

/**
 * 函数委托 参见 http://blog.csdn.net/zhangxin09/article/details/8508128
 * @return {Function}
*/
Function.prototype.delegate = function () {
 var self = this, scope = this.scope, args = arguments, aLength = arguments.length, fnToken = 'function';
 return function(){
 var bLength = arguments.length, Length = (aLength > bLength) ? aLength : bLength;
 // mission one:
 for (var i = 0; i < Length; i++)
 if (arguments[i])args[i] = arguments[i]; // 拷贝参数
 args.length = Length; // 在 MS jscript下面,arguments作为数字来使用还是有问题,就是length不能自动更新。修正如左:
 // mission two:
 for (var i = 0, j = args.length; i < j; i++) {
 var _arg = args[i];
 if (_arg && typeof _arg == fnToken && _arg.late == true)
 args[i] = _arg.apply(scope || this, args);
 }
 return self.apply(scope || this, args);
 };
};

繁简的转换基本如此了。值得一提的是,浏览器其实替我们识别语言环境的变量,主要是 navigator.userLanguage || navigator.language。这个变量在服务端也可以获取,头读取:Request.ServerVariables("http_accept_language")。

/**
	 * 默认是否正体中文:true为正体;false简体。 HTTP
	 * 头读取:Request.ServerVariables("http_accept_language")
	 * 
	 * @return {Boolean}
	 */
	function getClientLanguage() {
		var s = navigator.userLanguage || navigator.language;
		switch (s.toLowerCase()) {
		case 'zh-cn':
			return false;
		case 'zh-tw':
			return true;
		default:
			return null;
		}
	}

最后我们还通过 cookie 来保存语言状态。