Topics

 

自制关卡的视频录像没有了

内容已经改罗~~

该帖由 伯俞  2004年11月20日,  05:00:23 pm 发表
========

動作:
5>4>3>2>1>6　
幾乎是照著順序排下來~~5代的動作是最佳的!比4代還要好!6代---->特例!!勞菈變成\"老\"菈了!(還是因為退隱古墓太久...便遲鈍了!?~~戶樞不蠹...)

畫面:
6>4>5>3>2>1　
順著時代在進步嘛!4和5代順序相反是因為五代沒啥\"古蹟\"&秀麗的風光,而且五代竟然沒有支援凹凸貼圖!(4帶有的5代竟然沒有....怪怪!)6代的夜總會那個地方我很喜歡,因為那光影好美!而4代,我喜歡前期的風光明媚,但是不太喜歡後期的陰暗....,5代~~沒啥特別喜歡的場景!3代我喜歡內華達.南太平洋小島.倫敦.南極洲的第一關的\"一開始\"的那種場景,2代第一關不錯!西藏的也很好,Lara\' Home訓練關我也很喜歡,1代印加那關是我最最喜歡的場景!!我每次作關卡最喜歡用印加的貼圖了

謎題:
4>3>5>2>1>6　
4代的謎題,可謂之經典!三代的倫敦那關也花了我不少的時間，五代則是第四大關！2代沉船那關,我也費了不少時間(還有一個原因是因為當時感覺好恐怖...)其他則是以我個人在玩的時候,想了多久為準~~6代...一星期就破了


敵人AI:
4>5>3>2>1>6
4代還要用瞄準器去爆骷髏的頭,五代要多VC大樓的警衛(但是為啥比不上4代呢?原因是因為前面2大關的敵人都太簡單了!我從沒用過其他武器去打!-->害我一直到最有網路後才知道那關還有其他武器!!完全忽略了他們!)2代要運用戰術!-->不然會浪費很多子彈....=.=3代有了沙漠之鷹這個近乎\"無敵\"的武器之後...就沒啥緊張的戰鬥了,哈哈!6代的則是那個紅鬼以及波阿斯,1代....以前玩的時候超怕暴龍和亞特蘭提斯的敵人,但是自從了解其攻破發後...就覺得暴龍好簡單喔!(亞特蘭提斯的人造生物我還在研究有啥較好的攻擊方法....我還是很怕他們!-->最大隻的\"嬰兒\"除外!我以前最愛看她把Lara抓起來的樣子了!天真無邪,竟把Lara當娃娃摔,摔完後發現不動了就丟到一旁....別罵我阿!我也不願意,但是真的很好笑!這個動作充分的表現出嬰兒對新奇\"東西\"的好奇!設計的真妙!)

音樂:
1=3=6>4=2>5　
1代的主題音樂實在是太好聽了!不過我說的是在SS&PS上的配樂!PC版的只有音效...風聲不算是音樂吧!?3代的則是有一種神秘感!6代的....有一種沒落的感覺!很適合6代的遭遇.....!?尤其是中間有著3代旋律的地方!是我最喜歡的地方!4代有一些不錯聽,例如在Tempie Of Isis那關在Isis雕像附近拿聖甲蟲時的那個!或著是在末代圖書館的七芒星火龍謎題時出現的音樂,都是我很喜歡的!2代主題曲不錯,而再騎雪橇車時的配樂也是很好聽,最不喜歡的就是5代的了!怎麼都是搖滾樂!?一點古墓風格都沒有!我還是比較喜歡Nathan McCree 作的音樂!

選單介面:
1=2=3>4=5>6　
就是按了ESC時出現的那個選單,以及剛開始的遊戲選單,我比較喜歡以前1~3的旋轉選單,4代大概是因為有了\"組合\"的功能,所以不太適合旋轉選單,6代的選單蠻漂亮的,但是挺麻煩的-->離開遊戲要按4次!!(1按esc去選離開遊戲2按任何一個鍵進入3選\"離開遊戲\"4關掉Launher選單.....唉~~)

\"死亡方式\":
6>1>4=5>3=2
大家一定覺得這是一個奇怪的評價吧!我之所以會做這個評價,是因為其實我第一次玩古墓奇兵時,看過太多死法了!(技術不好--->每每有一種玩不下去的想法時,我和我哥兩人就會自暴自棄的玩死Lara!)當時常常和我哥討論要不要出一本.......Lara死法大全!(別打我阿!)當時我們每發現一種死法,就會紀錄下來!(在本子上!當時玩的是ss,要紀錄水晶!)最好玩的就莫過於那個\"摔娃娃\"了!而隨著古墓的動作越多,死法也就越多了!尤其是6代的死法!比以前還新奇!身體會自然擺放!!

總評:
1=4>3>2>6>5
四代阿.....是古墓引擎的最高峰!而一代則是我的初戀!當然是最好玩的!3代..當時在玩時電腦配備不太好,玩起來Log連連...印象不好,6代....不用多說,就是如大家所見嘛....但是我還是覺得很好玩!五代bug蠻多的(比起古墓1~4算多了)而畫面又比不上6代,雖然五代的動作最完善(4代要進高處的矮洞竟然還要分2個動作...&#%@,從矮洞下到低處還得轉身下...唉~~)2代給我的感覺是陰暗的,而且戰鬥太多了!! 雖然是在中國的故事,但~~太暗了啦!(大概是因為製作公司引進了\"照明彈\"這東西...想要讓它非常有用...很多地方都暗的跟什麼一樣= =)

IE 7的消息大家网上查就知道

自己比的，嘿嘿

哎呀，这个传的附件都集中在下面去了啊。。。

这次比较的是 IE 7.0     Firefox 2.0     Opera 9.0    GreenBrowser 3.6 [绿色版]  TheWorld 1.33 [绿色版]

第一个图（3.jpg）是都打开三个页面的 （中文站新闻，老大的Blog以及cnbeta的首页）

第二个图（1.jpg）是打开一个页面的（中文站新闻）

第三个是（1-.jpg）是打开一个空白页面的

第四个是一个空白页面，但是所有程序都最小化的。

看得出来IE7.0在占用内存方便还是。。。让人失望啊

IE7.0支持透明PNG了（比如大家旁边那个企鹅，背景不透明八，而实际不是那样的），这个是我目前唯一喜欢的一点：D

上Q 或者MSN ，帮我下载个东西

 

http://www.gmly.info/index.php?option=com_content&task=view&id=405&Itemid=33

[ENSTR]="Press ??? at the highest point of your swing to jump farthest."

[CHSTR]="在您摆荡至最高点时按 ??? 跳得最远。"

// ----------------------------------

[ENSTR]="Press movement key up to swing in the direction you're facing."

[CHSTR]="按方向键上向您面对的方向游去。"

// ----------------------------------

[ENSTR]="Walk off an edge to safely drop, grab the edge, and hang."

[CHSTR]="走落边缘可安全落下，劳拉会自行攀住边缘并吊挂住。"

// ----------------------------------

[ENSTR]="Walk off an edge or press ??? near the edge to . . .

还没有汉化图片，嗯，有兴趣的可以看看，方法是：

个人资料——>风格及配置偏好——>目前风格: SMF XXXXXXX(更改)—（选更改）—>SMF Live Forum Messanger（这个是新装的，比较清爽！）

目前还在修改中，欢迎试用~~：D

游戏地址：

http://www.3jindt.com/nanaca106.swf

http://www.3jindt.com/nanaca106.swf

http://www.gmly.info/index.php?option=com_content&task=view&id=383&Itemid=33

vincent原译稿


RUTLAND: You're nothing but a thief in cargo shorts.——你只是个穿着迷你裤的小偷。


yew


RUTLAND: 你只是个穿着迷你裤的小偷。

换成"你不过是个衣冠楚楚的小偷/贼罢了。"




羽化蝉


玻利维亚那段第一次相遇，德语版里Rutland就说了："Amanda说你是个贱货"


willbe


那就照最早的翻译，你这个下三滥的小偷


yew


你是个贱货""下三滥的小偷"好恶毒呀！比"衣冠楮 . .

embed
　　（一）、基本语法：
　　embed src=url
　　说明：embed可以用来插入各种多媒体，格式可以是 Midi、Wav、AIFF、AU、MP3等等，Netscape及新版的IE 都支持。　　　url为音频或视频文件及其路径，可以是相对路径或绝对路径。
　　示例：<embed src="your.mid">


　　（二）、属性设置：
　　1、自动播放：
　　语法：autostart=true、false
　　说明：该属性规定音频或视频文件是否在下载完之后就自动播放。
　　true：音乐文件在下载完之后自动播放；
　　false：音乐文件在下载完之后不自动播放。
　　示例：<embed src="your.mid" autostart=true>
　　<embed src="your.mid" autostart=false>


　　2、循环播放：
　　语法：loop=正整数、true、false
　　说明：该属性规定音频或视频文件是否循环及循环次数。
　　属性值为正整数值时，音频或视频文件的循环次数与正整数值相同；
　　属性值为true时，音频或视频文件循环；
　　属性值为false时，音频或视频文件不循环。
　　示例：<embed src="your.mid" autostart=true loop=2>
　　　　　<embed src="your.mid" autostart=true loop=true>
　　　　　<embed src="your.mid" autostart=true loop=false>


　　3、面板显示：
　　语法：hidden=ture、no
　　说明：该属性规定控制面板是否显示，默认值为no。
　　ture：隐藏面板；
　　no：显示面板。
　　示例：<embed src="your.mid" hidden=ture>
　　<embed src="your.mid" hidden=no>


　　4、开始时间：
　　语法：starttime=mm:ss（分：秒）
　　说明：该属性规定音频或视频文件开始播放的时间。未定义则从文件开头播放。
　　示例：<embed src="your.mid" starttime="00:10">


　　5、音量大小：
　　语法：volume=0-100之间的整数
　　说明：该属性规定音频或视频文件的音量大小。未定义则使用系统本身的设定。
　　示例：<embed src="your.mid" volume="10">


　　6、容器属性：
　　语法：height=# width=#
　　说明：取值为正整数或百分数，单位为像素。该属性规定控制面板的高度和宽度。
　　height：控制面板的高度；
　　width：控制面板的宽度。
　　示例：<embed src="your.mid" height=200 width=200>


　　7、容器单位：
　　语法：units=pixels、en
　　说明：该属性指定高和宽的单位为pixels或en。
　　示例：<embed src="your.mid" units="pixels" height=200 width=200>
　　　　　<embed src="your.mid" units="en" height=200 width=200>


　　8、外观设置：
　　语法：controls=console、smallconsole、playbutton、pausebutton、stopbutton、volumelever
　　说明：该属性规定控制面板的外观。默认值是console。
　　console：一般正常面板；
　　smallconsole：较小的面板；
　　playbutton：只显示播放按钮；
　　pausebutton：只显示暂停按钮；
　　stopbutton：只显示停止按钮；
　　volumelever：只显示音量调节按钮。
　　示例：<embed src="your.mid" controls=smallconsole>
　　　　　<embed src="your.mid" controls=volumelever>


　　9、对象名称：
　　语法：name=#
　　说明：#为对象的名称。该属性给对象取名，以便其他对象利用。
　　示例：<embed src="your.mid" name="sound1">


　　10、说明文字：
　　语法：title=#
　　说明：#为说明的文字。该属性规定音频或视频文件的说明文字。
　　示例：<embed src="your.mid" title="第一首歌">


　　11、前景色和背景色：
　　语法：palette=color|color
　　说明：该属性表示嵌入的音频或视频文件的前景色和背景色，第一个值为前景色，第二个值为背景色，中间用 | 隔开。color可以是RGB色（RRGGBB），也可以是颜色名，还可以是transparent（透明）。
　　示例：<embed src="your.mid" palette="red|black">


　　12、对齐方式：
　　语法：align=top、bottom、center、baseline、 left、right、texttop、middle、absmiddle、absbottom
　　说明：该属性规定控制面板和当前行中的对象的对齐方式。
　　center：控制面板居中；
　　left：控制面板居左；
　　right：控制面板居右；
　　top：控制面板的顶部与当前行中的最高对象的顶部对齐；
　　bottom：控制面板的底部与当前行中的对象的基线对齐；
　　baseline：控制面板的底部与文本的基线对齐；
　　texttop：控制面板的顶部与当前行中的最高的文字顶部对齐；
　　middle：控制面板的中间与当前行的基线对齐；
　　absmiddle：控制面板的中间与当前文本或对象的中间对齐；
　　absbottom：控制面板的底部与文字的底部对齐。
　　示例：<embed src="your.mid" align=top>
　　　　　<embed src="your.mid" align=center>


==================
这里还有两个网页很好：

http://playlist.pomaster.com/embed/embed.asp   EMBED語法產生

http://playlist.pomaster.com/embed/embed.asp    DHTML 参考手册 - EMBED 元素 | embed 对象

这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念，增进知识，类似于打RPG游戏的升级。整理这篇文章的动机是两个问题： 问题一：
使用Windows记事本的"另存为"，可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件，Windows是怎样识别编码方式的呢？
我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节，分别是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。但这些标记是基于什么标准呢？ 问题二： 最近在网上看到一个ConvertUTF.c，实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF-8这些编码方式，我原来就了解。但这个程序让我有些糊涂，想不起来UTF-16和UCS2有什么关系。
查了查相关资料，总算将这些问题弄清楚了，顺带也了解了一些Unicode的细节。写成一篇文章，送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂，但要求读者知道什么是字节，什么是十六进制。
0、big endian和little endian
big endian和little endian是CPU处理多字节数的不同方式。例如"汉"字的Unicode编码是6C49。那么写到文件里时，究竟是将6C写在前面，还是将49写在前面？如果将6C写在前面，就是big endian。如果将49写在前面，就是little endian。
"endian"这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，一个皇帝送了命，另一个丢了王位。
我们一般将endian翻译成"字节序"，将big endian和little endian称作"大尾"和"小尾"。
1、字符编码、内码，顺带介绍汉字编码
字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码，为了处理汉字，程序员设计了用于简体中文的GB2312和用于繁体中文的big5。
GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。
GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。
从ASCII、GB2312到GBK，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK都属于双字节字符集 (DBCS)。
2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。从汉字字汇上说，GB18030在GB13000.1的20902个汉字的基础上增加了CJK扩展A的6582个汉字（Unicode码0x3400-0x4db5），一共收录了27484个汉字。
CJK就是中日韩的意思。Unicode为了节省码位，将中日韩三国语言中的文字统一编码。GB13000.1就是ISO/IEC 10646-1的中文版，相当于Unicode 1.1。
GB18030的编码采用单字节、双字节和4字节方案。其中单字节、双字节和GBK是完全兼容的。4字节编码的码位就是收录了CJK扩展A的6582个汉字。 例如：UCS的0x3400在GB18030中的编码应该是8139EF30，UCS的0x3401在GB18030中的编码应该是8139EF31。
微软提供了GB18030的升级包，但这个升级包只是提供了一套支持CJK扩展A的6582个汉字的新字体：新宋体-18030，并不改变内码。Windows 的内码仍然是GBK。
这里还有一些细节：
GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。
对于任何字符编码，编码单元的顺序是由编码方案指定的，与endian无关。例如GBK的编码单元是字节，用两个字节表示一个汉字。 这两个字节的顺序是固定的，不受CPU字节序的影响。UTF-16的编码单元是word（双字节），word之间的顺序是编码方案指定的，word内部的字节排列才会受到endian的影响。后面还会介绍UTF-16。
GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析：在读取DBCS字符流时，只要遇到高位为1的字节，就可以将下两个字节作为一个双字节编码，而不用管低字节的高位是什么。
2、Unicode、UCS和UTF
前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容（更准确地说，是与ISO-8859-1兼容），与GB码不兼容。例如"汉"字的Unicode编码是6C49，而GB码是BABA。
Unicode也是一种字符编码方法，不过它是由国际组织设计，可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set"，简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。
根据维基百科全书(
http://zh.wikipedia.org/wiki/)
的记载：历史上存在两个试图独立设计Unicode的组织，即国际标准化组织（ISO）和一个软件制造商的协会（unicode.org）。ISO开发了ISO 10646项目，Unicode协会开发了Unicode项目。
在1991年前后，双方都认识到世界不需要两个不兼容的字符集。于是它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode2.0开始，Unicode项目采用了与ISO 10646-1相同的字库和字码。
目前两个项目仍都存在，并独立地公布各自的标准。Unicode协会现在的最新版本是2005年的Unicode 4.1.0。ISO的最新标准是ISO 10646-3:2003。
UCS只是规定如何编码，并没有规定如何传输、保存这个编码。例如"汉"字的UCS编码是6C49，我可以用4个ascii数字来传输、保存这个编码；也可以用utf-8编码:3个连续的字节E6 B1 89来表示它。关键在于通信双方都要认可。UTF-8、UTF-7、UTF-16都是被广泛接受的方案。UTF-8的一个特别的好处是它与ISO-8859-1完全兼容。UTF是"UCS Transformation Format"的缩写。
IETF的RFC2781和RFC3629以RFC的一贯风格，清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。
2.1、内码和code page
目前Windows的内核已经支持Unicode字符集，这样在内核上可以支持全世界所有的语言文字。但是由于现有的大量程序和文档都采用了某种特定语言的编码，例如GBK，Windows不可能不支持现有的编码，而全部改用Unicode。
Windows使用代码页(code page)来适应各个国家和地区。code page可以被理解为前面提到的内码。GBK对应的code page是CP936。
微软也为GB18030定义了code page：CP54936。但是由于GB18030有一部分4字节编码，而Windows的代码页只支持单字节和双字节编码，所以这个code page是无法真正使用的。

字符集简史


在所有字符集中，最知名可能要数被称为ASCII的7位字符集了。它是美国信息交换标准委员会（American Standards Committee for Information Interchange）的缩写, 为美国英语通信所设计。它由128个字符组成，包括大小写字母、数字0-9、标点符号、非打印字符（换行符、制表符等4个）以及控制字符（退格、响铃等）组成。


但是，由于他是针对英语设计的，当处理带有音调标号（形如汉语的拼音）的欧洲文字时就会出现问题。因此，创建出了一些包括255个字符的由ASCII扩展的字符集。其中有一种通常被成为IBM字符集，它把值为128-255之间的字符用于画图和画线，以及一些特殊的欧洲字符。另一种8位字符集是ISO 8859-1 Latin 1，也简称为ISO Latin-1。它把位于128-255之间的字符用于拉丁字母表中特殊语言字符的编码，也因此而得名。


欧洲语言不是地球上的唯一语言，因此亚洲和非洲语言并不能被8位字符集所支持。仅汉语（或pictograms）字母表就有80000以上个字符。但是把汉语、日语和越南语的一些相似的字符结合起来，在不同的语言里，使不同的字符代表不同的字，这样只用2个字节就可以编码地球上几乎所有地区的文字。因此，创建了UNICODE编码。它通过增加一个高字节对ISO Latin-1字符集进行扩展，当这些高字节位为0时，低字节就是ISO Latin-1字符。UNICODE支持欧洲、非洲、中东、亚洲（包括统一标准的东亚像形汉字和韩国像形文字）。但是，UNICODE并没有提供对诸如Braille, Cherokee, Ethiopic, Khmer, Mongolian, Hmong, Tai Lu, Tai Mau文字的支持。同时它也不支持如Ahom, Akkadian, Aramaic, Babylonian Cuneiform, Balti, Brahmi, Etruscan, Hittite, Javanese, Numidian, Old Persian Cuneiform, Syrian之类的古老的文字。


事实证明，对可以用ASCII表示的字符使用UNICODE并不高效，因为UNICODE比ASCII占用大一倍的空间，而对ASCII来说高字节的0对他毫无用处。为了解决这个问题，就出现了一些中间格式的字符集，他们被称为通用转换格式，既UTF（Universal Transformation Format）。目前存在的UTF格式有：UTF-7, UTF-7.5, UTF-8, UTF-16, 以及 UTF-32。本文讨论UTF-8字符集的基础。


UTF_8字符集


UTF-8是UNICODE的一种变长字符编码，由Ken Thompson于1992年创建。现在已经标准化为RFC 3629。UTF-8用1到6个字节编码UNICODE字符。如果UNICODE字符由2个字节表示，则编码成UTF-8很可能需要3个字节，而如果UNICODE字符由4个字节表示，则编码成UTF-8可能需要6个字节。用4个或6个字节去编码一个UNICODE字符可能太多了，但很少会遇到那样的UNICODE字符。


UFT-8转换表表示如下：


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

实际表示ASCII字符的UNICODE字符，将会编码成1个字节，并且UTF-8表示与ASCII字符表示是一样的。所有其他的UNCODE字符转化成UTF-8将需要至少2个字节。每个字节由一个换码序列开始。第一个字节由唯一的换码序列，由n位1加一位0组成。n位1表示字符编码所需的字节数。


示例


UNICODE uCA(11001010) 编码成UTF-8将需要2个字节：


uCA -> C3 8A

1100 1010
110xxxxx 10xxxxxx

1100 1010 -> 110xxxxx 10xxxxxx
-> 110xxxxx 10xxxxx0
-> 110xxxxx 10xxxx10
-> 110xxxxx 10xxx010
-> 110xxxxx 10xx1010
-> 110xxxxx 10x01010
-> 110xxxxx 10001010
-> 110xxxx1 10001010
-> 110xxx11 10001010
-> 11000011 10001010
-> C3 8A

UNICODE uF03F (11110000 00111111) 编码成UTF-8将需要3个字节:


u F03F -> EF 80 BF


1111 0000 0011 1111 -> 1110xxxx 10xxxxxx 10xxxxxx
-> 11101111 10000000 10111111
-> EF 80 BF


译者注：由上分析可以看到，UNCODE到UTF-8的转换就是先确定编码所需要的字节数，然后用UNICODE编码位从低位到高位依次填入上面表示为x的位上，不足的高位以0补充。以上是个人经验，如有错误，请不惜指教，谢过先:)


UTF-8编码的优点：


UTF-8编码可以通过屏蔽位和移位操作快速读写。
字符串比较时strcmp()和wcscmp()的返回结果相同，因此使排序变得更加容易。
字节FF和FE在UTF-8编码中永远不会出现，因此他们可以用来表明UTF-16或UTF-32文本（见BOM）
UTF-8 是字节顺序无关的。它的字节顺序在所有系统中都是一样的，因此它实际上并不需要BOM。


UTF-8编码的缺点：


你无法从UNICODE字符数判断出UTF-8文本的字节数，因为UTF-8是一种变长编码
它需要用2个字节编码那些用扩展ASCII字符集只需1个字节的字符
ISO Latin-1 是UNICODE的子集，但不是UTF-8的子集
8位字符的UTF-8编码会被email网关过滤，因为internet信息最初设计为7为ASCII码。因此产生了UTF-7编码。
UTF-8 在它的表示中使用值100xxxxx的几率超过50%， 而现存的实现如ISO 2022， 4873， 6429， 和8859系统，会把它错认为是C1 控制码。因此产生了UTF-7.5编码。


修正的UTF-8：


java使用UTF-16表示内部文本，并支持用于字符串串行化的非标准的修正UTF-8编码。标准UTF-8和修正的UTF-8有两点不同：
修正的UTF-8中，null字符编码成2个字节（11000000 00000000） 而不是标准的1个字节（00000000），这样作可以保证编码后的字符串中不会嵌入null字符。因此如果在类C语言中处理字符串，文本不会在第一个null字符时截断（C字符串以null结尾）。
在标准UTF-8编码中，超出基本多语言范围（BMP - Basic Multilingual Plain）的字符被编码为4字节格式，但是在修正的UTF-8编码中，他们由代理编码对（surrogate pairs）表示，然后这些代理编码对在序列中分别重新编码。结果标准UTF-8编码中需要4个字节的字符，在修正后的UTF-8编码中将需要6个字节。


位序标志BOM


BOM（Byte Order Mark）是一个字符，它表明UNICODE文本的UTF-16,UTF-32的编码字节顺序（高字节低字节顺序）和编码方式（UTF-8,UTF-16,UTF-32， 其中UTF-8编码是字节顺序无关的）。


如下所示：


Encoding Representation
UTF-8 EF BB BF
UTF-16 Big Endian FE FF
UTF-16 Little Endian FF FE
UTF-32 Big Endian 00 00 FE FF
UTF-32 Little Endian FF FE 00 00

UTF-8 and Unicode FAQ
by Markus Kuhn 

中国LINUX论坛翻译小组 xLoneStar[译] 2000年2月 
这篇文章说明了在 POSIX 系统 (Linux,Unix) 上使用 Unicode/UTF-8 所需要的信息. 在将来不远的几年里, Unicode 已经很接近于取代 ASCII 与 Latin-1 编码的位置了. 它不仅允许你处理处理事实上存在于地球上的任何语言文字, 而且提供了一个全面的数学与技术符号集, 因此可以简化科学信息交换.

UTF-8 编码提供了一种简便而向后兼容的方法, 使得那种完全围绕 ASCII 设计的操作系统, 比如 Unix, 也可以使用 Unicode. UTF-8 就是 Unix, Linux 已经类似的系统使用 Unicode 的方式. 现在是你了解它的时候了.

什么是 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 以外的大范围的编码是为私用保留的.

什么是组合字符?
UCS里有些编码点分配给了 组合字符.它们类似于打字机上的无间隔重音键. 单个的组合字符不是一个完整的字符. 它是一个类似于重音符或其他指示标记, 加在前一个字符后面. 因而, 重音符可以加在任何字符后面. 那些最重要的被加重的字符, 就象普通语言的正字法(orthographies of common languages)里用到的那种, 在 UCS 里都有自己的位置, 以确保同老的字符集的向后兼容性. 既有自己的编码位置, 又可以表示为一个普通字符跟随一个组合字符的被加重字符, 被称为 预作字符(precomposed characters). UCS 里的预作字符是为了同没有预作字符的旧编码, 比如 ISO 8859, 保持向后兼容性而设的. 组合字符机制允许在任何字符后加上重音符或其他指示标记, 这在科学符号中特别有用, 比如数学方程式和国际音标字母, 可能会需要在一个基本字符后组合上一个或多个指示标记.

PHP: UTF-8兼容的substr()函数

把Nucleus改成了PHP编码后，发现一些功能，如RSS，LastComments插件等等由于要截取前...个字符做预览，结果造成了从UTF-8字符的中间截断，出现错误，这个函数可以很好的改善这个功能。

更好的实现方法当然是使用官方的mb_substr，但是需要在编译的时候指定参数，我等使用虚拟主机的只好用这个方法解决了。

<?
function utf8_substr($str,$start) {
    /*
    UTF-8 version of substr(), for people who can't use mb_substr() like me.
    Length is not the count of Bytes, but the count of UTF-8 Characters
   
    Author: Windix Feng
    Bug report to: windix(AT)gmail.com, http://www.douzi.org

    - History -
    1.0 2004-02-01 Initial Version
    2.0 2004-02-01 Use PREG instead of STRCMP and cycles, SPEED UP!
    */

preg_match_all("/[x01-x7f]|[xc2-xdf][x80-xbf]|xe0[xa0-xbf][x80-xbf]|[xe1-xef][x80-xbf][x80-xbf]|xf0[x90-xbf][x80-xbf][x80-xbf]|[xf1-xf7][x80-xbf][x80-xbf][x80-xbf]/", $str, $ar); 

    if(func_num_args() >= 3) {
        $end = func_get_arg(2);
        return join("",array_slice($ar[0],$start,$end));
    } else {
        return join("",array_slice($ar[0],$start));
    }
}
?>