DOM扫描ＸＭＬ后设节点树

　　一般使用DOM扫描一个XML文档后会生成一个以节点树表示的文档，XML中的每一个元素、实体、PCData和Attribut都会生成一个节点，节点类型是实现了Node接口的类。参考代码如下：


public static void getScanner(String address) throws Exception{
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
//create a DocumentBuilderFactory

DocumentBuilder db = null;
//create a DocumentBuilder
try{
　　db=dbf.newDocumentBuilder();
　　} catch (ParserConfigurationException pce){
　　　　System.err.println(pce);
　　　　System.exit(1);
　　}

Document doc = null;
try{
　　doc=db.parse(new File(address));
　　} catch (SAXException se){
　　　　System.err.println(se.getMessage());
　　　　//to be replaced by the log method;
　　　　System.exit(1);
} catch (IOException ioe){
System.err.println(ioe);
//to be replaced by the log method;
System.exit(1);
}
//parse the input file
}

public static void printxml(Node n)
{
//recursive routine to print out Dom Tree nodes
int type = n.getNodeType();

switch (type){
case Node.DOCUMENT_NODE:
System.out.print("DOC:");
break;
case Node.DOCUMENT_TYPE_NODE:
System.out.print("DOC_TYPE:");
break;
　case Node.ELEMENT_NODE:
System.out.print("ELEM:");
break;
case Node.TEXT_NODE:
System.out.print("TEXT:");
break;
default:
System.out.print("Other Node:" + type);
break;
}

System.out.print(" nodeName=\"" + n.getNodeName() + "\"");

String val = n.getNodeValue();
if(val!=null){
if (!(val.trim().equals(""))){
System.out.print("nodeValue \"" + n.getNodeValue() + "\"");
}
}
System.out.println();


//Print children if any
for (Node child = n.getFirstChild() ; child!=null ; child = child.getNextSibling() )
{
　　printxml(child);
　　}
}


比如我导入的xml文档是这样：

<?xml version="1.0"?>

<GenericProfileOfVideoCodecSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<Name>1P-Goodquality</Name>

<Test>test</Test>

</GenericProfileOfVideoCodecSettings>

生成的文档树就是这样的：

不过，从实际情况来看GenericProfileOfVideoCodecSettings的所有子节点每个都会带着一个空白的兄弟节点，这个"空白"其实就是xml代码页中两个元素之间的空格和换行。于是上面的输出就会带有很多的
TEXT: nodeName="#text"

x264编码参数解释

源文：http://www.digital-digest.com/articles/x264_options_page1.html


你有使用mencoder ffmpeg对视频编码成h.264吗？面对复杂的编码参数无所适从吗？读读这篇文章吧，虽然它面向StaxRip和mergui.
另外，这篇文章发布于n年前，上面所说的东西实际上已经是很老的了，如果你对新的参数有兴趣请看http://mewiki.project357.com/wiki/X264_Settings

Introduction + Basic x264 Usage What is this guide about? This guide aims to explain, to people just starting out with H.264 encoding, what the various options in x264 mean and how they affect the encoded video. For each option, a description is provided, as well as a list of possible options (and their descriptions), the command line version of the option and the recommend setting is shown in underline whenever possible. If you are reading this guide, then it must mean that you already know all about H.264 and H.264 playback. If you don't, head on to our H.264 Playback Guide to get acquainted with this new video compression format. Future versions of this guide will feature more information regarding compatibility (eg. with QuickTime, iPod, PSP, Xbox). What is x264? x264 is a free H.264 encoder. It is mainly aimed at intermediate users, so it has lots of options that will be confusing to the average user. If you don't know your trellis from your pyramid, then this guide will hopefully help you to understand things a bit better (or just enough so that you don't have to select options at random). The x264 options discussed in this article are ones that can be inputted using the command line version of the tool or through a Windows GUI software called StaxRip. A separate StaxRip H.264 Encoding Guide is also available, so don't fret if you can't figure out how to use this software (or to even install it). Why use StaxRip? Or rather, why not use MeGUI? MeGUI is probably the best tool around with dealing with x264, but it can be daunting for new users because of the numerous options that are included. StaxRip is aimed more at beginners, and so has (as the author states) only the important x264 options available to configure. Plus, StaxRip assumes no knowledge of Avisynth scripting. You can also read our MeGUI H.264 Conversion Guide. Software Requirements: x264 StaxRip Basic x264 usage: At it's most basic, x264 is a command line tool, where you can specify the input, output and encoding options all through a glorious black-background/white-text command line interface. The command line syntax is as follows x264.exe options --output output.*** inputfile.*** widthxheight A simple example of a x264 command line entry: x264.exe --bitrate 1087 --output "test.mp4" "test.avi" A more complicated example of a x264 command line entry: x264.exe --pass 2 --bitrate 1087 --stats "test.stats" --ref 3 --bframes 3 --b-pyramid --weightb --b-rdo --bime --direct auto --filter -4:-3 --analyse all --8x8dct --subme 6 --me umh --trellis 1 --mixed-refs --progress --no-psnr --output "test.264" "test.avs" There are many graphical user interfaces (GUIs) which allow you to set these options through a normal Windows program, and StaxRip is one of them. Throughout this guide, whenever an x264 option is explained, both the command line equivalent and the StaxRip/GUI version of the option will be shown. Frames Basics and x264 Profiles Frames Basics: Modern compressed video are made up of 3 different types of frames. Intra (I) frames (also known as key frames), Predictive (P) and Bidirectional (B) frames. Certain types of frames can be referenced, which means a frame sometimes only need to stores the difference between it-self and the referenced frame. The problem with referencing is that any error that occurs when frame Y references frame X will be carried over and propagated if frame Y is it-self referenced later on. This is why there are also frames which can't be referenced. The I frame stores the entire image and so are the least compressible. Video seeking (when you skip to a part of a video) requires I-frames, as otherwise a symptom called seeking lag will occur when the video is blank until the next I-frame is encountered. P-frames store the difference (called "referencing") between itself and an I-frame or other P-frames. This means P-frames can be referenced, so it needs to store enough information for this to happen, but not as much I-frames because of it's encoding technique (motion compensation). B frames also store the differences between itself and other frames as well (uses both previous and future frames for reference), but it can't be referenced ("B-frame pyramid" excepted), so they are the most compressible (holds least amount of information). 264 supports "B-frame pyramids", which allow B-frames to be referenced for other consecutive B-frames, but otherwise B-frames can't be referenced by any other frame, so less information is stored. So basically, a compressed video will be a combination of I, P and B frames, some referencing others. The successful combination of these frames and the referencing determines how well the video is compressed. x264 Profiles: Profiles are the easiest way to configure x264. Profiles are basically pre-configured x264 settings that have been saved and can be loaded time and time again to encode files. They save you time by not requiring you to re-set all the options whenever you use x264, and most importantly, they give new users a chance to experience x264 without understanding what the options are. Sharktooth from the Doom9 forums has produced several profiles for everyday usage, and has made it available for download. You should read the official forum thread for details of what each profile is intended for, although the profiles "PD-PSP", "PD-Xbox_Hires", "PD-Xbox_LoRes" and "PD-iPod" should come in handy for encoding a PSP/Xbox/iPod compatible video. There are even profiles specifically designed for Anime/cartoons The other piece of good news is that software like MeGUI allow you to import profiles, and StaxRip has these profiles built into the software it self (and also allow you to edit and create your own profiles). But what if you are curious and you want to find out just what options are being selected in a profile? It's actually very easy to view profiles, because they are actually just XML files. Clicking on the XML file should open them in Internet Explorer, and you should see a screen similar to the one below: What the above shows is that for this particular profile, NbBframes to 3, KeyframeInterval to 250, trellis to false and so on. On the x264 command line, the three options I've mentioned would translates to the following: x264.exe --bframes 3 --keyint 250 --trellis 0	导言和与x264的基本用法 本篇指导的内容？ 　　这篇指导文章的目的是向那些刚开始了解H.264编码的人们解释这些纷繁复杂的选项的意义以及它们对编码的视频的影响。每个选项我都将提供它的描述，以及一个相关选项的列表，命令行选项和推荐参数设置尽可能添加下划线。 　　我假设正在阅读这篇文章的你已经了解了H.264和H.264回放，如果你不清楚的话，清先阅读我们的H.264回放指导以便于了解这种新的压缩格式。 　　这篇指导的新版本将添加更多的关于兼容性的信息（比如QuickTime,iPod,PSP,Xbox） 什么是x264? 　　x264是一个免费的H.264编码器，它主要中级用户，所以它拥有的大量的选项将会让普通用户头痛死。如果你不了解你的水平，那么这篇文章可能帮助你增加一些了解（即便是能够让你不至于乱用选项） 　　这篇文章中讨论的x264选项是那些能够在命令行版本编码器中输入的，或者通过一个windows下的被成为StaxRip的图形程序使用的。你也可以阅读StaxRip H.264 Encoding Guide。所以如果你不懂如何使用那个软件也不必烦恼。 为什么使用StaxRip？ 　　或者更进一步问，为什么不实用MeGUI?它也许是处理x264最好的工具，但是对新手来说它那大量的选项太复杂了，而这款软件是面向初学者的，并且允许导入x264选项处理，此外，它还不需要Avisynth脚本的知识。 你也可以阅读我们的MeGUI H.264 Conversion Guide. 软件需求： x264 StaxRip 基本的x264用法： 　　这是最基本的用法，x264是一个命令行工具，你能指定输入，输出文件，和编码选项通过这个黑白的命令行交互窗口。 　　命令行的使用语法是这样的： x264.exe options --output output.*** inputfile.*** widthxheight 一个通过命令行使用x264的例子： x264.exe --bitrate 1087 --output "test.mp4" "test.avi" 一个更加复杂的命令行使用x264的例子： x264.exe --pass 2 --bitrate 1087 --stats "test.stats" --ref 3 --bframes 3 --b-pyramid --weightb --b-rdo --bime --direct auto --filter -4:-3 --analyse all --8x8dct --subme 6 --me umh --trellis 1 --mixed-refs --progress --no-psnr --output "test.264" "test.avs" 　　有很多普通的windows下的图形用户界面程序允许你设置这些参数。StaxRip就是其中之一。 　　通过这篇指导，你将了解所有的x264可选参数，包括命令行和软件版本的选项. 帧基础和x264 profiles 帧基础 　　现代压缩视频是由三种不同的帧组成： Intra (I) frames（内部帧（非官方翻译），也被称作关键帧），Predictive (P)（预测帧（非官方翻译）） 和 Bidirectional (B) frames（双向帧（非官方翻译））.每个类型的帧将会被引用，这意味着一个帧有时候只需要保存它自己和被它引用的帧的不同之处。引用导致的问题是，假设当Ｙ帧引用Ｘ帧的时候，如果Ｙ帧之后被引用的话，发生的错误将被一直传递。这就是为什么有一些帧是不能被引用的原因。 　　I帧存储着整个图像，所以它最不能被压缩，视频查找（当你跳过一个部分视频的时候）就需要I帧，否则当视频是空的时候并且未遇到下一个I帧时，就会发生查找滞后的现象。 　　P帧存储着它与I帧和其他P帧的不同之处（被称作引用），这意味着P帧能被引用, 所以它需要存储有足够的信息以保证引用的正确，但是由于编码技术的运动补偿，它并不需要存有I帧那么多的信息。 　　B帧也保存着它与其他帧的不同之处（通过同时使用先前的数据以及引用它的帧的数据），但是它不能被引用（B-frame pyramid例外），所以他们是最能被压缩的部分(因为他们只需要保有最少的信息)，264支持所谓的 "B-frame pyramids"，这项技术允许B帧被其他连续的B帧引用，除此之外B帧不能被其他任何B帧引用。因此保证了它可以保存最少的信息。 　　所以，基本上一个压缩过的视频将包含I,P和B帧，其中一些引用另外一些。一个视频压缩的好不好取决于是否能够成功的混合这些帧和处理好其中的引用关系。 x264 Profiles: 　　Profiles是最简单的配置x264的方法，Profiles是已存档的基本的x264预配置文件，它能够随时被读取来编码视频。他们能够让你不需要每次都被重复要求设置所有选项，从而大大的节省了你的时间。并且，最重要的是，他们可以让一个新手有机会体验x264而不需要去了解那些选项是干什么的。 Doom9论坛的Sharktooth制作了许多profiles文件以供日常使用。你可以下载它，你应该阅读论坛的官方帖子以了解每个profiles文件的详细情况与用处，尽管那些profiles文件比如"PD-PSP", "PD-Xbox_Hires", "PD-Xbox_LoRes" 和"PD-iPod"可以让我们很便捷的编码出适用于PSP/Xbox/iPod的视频，不过我们还能找到专为动画设计的profiles文件哦。 　　另外一个好消息是像MeGUI这样的软件允许你导入profiles,而StaxRip则内建了一个profiles文件，同样它也允许你编辑和创建自己信的profiles文件。 　　不过，要是你是个很有好奇心的人，并且你想要去找出每个选项的用处，你可以很容易的查看profiles文件，因为它们是标准的xml文档，在ie中打开它你会看到下面的内容： 　　上面这个profiles配置了NbBframes为3,KeyframeInterval为250,trellis被禁用等。用命令行来表示就会被翻译成： x264.exe --bframes 3 --keyint 250 --trellis 0
x264 Options: Common Mode: Description: Selects the encoding mode to be used by the encoder. Single pass encoding can give unexpected output file sizes (Quantizer and Quality modes) and/or poorer quality compared to multi pass encoding. Available Options: Single Pass - Bitrate: Encodes the video once (single pass) with a set constant bitrate for each frame Single Pass - Quantizer: Single pass encoding with a set quantizer (higher quantizer => lower quality) for each frame Single Pass - Quality: Single pass encoding with a set quality rating for each frame Two Pass: Encodes the video twice (once to determine it's properties, another to ensure the selected output file size is reached with maximum efficiency). This is the most common setting. Three Pass: Same as Two Pass except for an extra encoding pass to ensure even better quality/accurate file size Command Line: --bitrate, --qp, --crf, --pass 1/2/3 Quantizer: Description: Only available with "Single Pass - Quantizer" mode is selected. Set the quantizer value for the encoding. A high quantizer will equal a low quality (and smaller file size). A quantizer value between 20 (high quality) and 30 (low quality) should be used. Anime/cartoons or scenes with large patches of color or less details benefit from having a higher quantizer, typical movies require a lower quantizer. Command Line: --qp n (where 'n' is the quantizer value) Quality: Description: Only available with "Single Pass - Quality" mode is selected. Set the quality value for the encoding. A high quality value equals a higher quality encoding (and larger file size). Command Line: --crf n (where 'n' is the quality value) B-Frames: Description: Selects the number of consecutive B-frames x264 should use. It is also the maximum number of consecutive B-frames x264 can use if the "Adaptive" B-frames option (see next section) is selected. B-frames are frames that are small in size, but when placed correctly, offer no loss of quality. This can help improve compression. With the "Adaptive" option on (x264 will decide how many B-frames to use), having a setting of 3 is recommended as this gives x264 enough room to work with. Command Line: --bframes n (where 'n' is the number of B-frames) Reference Frames: Description: Selects the maximum number of reference frames that can be used. Referenced frames are frames that refer to other frames (eg. if both frames are similar). Having a high referenced frame will improve quality but slow up encoding. For typical content, a reference frame of 3 to 5 is recommended. For content with a lot of repetition (eg. animation), a reference frame of 8 to 10 can be used. If a large number of reference frames is selected, then the "Mixed References" options should also be selected to allow x264 greater control (see "Analysis Options" section). Command Line: --ref n (where 'n' is the number of reference frames) Loop Filter: Description: Also known as "de-blocking" filter. Connected with the "Alpha" and "Beta" setting next to it. One of the fundamental differences between H.264 and previous codecs. Should always be enabled or excessive video artifacts may appear. Controversial because blocking (when the video looks like a series of different colored squares in low bitrate video) and artifacts are treated as details by the human visual system, and removing them makes people think details is lost, when it's actually the other way around (more "actual" details shown due to less artifacts). This is an interesting topic that is better discussed in DeathTheSheep's x264 guide. Command Line: --nf (disables loop filter) Alpha/Beta: Description: This controls the "Loop Filter" (see above). Also known as Strength (Alpha) and Threshold (Beta). Alpha determines the strength of the deblocking action. Beta determines when x264 decides something is a block and when something isn't - a high value means x264 sees more video as blocks than a lower value. For example, a too high Beta value and a too high Alpha means x264 will identify too many blocks (even when they aren't artifacts) and apply too much filtering to remove them, making the picture look "washed out" and lacking detail. Both values can be positive or negative. 0/0 (Alpha/Beta) is the default and recommended setting, unless you find the video quality unacceptable, then you should try combinations. Do not go under -2 or above 3. This is an interesting topic that is better discussed in DeathTheSheep's x264 guide. Command Line: --filter	x264 选项: 普通部分 模式: 说明：选择编码器使用的编码模式，一次编码输出的文件可能不能断定大小（在量化器和质量模式下）并且／或者可能会产生比二轮编码烂一点的质量。 可用选项： Single Pass -Bitrate:用对每帧固定码率的设置一次编码视频。 Single Pass -Quantizer:用一个对每帧设置量化器的设置一次编码视频。 Single Pass -Quality：用一个对每帧设置与源文件的质量比率的设置来一次编码视频。 Two Pass:两次编码视频，第一次检测视频文件的信息，蝶如此确保输出的视频在确定的码率下质量最大化。这是最常用的设置。 Three Pass:同二次编码垒石，只是多用了一轮编码来确保更佳的文件品质。 命令行：-bitrate, -qp ,-crf ,-pass 1/2/3 量化器: 说明：只有当使用“一次编码量化器模式”的时候可用，需要设置量化器的值，值越高，表示越低的质量越小的文件。可以使用20-30之间的值。动画和卡通或者是一个有着大块相同色彩的区域的场景以及一个比较少细节的画面可以设置一个比较好的量化器值，普通的电影用比较少的值 命令行： -qp n (n为量化器的值) 质量: 说明: 只在“一次编码质量模式“被选用的模式下可用，这是一个值作为编码的质量，越高的值代表越高的质量，越大的文件， 命令行: --crf n　(n为质量的值) B帧: 说明: 选择x264使用的连续b帧的数量，这也是当Adaptive B帧选项被使用时x264可用的b帧的最大数量，b帧虽然体积小，但是当插入的位置正确的话不会降低质量。因此能够提升压缩率。当采用了Adaptive 选项的时候推荐把这个值设置为３以便于给x264程序足够的空间处理。 命令行: --bframes n　（n表示b帧的帧数) 引用帧: 说明: 选择引用帧的最大可用值，引用帧引用了其他的帧(比如当两个帧非常相似时)，引用帧多的话会提升质量，但是会减慢编码速度。对于一般的视频内容，设置它为 ３到５是一个比较不错的选择，对于有着大量重复内容的视频来说（比如动画）可以把它设置为８到１０，如果使用了大量的引用帧，那么应该使用Mixed References选项，以便于允许x265更好的控制编码 Command Line: --ref n (n表示引用帧的帧数) 循环过滤: 说明:也 被称作“去块效应滤镜”，需要紧跟着Alpha和Beta设置，H.264同之前的编码器的一个根本性的区别就是它总是允许过度的artifacts存 在，这样的处理有很大的争议，由于块效应（当视频在地码率下看起来像一系列不同的色块堆积而成的）和artifacts被人的视觉系统作为画面细节对待， 移除它们会让人觉得视觉细节丢失了，虽然实际的效果正好相反（越少artifacts会让人觉得有越多的“实际”细节），这是一个有趣的讨论题目，在这篇 文章中有详细的讨论：DeathTheSheep's x264 guide. 命令行: --nf (禁用循环过滤) Alpha/Beta: 说明:这 个选项控制循环过滤。Alpha也作为Strength，Beta也作为Threshold，alpha决定去块效应的强度，beta控制x264判定某 物是否是块。越高的值意味着x264把越多的东西作为块，例如，一个很高的beta值和一个很高的alpha值将判定过多的块（即使它们并非 artifacts）并且将允许更多此过滤来除去它们，这以为着图像会丢失很多细节。这两个值都可以是正负的。推荐把它们都设置为0，除非你发现视频的质 量实在让人无法接受。否则不要调整，而且即使调整也不要低于－2或高于3。 命令行: --filter
x264 Options: B-Frames Direct Mode: Description: This option when selected can improve compression efficiency. Disabled by default, Auto seems to be the most common value, with Spatial being used occasionally. Available Options: None Spatial Temporal: least used (at least in Sharktooth's profiles) Auto: most common Command Line: --direct x (where 'x' is 'none', 'spatial', 'temporal' or 'auto') Bias: Description: Sets how much bias x264 should give the usage of B-frames (higher means more use of B-frames). Setting this to 100 is the equivalent of not selecting the "Adaptive" option (see below). A default value of 0 works well. Option only available when at least 1 B-frame has been set. Command Line: --b-bias n (where 'n' is the bias value) Adaptive: Description: Turns on adaptive B-frames, which allows x264 to determine the number of B-frames to use (within the set B-frames limit in the previous section). A default value of On works well. Option only available when at least 1 B-frame has been set. Command Line: --no-b-adapt (disables adaptive B-frames) Pyramid: Description: Turns on B-frame Pyramid option, which allows B-frames to be used as references for other B-frames in prediction. A default value of On (when available) works well. Option only available when at least 2 B-frame has been set. Command Line: --b-pyramid (enables adaptive B-frames) RDO: Description: Turns on/off RDO for B-Frames. Turning it On will improve quality at the expense of encoding speed, but it is almost always worth it. Must have at least 1 B-frame and must have a "Subpixel Motion Estimation" (see "Analysis options" section) of 6 or 7. Command Line: --b-rdo (enables RD based mode decision for B-frames) Weighted Prediction: Description: Turns on weighted prediction for B-frames, which results in improved accuracy and therefore a more efficient encoding. Set it to On in most cases. Option only available when at least 1 B-frame has been set. Command Line: --weightb (enables weighted prediction) Bidirectional M.E.: Description: Turns on bidirectional M.E, which allows predictions based on motion both before and after the B-frames. Set it to On in most cases. Command Line: --bime (enables bidirectional M.E.	x264选项: B帧部分 直接模式: 说明:这个选项可以提升压缩性价比，默认禁用，自动是最常用的选择，偶尔会用到Spatial 可用选项: None Spatial Temporal: 极少使用 Auto: 最常用 命令行: --direct x ('x' 可以是 'none', 'spatial', 'temporal' 或 'auto') Bias: 说明: 设置x264使用多少斜线，越高的值使用越多的b帧，设置这个为100等价于不使用Adaptive选项，默认值是0，这个值能很好的工作，要设置这个选项要求b-frames大于1 命令行: --b-bias n (n为bias的值) Adaptive: 说明: 打开B帧的自适应，将允许x264决定使用b帧的数量（在bias中设置的值会限制这个数量），默认值是开启，只有当B-frame设置大于1的时候有效 命令行: --no-b-adapt (禁用 adaptive B-frames) Pyramid: 说明: 打开b帧金字塔层次选项, 将允许b帧引用其他b帧来预测，默认打开（当可用时），只有当B-frame设置大于2的时候有效 命令行: --b-pyramid (打开b pyramid) RDO: 说明:为b帧打开或者关闭RDO，开启这个选项能提升质量而仅仅减少一点编码速度，这个代价通常是值得的，b-frame必须大于1并且必须有“子像素运动估计” 命令行: --b-rdo (开启b帧的rd基础判断模式) 权重预测: 说明: 打开b帧的权重预测，这将提升精确度，即使编码更具性价比，大多数情况下都开启这个，只有当B-frame设置大于1的时候有效 命令行: --weightb (开启权重预测) 双向M.E.: 说明: 打开双向M.E，这将允许基于这个b帧的前后帧的变化来预测，多数情况都打开它 命令行: --bime (打开双向M.E)
x264 Options: Frame Options Scene Cut: Description: This option sets how x264 determines when a scene change has occurred and hence when a key frame is needed. A higher value will allow x264 to be more sensitive to scene changes. A video that has very few camera movements may require a higher scene cut value, for example. The default value of 40 should work well in most cases, plus or minus 5 for low/high action videos. Command Line: --scenecut n (where 'n' is the scene cut value) CABAC: Description: Stands for Context Adaptive Binary Arithmetic Coding. Improves encoding efficiency at the expense of playback/decoding efficiency. The default option of leaving this setting On is recommended, unless the encoded video is to be played back on devices with limited decoding power (eg. portable devices such as the iPod or high resolution clip playback on the Xbox). Command Line: --no-cabac (disables CABAC) GOP Size (Min/Max): Description: This option sets the minimum and maximum number of frames before a key frame has to be inserted by x264. For example, a minimum setting that is the same as the framerate of the video (eg. 24/25/30) will prevent the encoded video from having two subsequent key frames within a second of each other, which only aims to increase file size without any noticeable quality improvements. Similarly, a maximum setting ensures that a key frame is inserted at least every X number of frames. A video without key frames will have lower quality and there will be problem with seeking (if you try to skip to a part of the video without a key frame, there won't be any video until the next key frame is reached, also known as "seeking lag"). A recommend setting, as with DivX/XviD encoding, is to set this as 10 times the framerate, which equates to 10 seconds of video between key frames (ensures "seeking lag" is at most 10 seconds). Command Line: --keyint m --min-keyint n (where 'm' and 'n' are the max and min GOP size values) x264 Options: Analysis Mixed References: Description: This option allows x264 to have greater control over "Reference Frames" (see "Common options" section). Especially needed if the "Reference Frames" is set to a high value. Command Line: --mixed-refs (enables mixed references) No Fast P Skip: Description: Fast P Skip can improve encoding speed at the expense of a very slight quality drop. Leave this option set to Off (to allow for Fast P Skips) is recommended unless encoding for maximum quality with no regard to encoding time. Command Line: --no-fast-pskip (disables fast P skip) Motion Estimation Method: Description: This option select the way motion is detected by x264. Motion is what compression codecs are all about, tracking differences between scenes to allocate the various frame types and bitrates. Available Options (listed from fastest to slowest, encoding speed wise): Diamond: Only use when maximum encoding speed is required. Hexagon: A good option for when quality is not the most important factor, but still important. Multi Hex: Also known as "Uneven Multi-Hexagon". This is the most common setting, as it is a good trade off between speed and quality. Exhaustive: Slowest and totally unnecessary (it isn't estimation anymore, rather, it's Motion Calculation, pixel by pixel). Command Line: --me x (where 'x' is 'dia', 'hex', 'umh' or 'esa') Subpixel Motion Estimation: Description: Also known as "Partition Decision". A very important option that determines how x264 makes decisions about motion estimation. The options are available from 1 to 7, with 1 being the fastest (lowest quality) and 7 being the slowest (best quality). A setting of 6 is the most common, with 1 or 7 being used in extreme cases (fastest encoding or best quality). A setting of 6 or 7 enables the B-frames RDO option (see "B-Frames options" section). Command Line: --subme n (where 'n' is the estimation value) Trellis RD Quantization: Description: This option when turned on is supposed to improve quality, but at a severe slow down of encoding. The quality improvements are also subjective. Leaving it Off is recommended unless you have a fast computer and using multi-pass encoding. Never turn it on in single pass quantizer mode, as it would lead to unexpected results. Available Options: Disabled: Use this for 1-pass encoding Final MB: Use this for typical 2-pass encoding Always: Use this for maximum quality (slowest speed) Command Line: --trellis n (where 'n' is 0 {disabled}, 1 {Final MB} or 2 {Always})	x264选项：帧选项部分： Scene Cut: 说明: 这个选项决定x264如何判断当场景发生改变的时候是否需要插入关键帧，一个高的值将允许x264对场景变化更加敏感，如果一个视频只有很少的摄像机移动的话就需要更高的值，例如，默认的值40将在绝大多数情况下工作的很好，一般我们只在这个值上增删5左右。 命令行: --scenecut n CABAC: 说明:CABAC表示上下文适应的二进制算术编码。这个选项能够提高编码效率，而只会略微将少编码和解码的效率，默认选项就是打开，我们推荐打开，除非视频回放设备很烂。 命令行: --no-cabac (禁用 CABAC) GOP 大小 (Min/Max): 说明:这个选项设置了x264在每个关键帧前面插入的最大和最小帧数，例如，把最小值设置成和视频帧率一致（比如24/25/30）将防止编码的视频一秒之内有两个连续的关键帧（这种情况只会增加视频的大小却不能增加其质量）。 　 　类似的，最大值确保关键帧至少在每x个帧中能被插入，一个没有关键帧的视频的质量很低而且有寻址问题，（如果你试着去跳过包含关键帧的视频的一部分，那 么你就会直接跳到下一个关键帧处）。推荐的设置和DivX/XviD编码一样，把它设置为帧率的10倍，也就是每十秒一定有一个关键帧（这样确保寻址延迟 最多十秒） 命令行： --keyint m --min-keyint n ( 'm' 和 'n' 分别代表max和min) x264选项： 混合: 说明：这个选项允许x264对引用帧有更好的控制，尤其是当引用帧设置到很高的值的时候更加需要这个参数 命令行: --mixed-refs (开启混合引用) 禁用快速跳过p帧: 说明: 快速跳过p帧能够提升编码速度，而仅仅轻微降低视频质量，把这个选项设置为off能开启快速跳过p帧，我们推荐这样做，除非你更在意编码速度，而不是质量 命令行: --no-fast-pskip (禁用快速跳过p帧) 运动估计方式: 说明: 这个选项设定x264检测运动的方式，运动是视频编码的全部，追踪两个场景中的不同之处，并且分配帧类型和比特率 可用选项(从编码速度最快的排到最慢的)： Diamond:只有当要求最快的编码速度时使用。。 Hexagon:当视频质量不是最重要，但也是一个重要参考因素的时候使用。 Mulit Hex：也被称作“非匀称六边形搜索“这个是最常用的选项。它能够很好的平衡质量与速度， Exhaustive:最慢的并且完全不必要的选项。它搜索所有像素。 命令行: --me x ( 'x' 可以是 'dia', 'hex', 'umh' 或 'esa') 子像素运动估计: 说明: 也被成为分区判断，一个非常重要的选项，以决定x264怎样判断运动估计。值可以从1到7，1是最快但最低质量的方式，7是最慢当最高质量的方式，一般设置为6，1和7一般只有在极端条件下使用。设置为6或7允许B帧RDO选项 命令行: --subme n (n为评估值) RD栅格量化： 说明: 开启这个选项可以提升质量，但是会严重降低编码速度，而且质量提升也是主观的，一般推荐关闭，除非你有一台高速计算机并且使用多次编码，不论如何，绝对不要在一次量化器编码模式下使用它，否则会造成不可预期的结果。 可用选项: Disabled: 只用一次编码的时候使用 Final MB: 一般多次编码的时候用这个 Always: 最大质量模式，也最慢 命令行: --trellis n ( 'n'为 0 代表{disabled}, 1 代表{Final MB} 或 2 代表{Always})
x264 Options: Partitions Partitions: Description: These options determine the partition search types. Generally, you want to enable all of these options whenever possible, as they will improve encoding quality. The "P4x4" option requires the "P8x8" option. Command Line: --analyse x (where 'x' is 'p8x8', 'p4x4' {requires 'p8x8'}, 'b8x8', 'i8x8', 'i4x4' , 'none' or 'all') 8x8 DCT: Description: This option has been separated from the above because it has a different command line flag. This option is required if you want to select the "I8x8" option above. Command Line: --8x8dct (enables 8x8 DCT) Show progress indicator: Description: This option when enabled shows you how many frames have been encoded and how many frames are left. Best to leave it On if you don't want to sit there guessing how much is still left to do. Command Line: --progress (enables progress indicator) Disable PSNR computation: Description: This option disables noise reduction calculations. It is recommended that you leave this option On (to diable PSNR). Command Line: --no-psnr (disables PSNR computation) Threads: Description: This sets the number of CPU threads to use in encoding. An Intel Pentium processor with HyperThreading counts as 2 threads. Dual Core processors are also 2 threads. Dual core processor with HyperThreading (eg. Intel Extreme Edition) will have 4 threads. Command Line: --threads n (where 'n' is the number of threads) Output Type: Description: Selectable within the x264 command line by the output filename. A file with extension .264 will equal the "RAW" setting. Command Line: --output x (where 'x' is the output filename with the extension being .264, .mp4 or .mkv to indicate output type)	x264选项： 分区 分区: 说明: 这个选项决定分区搜索方式，你会希望把它设置为all，这样能提升编码质量，P4x4选项要求开启p8x8， p4x4只在subq >= 5，并且分辨率低时才推荐使用。 命令行: --analyse x ( 'x' 是 'p8x8', 'p4x4' {需要 'p8x8'}, 'b8x8', 'i8x8', 'i4x4' , 'none' 或 'all') 8x8 DCT: 说明: 这个选项被从上面单独分离出来是因为它的命令标志不同于上面的，这个选项要求你开启i8x8 命令行: --8x8dct (开启 8x8 DCT) 禁用PSNR 计算: 说明: 这个选项禁用降噪运算，推荐开启它以禁用降噪运算 命令行: --no-psnr (禁用 PSNR 运算) Threads: 说明: 这个选项设置cpu编码线程数。支持intel的HT技术的cpu每个核心被视为2个线程，双核处理器也是2个线程，双核ht的cpu就是4线程了。 命令行: --threads n ( 'n'表示线程数)

说说多种字符编码的统一处理

　　学校目前有几台阵列，几台linux服务器，几台windows服务器，还有一台FreeBSD服务器，各种服务器之间存储文件使用的编码是不一样的，而且这些服务器上挂的不同站点使用的字符编码也是不一样的。早期没有按照统一的标准制作，结果现在酿下的苦果就是我们这些继承人在处理问题的时候常常被编码问题所困扰。也许你也遇到了这种情况。最近正好搜了一些资料。了解了一些东西。共享出来。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
预备知识：

1. 字符集和编码

　　在Linux上经常使用的字符集是ISO 8859系列的字符集．它包含了10个 多语言的单字节编码字符集．它们分别是，

字符集	涵盖语言
ISO 8859-1（Latin1）	拉丁一字符集， 包含绝大多数的欧洲语言， 例如French（fr）， Spanish （es）， Catalan （ca）， Basque （eu）， Portuguese （pt）， Italian （it）， Albanian （sq）， Rhaeto-Romanic （rm）， Dutch （nl）， German （de）， Danish （da）， Swedish （sv）， Norwegian （no）， Finnish （fi）， Faroese （fo）， Icelandic （is）， Irish （ga）， Scottish （gd）， English （en）， Afrikaans （af） 和 Swahili （sw）．影响了美洲， 澳洲和非洲．
ISO 8859-2（Latin2）	拉丁二字符集， 包含了中欧和东欧的语言：Czech （cs）， Hungarian （hu）， Polish （pl）， Romanian （ro）， Croatian （hr）， Slovak （sk）， Slovenian （sl）， Sorbian．
ISO 8859-3（Latin3）	拉丁三字符集， 包括： Esperanto （eo） and Maltese （mt）
ISO 8859-4（Latin4）	拉丁四字符集， 包括： Estonian （et）， 巴尔地克 Latvian （lv） 和 Lithuanian （lt）， Greenlandic （kl） ， Lappish．
ISO 8859-5（西里尔语）	Bulgarian （bg）， Byelorussian （be）， Macedonian （mk）， Russian （ru）， Serbian （sr）
ISO 8859-6（阿拉伯语）	阿拉伯语（ar）
ISO 8859-7（希腊语）	希腊语（el）
ISO 8859-8（希伯来语）	Hebrew （iw） 和Yiddish （ji）
ISO 8859-9（Latin5）	重排了Latin1， 用土耳其语的几个字母做了替换
ISO 8859-9（Latin6）	重排了Latin4， 去掉了某些符号， 增加了Inuit等
ISO 8859-11（泰国语）	泰国语（th）
ISO 8859-12	Celtic
ISO 8859-13（Latin7）	Baltic Rim 和 Lativian（lv）
ISO 8859-14（Latin8）	Gaelic 和 Welsh （cy）
ISO 8859-15（Latin9）	Latin1的变种， 修改了某些字母

　　双字节字符集主要包含中文，日文和韩文．它由前导字节（Lead Byte） 和尾部字节（Trail Byte）构成， 由于一个字符采用了两个字节， 在软件的 国际化方面又增加了一些麻烦， 比如在显示上， 光标的位置不能位于汉字 之间， 删除和移动时必须是整字操作等， 在输入上， 一般需要预编辑服务器 才能输入汉字． 下表列出了中日韩语言编码的有关信息：

语言	字符集	代码页	前导字节范围	尾部字节范围
简体中文	GB2312-1980	CP936	0xA1-0xF7	0xA1-0xFE
	GBK	无	0x81-0xFE	0x40-0x7E， 0x80-0xFE
中文繁体	BIG-5	CP950	0x81-0xFE	0x40-0x7E， 0xA1-0xFE
日文	Shift-JIS	CP932	0x81-0x9F， 0xE0-0xFC	0x40-0xFC（0x7F除外）
韩文	KSC-5601-1987	CP949	0x81-0xFE	0x41-0x5A，0x61-0x7A，0x81-0xFE
	KSC-5601-1992	CP1361	0x84-0xD3 0xD8 0xD90-0xDE 0xE0-0xF9 0x41，0xFE	0x41-0x7E 0x81-0xFE 0x31-0x7E

　　信息产业部和国家质量技术监督局联合制定了两项中文信息处理基础性国家标准，为解决偏、生汉字的输入提供了方案。其中GB18030- 2000《信息技术和信息交换用汉字编码字符集、基本集的扩充》，为强制性 国家标准．它收录了2.7万多个汉字，总编码空间超过150万个码位，为彻底 解决邮政、户政、金融、 地理信息系统等迫切需要的人名、地名用字问题 提供了解决方案，也为汉字研究、古籍整理等领域提供了统一的信息平台基础。 这项标准还同时收录了藏文、蒙文、维吾尔文等主要的少数民族文字．字符 集编码范围是：

字节数	编码空间	码位数目
单字节	0x00-0x80	129
双字节	第一字节：0x81-0xFE 第二字节：0x40-0x7E，0x80-0xFE	23940
四字节	四字节范围分别是： 0x80-0xFE，0x30-0x39，0x81-0xFE，0x30-0x39	1587600

　　香港特别行政区也对Big5编码提出了"香港增补字符集"， 其目的，是 收纳香港特区政府及市民在中文电子通讯中有需要使用的字符，来补充目前 大五码和ISO10646编码标准内并未包含的字符，以作为一个通用的中文界面， 方便大家能准确地以中文进行电子通讯。香港增补字符集有两套编码方案， 一套适用於大五码系统，另一套适用於ISO10646平台。香港增补字符集的大 五码版本，实际上是政府通用字库的增订版。ISO10646国际编码标准目前并 未包含香港增补字符集内的所有字符。目前尚未收纳在ISO10646内的香港增 补字符集字符，均已提交国际标准化组织管辖下的表意文字小组，以考虑是 否纳入ISO10646日后的新增版本内．

2. 多字节字符（Multibyte）和宽字符（WideChar）的使用

　　我们平时见到的以文本方式存在的字符都是多字节字符， 它主要用于文件存储和网络上的以流（Stream）的方式传输．一个GB编码的汉字需要两个字节．多字节字符的缺点是在中文处理上不方便， 比如汉字的删除和光标的移动都会有半汉字问题．为了文本处理的方便，在内部操作上通常是把汉字 与英文的混和字符串先转换成等宽度的字符串， 即宽字符，为软件的内部处理 提供方便．

　glibc2.1.x中多字节字符串和宽字符串的转换有时有问题．在X下还可以 使用另外一种方式完成转换， 即使用XmbTextListToTextProperty（）和 XwcTextPropertyToTextList（） 联合完成转换．

3. Unicode

　　目前所使用的Unicode 是一种16位字宽的字符编码， 它由非赢利的计算机 组织Unicode研讨会维护和改进．它起源于Xerox和Apple之间的合作研究．几 个公司组成了一个非正式的论坛， 接着IBM， Microsoft等公司迅速加入． Unicode研讨会在1990年发表了Unicode标准版本1， 同时国际标准化组织完成 了一种类似的编码----ISO 10646．因为没有必要存在两套标准， 所以Unicode 研讨会和国际标准化组织在1991到1992合二为一． 1994年， 中国和日本开始了基于ISO10646上的国家标准进行工作．现在， Unicode 开始用在许多产品中．

　　Unicode包含了当今计算机领域中广泛使用的所由字符， 如世界上大部分 的书面语言， 印刷字符， 数字和技术符号， 地理图形和标点符号．由于Unicode 的一致性， 它在大多数情况下都可能简化软件的国际化过程．它取消了处理多种代码页的必要， 并且由于是16位编码， 因此由双字节字符集所引起的额外处理也不必要了．

　　但是， Unicode作为一种编码也有它的缺陷， 比如编码的位置与排序无关， 所以使软件支持Unicode仅仅是国际化的第一步， 实际情况中还需要与语言相关的信息和规则．所以Unicode一般作为程序的内部处理编码， 必须提供与其它编码的双向转换表．

　　最后需要说明的是，虽然使用Unicode会使普通的英文文本大两倍， 但是使用Unicode的整个系统却不会增加太大，因为系统存放的文件大部分是二进制文件格式， 同时， 使用针对Unicode的压缩方式，可以把文件压缩成和使用对应的8位正文一样大小。

-----------------------------------------------------------------------------　　

UCS 和 ISO 10646?

国际标准 ISO 10646 定义了 通用字符集 (Universal Character Set, UCS). UCS 是所有其他字符集标准的一个超集. 它保证与其他字符集是双向兼容的. 就是说, 如果你将任何文本字符串翻译到 UCS格式, 然后再翻译回原编码, 你不会丢失任何信息.

UCS 包含了用于表达所有已知语言的字符. 不仅包括拉丁语,希腊语, 斯拉夫语,希伯来语,阿拉伯语,亚美尼亚语和乔治亚语的描述, 还包括中文, 日文和韩文这样的象形文字, 以及 平假名, 片假名, 孟加拉语, 旁遮普语果鲁穆奇字符(Gurmukhi), 泰米尔语, 印.埃纳德语(Kannada), Malayalam, 泰国语, 老挝语, 汉语拼音(Bopomofo), Hangul, Devangari, Gujarati, Oriya, Telugu 以及其他数也数不清的语. 对于还没有加入的语言, 由于正在研究怎样在计算机中最好地编码它们, 因而最终它们都将被加入. 这些语言包括 Tibetian, 高棉语, Runic(古代北欧文字), 埃塞俄比亚语, 其他象形文字, 以及各种各样的印-欧语系的语言, 还包括挑选出来的艺术语言比如 Tengwar, Cirth 和 克林贡语(Klingon). UCS 还包括大量的图形的, 印刷用的, 数学用的和科学用的符号, 包括所有由 TeX, Postscript, MS-DOS，MS-Windows, Macintosh, OCR 字体, 以及许多其他字处理和出版系统提供的字符.

ISO 10646 定义了一个 31 位的字符集. 然而, 在这巨大的编码空间中, 迄今为止只分配了前 65534 个码位 (0x0000 到 0xFFFD). 这个 UCS 的 16位子集称为 基本多语言面 (Basic Multilingual Plane, BMP). 将被编码在 16 位 BMP 以外的字符都属于非常特殊的字符(比如象形文字), 且只有专家在历史和科学领域里才会用到它们. 按当前的计划, 将来也许再也不会有字符被分配到从 0x000000 到 0x10FFFF 这个覆盖了超过 100 万个潜在的未来字符的 21 位的编码空间以外去了. ISO 10646-1 标准第一次发表于 1993 年, 定义了字符集与 BMP 中内容的架构. 定义 BMP 以外的字符编码的第二部分 ISO 10646-2 正在准备中, 但也许要过好几年才能完成. 新的字符仍源源不断地加入到 BMP 中, 但已经存在的字符是稳定的且不会再改变了.

UCS 不仅给每个字符分配一个代码, 而且赋予了一个正式的名字. 表示一个 UCS 或 Unicode 值的十六进制数, 通常在前面加上 "U+", 就象 U+0041 代表字符"拉丁大写字母A". UCS 字符 U+0000 到 U+007F 与 US-ASCII(ISO 646) 是一致的, U+0000 到 U+00FF 与 ISO 8859-1(Latin-1) 也是一致的. 从 U+E000 到 U+F8FF, 已经 BMP 以外的大范围的编码是为私用保留的.

什么是 Unicode?

历史上, 有两个独立的, 创立单一字符集的尝试. 一个是国际标准化组织(ISO)的 ISO 10646 项目, 另一个是由(一开始大多是美国的)多语言软件制造商组成的协会组织的 Unicode 项目. 幸运的是, 1991年前后, 两个项目的参与者都认识到, 世界不需要两个不同的单一字符集. 它们合并双方的工作成果, 并为创立一个单一编码表而协同工作. 两个项目仍都存在并独立地公布各自的标准, 但 Unicode 协会和 ISO/IEC JTC1/SC2 都同意保持 Unicode 和 ISO 10646 标准的码表兼容, 并紧密地共同调整任何未来的扩展.

那么 Unicode 和 ISO 10646 不同在什么地方?

　　Unicode 协会公布的 Unicode 标准 严密地包含了 ISO 10646-1 实现级别3的基本多语言面. 在两个标准里所有的字符都在相同的位置并且有相同的名字.

　　Unicode 标准额外定义了许多与字符有关的语义符号学, 一般而言是对于实现高质量的印刷出版系统的更好的参考. Unicode 详细说明了绘制某些语言(比如阿拉伯语)表达形式的算法, 处理双向文字(比如拉丁与希伯来文混合文字)的算法和排序与字符串比较所需的算法, 以及其他许多东西.

　　另一方面, ISO 10646 标准, 就象广为人知的 ISO 8859 标准一样, 只不过是一个简单的字符集表. 它指定了一些与标准有关的术语, 定义了一些编码的别名, 并包括了规范说明, 指定了怎样使用 UCS 连接其他 ISO 标准的实现, 比如 ISO 6429 和 ISO 2022. 还有一些与 ISO 紧密相关的, 比如 ISO 14651 是关于 UCS 字符串排序的.

　　考虑到 Unicode 标准有一个易记的名字, 且在任何好的书店里的 Addison-Wesley 里有, 只花费 ISO 版本的一小部分, 且包括更多的辅助信息, 因而它成为使用广泛得多的参考也就不足为奇了. 然而, 一般认为, 用于打印 ISO 10646-1 标准的字体在某些方面的质量要高于用于打印 Unicode 2.0的. 专业字体设计者总是被建议说要两个标准都实现, 但一些提供的样例字形有显著的区别. ISO 10646-1 标准同样使用四种不同的风格变体来显示表意文字如中文, 日文和韩文 (CJK), 而 Unicode 2.0 的表里只有中文的变体. 这导致了普遍的认为 Unicode 对日本用户来说是不可接收的传说, 尽管是错误的.

什么是 UTF-8?

首先 UCS 和 Unicode 只是分配整数给字符的编码表. 现在存在好几种将一串字符表示为一串字节的方法. 最显而易见的两种方法是将 Unicode 文本存储为 2 个 或 4 个字节序列的串. 这两种方法的正式名称分别为 UCS-2 和 UCS-4. 除非另外指定, 否则大多数的字节都是这样的(Bigendian convention). 将一个 ASCII 或 Latin-1 的文件转换成 UCS-2 只需简单地在每个 ASCII 字节前插入 0x00. 如果要转换成 UCS-4, 则必须在每个 ASCII 字节前插入三个 0x00.

在 Unix 下使用 UCS-2 (或 UCS-4) 会导致非常严重的问题. 用这些编码的字符串会包含一些特殊的字符, 比如 '\0' 或 '/', 它们在 文件名和其他 C 库函数参数里都有特别的含义. 另外, 大多数使用 ASCII 文件的 UNIX 下的工具, 如果不进行重大修改是无法读取 16 位的字符的. 基于这些原因, 在文件名, 文本文件, 环境变量等地方, UCS-2 不适合作为 Unicode 的外部编码.

在 ISO 10646-1 Annex R 和 RFC 2279 里定义的 UTF-8 编码没有这些问题. 它是在 Unix 风格的操作系统下使用 Unicode 的明显的方法.

UTF-8 有一下特性:

• UCS 字符 U+0000 到 U+007F (ASCII) 被编码为字节 0x00 到 0x7F (ASCII 兼容). 这意味着只包含 7 位 ASCII 字符的文件在 ASCII 和 UTF-8 两种编码方式下是一样的.
• 所有 >U+007F 的 UCS 字符被编码为一个多个字节的串, 每个字节都有标记位集. 因此, ASCII 字节 (0x00-0x7F) 不可能作为任何其他字符的一部分.
• 表示非 ASCII 字符的多字节串的第一个字节总是在 0xC0 到 0xFD 的范围里, 并指出这个字符包含多少个字节. 多字节串的其余字节都在 0x80 到 0xBF 范围里. 这使得重新同步非常容易, 并使编码无国界, 且很少受丢失字节的影响.
• 可以编入所有可能的 2³¹个 UCS 代码
• UTF-8 编码字符理论上可以最多到 6 个字节长, 然而 16 位 BMP 字符最多只用到 3 字节长.
• Bigendian UCS-4 字节串的排列顺序是预定的.
• 字节 0xFE 和 0xFF 在 UTF-8 编码中从未用到.

下列字节串用来表示一个字符. 用到哪个串取决于该字符在 Unicode 中的序号.

U-00000000 - U-0000007F:	0xxxxxxx
U-00000080 - U-000007FF:	110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF:	1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF:	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF:	111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF:	1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

xxx 的位置由字符编码数的二进制表示的位填入. 越靠右的 x 具有越少的特殊意义. 只用最短的那个足够表达一个字符编码数的多字节串. 注意在多字节串中, 第一个字节的开头"1"的数目就是整个串中字节的数目.

例如: Unicode 字符 U+00A9 = 1010 1001 (版权符号) 在 UTF-8 里的编码为:

11000010 10101001 = 0xC2 0xA9

而字符 U+2260 = 0010 0010 0110 0000 (不等于) 编码为:

11100010 10001001 10100000 = 0xE2 0x89 0xA0

这种编码的官方名字拼写为 UTF-8, 其中 UTF 代表 UCS Transformation Format. 请勿在任何文档中用其他名字 (比如 utf8 或 UTF_8) 来表示 UTF-8, 当然除非你指的是一个变量名而不是这种编码本身.

//你看不懂这一段的话请看utf-8官方解释：

What is UTF-8?

UTF-8 stands for Unicode Transformation Format-8. It is an octet (8-bit) lossless encoding of Unicode characters.

UTF-8 encodes each Unicode character as a variable number of 1 to 4 octets, where the number of octets depends on the integer value assigned to the Unicode character. It is an efficient encoding of Unicode documents that use mostly US-ASCII characters because it represents each character in the range U+0000 through U+007F as a single octet. UTF-8 is the default encoding for XML.

所以，其实说白了。unicode仅仅是表示了字符的编码表，但是没有指定如何编码，而UTF-8是一种unicode的八字节编码格式。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

好了，有了预备知识之后，就可以去了解如何解决这种问题了。给了我最大启发的就是下面这两篇文章了：


　　设想一下如何设计一个全球的论坛系统：可以让中文和日文的用户都可以方便的浏览发表呢？在数据中间处理阶段应该以那种字符集存储呢？答案很简 单：UniCode。以前很多文章都有关于如何设计一个国际化界面的介绍，只是应用的本地化界面输出，但很少提及数据在中间处理过程中如何适应国际化。

　　输入和存储阶段就用UniCode方式进行处理和存储，以方便应用以后的国际化。GOOGLE的设计就是一个非常好的国际化应用榜样，我以GOOGLE搜索引擎的国际化支持为例说明如何实现国际化应用的设计。

GOOGLE用户经常有这样的感觉：

1. 为什么我第一次去GOOGLE，出现的就是中文的界面？
2. 为什么在所有网站中查中文：有时候还会匹配到日文网站的结果？比如：就以"google 秘密"这个查询为例：我们在输入框输入"google 秘密"
   http://www.google.com/search?hl=zh-CN&newwindow=1&q=google+%C3%D8%C3%DC&btnG=Google%CB%D1%CB%F7&lr=

首先我将GOOGLE对查询的处理流程简单的说明如下：

1. 客户端浏览器输入；
2. 查询字符串按客户端系统编码方式（GBK）转换成字节流，并URL Encode后传给GOOGLE；
3. GOOLGE将输入的字符串URL Decode后，按照客户端的系统编码方式将这个字符串（字节串）解码成UniCode
4. 查询过程，完全是基于UniCode的匹配过程，比如对于“中文”这2个字在简体繁体中文和日文里都有，因此无论是何种语言的页面包含这2个字的页面都能匹配上。
5. 结果集输出：将查询结果集的内容（UNICODE）按客户端系统编码方式（GBK）“编码”成的字节流，返回给浏览器

具体说明：

• GOOGLE如何识别出浏览器使用的“界面语言”：GOOGLE获得这个查询字符串的同时，一般会根据hl=zh-CN这个参数， 知道了客户端使用的字符集编码方式，如果用户第一次访问：GOOGLE会根据浏览器的发送的请求中包含的Accept language: zh_cn这个头信息来判别，这就是为什么现在很多用户第一次去GOOGLE的时候它就能自动识别出来的原因。这个参数在之后的查询和翻页过程中通过 cookie保存，并通过get方式一直传递给GOOGLE（因此你也可以使用使用偏好设置界面语言），从而可靠地识别出客户端的编码方式。
• GOOGLE如何查询：也许从URL上你可以看到：传过去的“秘密”这个查询实际上是%C3%D8%C3%DC=>"秘密"这2个字按GBK（WINDOWS客户端缺省的编码方式）编码方式的4个字节然后再URLEncode后的形式（关于中文编码方式请参考：汉字的编码方式），GOOGLE 将查询字符串按这个编码方式解码并转成UniCode，然后用这个UniCode编码方式的字符串进行内部的查询操作。而任何语言的页面都是先转换成 UniCode后存储在GOOGLE的数据索引库里的。在UniCode中日文和中文写法一样的字，用的是同样的编码。因此，如果你没有指定语言过滤的话，日文网页的结果就首先被命中了；因此，对于中文客户端的查询：如果相应字符在UniCode中和繁体，日文映射的字一样，就可以匹配到相应的日文网页，繁体中文网页...，GOOGLE的查询结果也首先是UniCode的，最后将UniCode结果按照客户端的编码方式转换成字节流，返回到客户端。

从以上的分析中我们可以看出：UniCode非常漂亮的解决了应用的国际化问题。对于应用前端来说，剩下的工作就是根据本地编码环境进行本地化的过程了。

1. 数据从输入的开始，就全部先转换成UniCode，然后再进行处理，并按照UniCode方式集中存储(UniCode inside)
2. 数据输出过程中，只是在最后输出到客户端的时候，按照客户端的本地化设置将UniCode数据转换成本地字符集，并配以相应语言/字符的界面(Localization outside)

　　如果应用的开发只是满足于在国内市场自给自足，“汉化”的思路的大量出现是很自然的。但要是把“汉化”比作UCDOS和RichWin的话，那么这种汉化方式迟早要被内核汉化的WIN95淘汰的。毕竟核心级别对国际化的支持才是一个真正简化前端应用设计、通用的解决方案。Microsoft和Sun等国际化大公司的产品从一开始就是为全球市场设计的，因此对国际化的支持一致非常重视。相比之下国内软件行业对相应国际标准显然重视不足，也很少积极地参 与相关标准制定。
　　转自：http://www.chedong.com/tech/unicode_java.html#google

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
据说Google修改过一次它的编码处理方式：

　　GOOGLE的国际化做得很好。我们知道，你在www.google.com里面输入一个检索词，然后便会生成一个HTTP的GET请求。这个请求一般有几个参数，以前的http://www.google.com/search?q=%s就是最简单的一个，%s就是用来代替你输入的值的。但GOOGLE是一个面对全球服务的站点。它收到请求后会解释q的值。如果大家写过JSP或者JAVA程序，就会经 常陪到getParameter得到的中文是乱码。这里面就是一个编码问题。浏览器的地址栏内的URL，一切非正常字符（A- z,0-9,:,.等)都会进行编码（Encode，一个%号，然后加上它的ASCII内码，一个中文一般会编码成为两个，如“中 文”两个字会编码为：%D6%D0%CE%C4，然后程序收到请求后会进行相应的解码。
　　GOOGLE近期改进了它的编码方案，即是在生成URL的时候，由客户端按照指定的编码进行Encode,查看 www.google.com主页的源文件，你会发觉encodeURIComponent这个Javascript的函数。默认情况下，会用Javascript的 功能，把输入的检索词进行UTF-8编码，“中文”两个字就会编码成：%E4%B8%AD%E6%96%87，一共六个字节。这时如果还是按照四个字节进行解码，就会出错，也就是乱码。可以对比默认情况下的编码，是四个字节。具体关于字符编码的内容，就不在这里讨论。

再来看Google配置检索式的时候的几个参数：

[*]ACTION地址： http://www.google.com/search?
[*]q 检索的词，即你在输入框内输入的内容，会进行URL Encode编码
[*]lr 检索范围。如“lr=”表示检索所有的网站，lr=lang_zh-CN表示检索中文简体，lr=lang_zh-CN|lang_zh-TW表示 中文网页（简繁）
[*]ie 指示浏览器URL的编码，Google会将q的值按照这个编码来进行解码（这个最重要）
[*]oe Outlook的编码？？（这个参数暂不清楚什么意思，目前对检索没有影响，直接给一个值，或者不要也行


这时就可以按需进行组合了，名和值之前为“=”，每个之间以“&”进行连接
如：http://www.google.com/search?q=%s&ie=GB2312&lr=lang_zh-CN
意思为：浏览器的URL编码为GB2312，检索范围为“中文网页”

http://www.google.com/search?q=%s&ie=UTF-8&lr=lang_zh-CN
意思为：浏览器的URL编码为UTF-8，检索范围为“简体中文网页”

如果是检索图像，把search换成images就行了，其它不变。
http://images.google.com/images?q=%s&ie=UTF-8&lr=lang_zh-CN

//关于这篇文章的内容，我们其实可以测试一下就能了解了。在google搜索两个中文，之后添加一个&ie=gb2312结果就会出现乱码。


================================================================================待续。。。

NFS的配置和使用

　　一般来说，在linux/unix下，如果需要挂载网络上另外一台服务器的目录的话nfs是最方便且容易实现的一种方法了。
　　目前NFS已经到了V4版本了。
　　自从 1984 年推出以来，网络文件系统 (NFS) 已成为网络文件共享的标准，尤其是在UNIX® 和 Linux® 社区中。过去 20 年以来，NFS 协议已慢慢适应新需求和市场变化。
　　
　　下面开始配置：

首先。
　　需要作为nfs服务器的主机需要开启nfs服务，并且在/etc/exports中列出允许共享的目录。开启服务只需要
/etc/init.d/nfs start
就可以，但是为了以后自动启动，可以使用chkconfig命令来配置服务的启动。
chkconfig --level 345 nfs on
修改/etc/exports
修改的规则是每个共享目录一行，比如
/home/test 192.168.0.11(ro,sync, no_root_squash) 192.168.0.12(rw,sync)
这里的意思就是把/home/test目录分别共享给192.168.0.11和192.168.0.12，前者只读后者读写权限。
详细的参数介绍：

rw： 可读写的权限；
ro： 只读的权限；
no_root_squash： 登入到NFS主机的用户如果是ROOT用户，他就拥有ROOT的权限
root_squash： root用户的所有请求映射成如anonymous用户一样的权限（默认）
all_squash： 不管登陆NFS主机的用户是什么都会被重新设定为nobody。适合公用目录。
no_all_squash： 保留共享文件的UID和GID（默认）
anonuid： 将登入NFS主机的用户都设定成指定的user id,此ID必须存在于/etc/passwd中。
anongid： 同 anonuid ，但是变成 group ID 就是了！
sync： 资料同步写入存储器中。
async： 资料会先暂时存放在内存中，不会直接写入硬盘。
secure： NFS通过1024以下的安全TCP/IP端口发送
insecure： NFS通过1024以上的端口发送
wdelay： 如果多个用户要写入NFS目录，则归组写入（默认）
no_wdelay： 如果多个用户要写入NFS目录，则立即写入，当使用async时，无需此设置。
hide： 在NFS共享目录中不共享其子目录
no_hide： 共享NFS目录的子目录
subtree_check： 如果共享/usr/bin之类的子目录时，强制NFS检查父目录的权限（默认）
no_subtree_check： 和上面相对，不检查父目录权限

每次修改/etc/exports目录之后需要让其生效可以重启nfs服务，或者使用exportfs命令
参数解释：

-a ：全部mount或者unmount /etc/exports中的内容
-r ：重新mount /etc/exports中分享出来的目录
-u ：umount 目录
-v ：在 export 的时候，将详细的信息输出到屏幕上。

－－－－－－－－－－－－－－－－－－－－－－－
客户机：
　　在客户机要挂载nfs分区使用的是
mount -t nfs 10.1.1.11:/home/test /mnt
其中10.1.1.11:/home/test为服务器端ip和共享的目录，/mnt为本机要挂载的目录

-----------------------------------------
2008-11-17更新：
开机自动启动：
因为我不需要automount的特性，所以直接修改/etc/vfstab
说明：
格式：
device to mount device to fsck mount point FS type fsck pass mount at boot mount options

* device to mount 指定远程服务器名和共享路径。远程服务器名和共享路径用冒号分开。
* device to fsck 这个是空的。从来不从客户机进行文件检测。
* mount point 指定本地的mount点。这个目录必须是已经存在的。
* FS type 对于nfs资源系统来说，当然是nfs了。
* fsck pass 这个也是空的。表示不从客户机进行文件系统检测。
* mount at boot 选择yes or no，yes就是启动时自动安装。
* mount options 用逗号分隔的mount命令的列表。

例如：
# vi /etc/vfstab 添加：
peng:/export/home/peng/games - /export/home/games nfs - yes soft,bg

表示开机自动把远程主机peng的/export/home/peng/games目录自动挂到本机的/export/home/games下。soft选项是目录不能安装，产生一个错误。bg选项，系统启动过程中安装在后台。

简单的ssh隧道代理的方法

服务器端：
　　/etc/ssh/sshd_config中把AllowTcpForwarding后面的no改成yes，就是开启tcp转发啦。

客户端：
　　ubuntu下直接用命令
ssh -ND 10000 -p 2222 username@remotehost
　　意思就是用-D指定本地端口-N就是不指定远程命令，直接把ssh后台运行用以端口转发。
　　-p指定ssh服务器的端口，如果默认的话可以不用这个参数。
　　执行完命令等待输入口令以后就可以了。接下来只要在需要代理的地方填上localhost 10000就可以通过remotehost来代理上网了。。。