VC 中的 STL string 实现

今天小实验一下发现 VC9 的 STL string 实现中没有使用 引用计数和写时拷贝

在 VC6.0 时默认还是有这两个特性的，从 VC7.0 开始貌似就取消了，大概是考虑到线程安全问题

如果我不用多线程，这两个特性应该还是可以一定程度上提高效率的吧

不然在返回一个 string 时是否也要考虑用 auto_ptr 了呢…

看来有必要自己实现一个 string ，或者偶尔考虑用一下其他库的…

 

不过从一致性考虑，感觉还是显式使用智能指针实现以上功能比较好，不然其他各种自定类型是不是也有必要封装一个 share_ptr 类似特性呢。

USACO 4.2.1 Ditch 网络最大流问题算法小结

http://dantvt.is-programmer.com/posts/7974.html
复制算了。MSN 居然能认出全部格式…不错

通过 USACO 4.2.1 Ditch 学习一下最大流算法 。可惜它给的测试数据几乎没有任何杀伤力，后面测试时我们采用 DD_engi 写的程序生成的加强版数据。

总体上来说，最大流算法分为两大类：增广路 (Augmenting Path) 和预流推进重标号 (Push Relabel)。也有算法同时借鉴了两者的长处，如 Improved SAP。本篇主要介绍增广路类算法，思想、复杂度及实际运行效率比较，并试图从中选择一种兼顾代码复杂度和运行效率的较好方案。以下我们将会看到，有时理论分析的时间复杂度并不能很好的反映一种算法的实际效率。

1. Ford – Fulkerson 方法

所有增广路算法的基础都是 Ford – Fulkerson 方法。称之为方法而不是算法是因为 Ford – Fulkerson 只提供了一类思想，在此之上的具体操作可有不同的实现方案。

给定一个有向网络 G(V,E) 以及源点 s 终点 t ，FF 方法描述如下：

Ford-Fulkerson 方法 (G,s,t)
1 将各边上流量 f 初始化为 0
2 while 存在一条增广路径 p
3     do 沿路径 p 增广流量 f
4 return f

假设有向网络 G 中边 (i,j) 的容量为 c(i,j) ，当前流量为 f(i,j) ，则此边的剩余流量即为 r(i,j) = c(i,j) – f(i,j) ，其反向边的剩余流量为 r(j,i) = f(i,j) 。有向网中所有剩余流量 r(i,j) > 0 的边构成残量网络 G_f ，增广路径 p 即是残量网络中从源点 s 到终点 t 的路径。

沿路径 p 增广流量f的操作基本都是相同的，各算法的区别就在于寻找增广路径 p 的方法不同。例如可以寻找从 s 到 t 的最短路径，或者流量最大的路径。

2. Edmonds – Karp 算法

Shortest Augmenting Path (SAP) 是每次寻找最短增广路的一类算法，Edmonds – Karp 算法以及后来著名的 Dinic 算法都属于此。SAP 类算法可统一描述如下：

Shortest Augmenting Path
1 x <– 0
2 while 在残量网络 G_x 中存在增广路 s ~> t
3     do 找一条最短的增广路径 P
4        delta <– min{r_ij:(i,j) 属于 P}
5        沿 P 增广 delta 大小的流量
6        更新残量网络 G_x
7 return x

在无权边的有向图中寻找最短路，最简单的方法就是广度优先搜索 (BFS)，E-K 算法就直接来源于此。每次用一遍 BFS 寻找从源点 s 到终点 t 的最短路作为增广路径，然后增广流量 f 并修改残量网络，直到不存在新的增广路径。

E-K 算法的时间复杂度为 O(VE²)，由于 BFS 要搜索全部小于最短距离的分支路径之后才能找到终点，因此可以想象频繁的 BFS 效率是比较低的。实践中此算法使用的机会较少。

3. Dinic 算法

BFS 寻找终点太慢，而 DFS 又不能保证找到最短路径。1970年 Dinic 提出一种思想，结合了 BFS 与 DFS 的优势，采用构造分层网络的方法可以较快找到最短增广路，此算法又称为阻塞流算法 (Blocking Flow Algorithm)。

首先定义分层网络 AN(f)。在残量网络中从源点 s 起始进行 BFS，这样每个顶点在 BFS 树中会得到一个距源点 s 的距离 d，如 d(s) = 0，直接从 s 出发可到达的点距离为 1，下一层距离为2 … 。称所有具有相同距离的顶点位于同一层，在分层网络中，只保留满足条件 d(i) + 1 = d(j) 的边，这样在分层网络中的任意路径就成为到达此顶点的最短路径。

Dinic 算法每次用一遍 BFS 构建分层网络 AN(f)，然后在 AN(f) 中一遍 DFS 找到所有到终点 t 的路径增广；之后重新构造 AN(f)，若终点 t 不在 AN(f) 中则算法结束。DFS 部分算法可描述如下：

 1 p <– s
 2 while s 的出度 > 0 do
 3     u <– p.top
 4     if u != t then
 5         if u 的出度 > 0 then
 6             设 (u,v) 为 AN(f) 中一条边
 7             p <– p, v
 8         else
 9             从 p 和 AN(f) 中删除点 u 以及和 u 连接的所有边
10     else
11         沿 p 增广
12         令 p.top 为从 s 沿 p 可到达的最后顶点
13 end while

 实际代码中不必真的用一个图来存储分层网络，只需保存每个顶点的距离标号并在 DFS 时判断 dist[i] + 1 = dist[j] 即可。Dinic 的时间复杂度为 O(V²E)。由于较少的代码量和不错的运行效率，Dinic 在实践中比较常用。具体代码可参考 DD_engi 网络流算法评测包中的标程，这几天 dinic 算法的实现一共看过和比较过将近 10 个版本了，DD 写的那个在效率上是数一数二的，逻辑上也比较清晰。

 4. Improved SAP 算法

 本次介绍的重头戏。通常的 SAP 类算法在寻找增广路时总要先进行 BFS，BFS 的最坏情况下复杂度为 O(E)，这样使得普通 SAP 类算法最坏情况下时间复杂度达到了 O(VE²)。为了避免这种情况，Ahuja 和 Orlin 在1987年提出了Improved SAP 算法，它充分利用了距离标号的作用，每次发现顶点无出弧时不是像 Dinic 算法那样到最后进行 BFS，而是就地对顶点距离重标号，这样相当于在遍历的同时顺便构建了新的分层网络，每轮寻找之间不必再插入全图的 BFS 操作，极大提高了运行效率。国内一般把这个算法称为 SAP…显然这是不准确的，毕竟从字面意思上来看 E-K 和 Dinic 都属于 SAP，我还是习惯称为 ISAP 或改进的 SAP 算法。

 与 Dinic 算法不同，ISAP 中的距离标号是每个顶点到达终点 t 的距离。同样也不需显式构造分层网络，只要保存每个顶点的距离标号即可。程序开始时用一个反向 BFS 初始化所有顶点的距离标号，之后从源点开始，进行如下三种操作：(1)当前顶点 i 为终点时增广 (2) 当前顶点有满足 dist[i] = dist[j] + 1 的出弧时前进 (3) 当前顶点无满足条件的出弧时重标号并回退一步。整个循环当源点 s 的距离标号 dist[s] >= n 时结束。对 i 点的重标号操作可概括为 dist[i] = 1 + min{dist[j] : (i,j)属于残量网络G_f}。具体算法描述如下：

algorithm Improved-Shortest-Augmenting-Path
 1 f <– 0
 2 从终点 t 开始进行一遍反向 BFS 求得所有顶点的起始距离标号 d(i)
 3 i <– s
 4 while d(s) < n do
 5     if i = t then    // 找到增广路
 6         Augment
 7         i <– s      // 从源点 s 开始下次寻找
 8     if G_f 包含从 i 出发的一条允许弧 (i,j)
 9         then Advance(i)
10         else Retreat(i)    // 没有从 i 出发的允许弧则回退
11 return f

procedure Advance(i)
1 设 (i,j) 为从 i 出发的一条允许弧
2 pi(j) <– i    // 保存一条反向路径，为回退时准备
3 i <– j        // 前进一步，使 j 成为当前结点

procedure Retreat(i)
1 d(i) <– 1 + min{d(j):(i,j)属于残量网络G_f}    // 称为重标号的操作
2 if i != s
3     then i <– pi(i)    // 回退一步

procedure Augment
1 pi 中记录为当前找到的增广路 P
2 delta <– min{r_ij:(i,j)属于P}
3 沿路径 P 增广 delta 的流量
4 更新残量网络 G_f

 算法中的允许弧是指在残量网络中满足 dist[i] = dist[j] + 1 的弧。Retreat 过程中若从 i 出发没有弧属于残量网络 G_f 则把顶点距离重标号为 n 。

 虽然 ISAP 算法时间复杂度与 Dinic 相同都是 O(V²E)，但在实际表现中要好得多。要提的一点是关于 ISAP 的一个所谓 GAP 优化。由于从 s 到 t 的一条最短路径的顶点距离标号单调递减，且相邻顶点标号差严格等于1，因此可以预见如果在当前网络中距离标号为 k (0 <= k < n) 的顶点数为 0，那么可以知道一定不存在一条从 s 到 t 的增广路径，此时可直接跳出主循环。在我的实测中，这个优化是绝对不能少的，一方面可以提高速度，另外可增强 ISAP 算法时间上的稳定性，不然某些情况下 ISAP 会出奇的费时，而且大大慢于 Dinic 算法。相对的，初始的一遍 BFS 却是可有可无，因为 ISAP 可在循环中自动建立起分层网络。实测加不加 BFS 运行时间差只有 5% 左右，代码量可节省 15~20 行。

 5. 最大容量路径算法 (Maximum Capacity Path Algorithm)

 1972年还是那个 E-K 组合提出的另一种最大流算法。每次寻找增广路径时不找最短路径，而找容量最大的。可以预见，此方法与 SAP 类算法相比可更快逼近最大流，从而降低增广操作的次数。实际算法也很简单，只用把前面 E-K 算法的 BFS 部分替换为一个类 Dijkstra 算法即可。USACO 4.2 节的说明详细介绍了此算法，这里就不详述了。

 时间复杂度方面。BFS 是 O(E)，简单 Dijkstra 是 O(V²)，因此效果可想而知。但提到 Dijkstra 就不能不提那个 Heap 优化，虽然 USACO 的算法例子中没有用 Heap ，我自己还是实现了一个加 Heap 的版本，毕竟 STL 的优先队列太好用了不加白不加啊。效果也是非常明显的，但比起 Dinic 或 ISAP 仍然存在海量差距，这里就不再详细介绍了。

 6. Capacity Scaling Algorithm

 不知道怎么翻比较好，索性就这么放着吧。叫什么的都有，容量缩放算法、容量变尺度算法等，反正就那个意思。类似于二分查找的思想，寻找增广路时不必非要局限于寻找最大容量，而是找到一个可接受的较大值即可，一方面有效降低寻找增广路时的复杂度，另一方面增广操作次数也不会增加太多。时间复杂度 O(E²logU) 实际效率嘛大约稍好于最前面 BFS 的 E-K 算法，稀疏图时表现较优，但仍然不敌 Dinic 与 ISAP。

 7. 算法效率实测！

 重头戏之二，虽然引用比较多，哎~

 首先引用此篇强文 《Maximum Flow: Augmenting Path Algorithms Comparison》

 对以上算法在稀疏图、中等稠密图及稠密图上分别进行了对比测试。直接看结果吧：

稀疏图：

ISAP 轻松拿下第一的位置，图中最左边的 SAP 应该指的是 E-K 算法，这里没有比较 Dinic 算法是个小遗憾吧，他把 Dinic 与 SAP 归为一类了。最大流量路径的简单 Dijkstra 实现实在是太失败了 – -，好在 Heap 优化后还比较能接受……可以看到 Scaling 算法也有不错的表现。

 中等稠密图：

 

 ISAP 依然领先。最大流量算法依然不太好过……几个 Scaling 类算法仍然可接受。

 稠密图：

 

 ISAP……你无敌了！这次可以看出 BFS 的 Scaling 比 DFS 实现好得多，而且几乎与 Improved Scaling 不相上下，代码量却差不少。看来除 ISAP 外 BFS Scaling 也是个不错的选择。

 最后补个我自己实测的图，比较算法有很多是 DD 网络流算法评测包里的标程，评测系统用的 Cena，评测数据为 DD ditch 数据生成程序生成的加强版数据：

 

 我一共写了 7 个版本的 ISAP ，Dinic 算法也写了几个递归版的但效率都不高，只放上来一个算了。从上图来看似乎 ISAP 全面超越了号称最大流最快速算法的 HLPP，但在另外一台机器上测试结果与此却不大相同，有时 ISAP 与 HLPP 基本持平，有时又稍稍慢一些。在这种差距非常小的情况下似乎编译器的效果也比较明显。那个 HLPP 是用 PASCAL 写的，我不知在 Win32 平台下编译代码效率如何，至少我的几个 ISAP 用 VC2008 + SP1 编译比用 g++ 要强不少，也可能是参数设置的问题。

不过这些都是小事，关键是见证了 ISAP 的实际效率。从上面可以看出不加 GAP 优化的 ISAP 有几个测试点干脆无法通过，而不加 BFS 却无甚大影响，递归与非递归相差在 7% 左右的样子。综合以上表现，推荐采用 ISAP 不加 BFS，非递归 + GAP 优化的写法，Ditch 这道题一共也才 80 行左右代码。要提的一点是 GAP 优化用递归来表现的话不如 while 循环来得直接。另外，看起来 HLPP 表现确实很优秀，有机会也好好研究一下吧，预流推进重标号算法也是一大类呢……

最后附上一个 ISAP + GAP + BFS 的非递归版本代码，网络采用邻接表 + 反向弧指针：

1. #include<cstdio>
2. #include<memory>
3. using namespace std;
4.  
5. const int maxnode = 1024;
6. const int infinity = 2100000000;
7.  
8. struct edge{
9.     int ver;    // vertex
10.     int cap;    // capacity
11.     int flow;   // current flow in this arc
12.     edge *next; // next arc
13.     edge *rev;  // reverse arc
14.     edge(){}
15.     edge(int Vertex, int Capacity, edge *Next)
16.         :ver(Vertex), cap(Capacity), flow(0), next(Next), rev((edge*)NULL){}
17.     void* operator new(size_t, void *p){
18.         return p;
19.     }
20. }*Net[maxnode];
21. int dist[maxnode]= {0}, numbs[maxnode] = {0}, src, des, n;
22.  
23. void rev_BFS(){
24.     int Q[maxnode], head = 0, tail = 0;
25.     for(int i=1; i<=n; ++i){
26.         dist[i] = maxnode;
27.         numbs[i] = 0;
28.     }
29.  
30.     Q[tail++] = des;
31.     dist[des] = 0;
32.     numbs[0] = 1;
33.     while(head != tail){
34.         int v = Q[head++];
35.         for(edge *e = Net[v]; e; e = e->next){
36.             if(e->rev->cap == 0 || dist[e->ver] < maxnode)continue;
37.             dist[e->ver] = dist[v] + 1;
38.             ++numbs[dist[e->ver]];
39.             Q[tail++] = e->ver;
40.         }
41.     }
42. }
43.  
44. int maxflow(){
45.     int u, totalflow = 0;
46.     edge *CurEdge[maxnode], *revpath[maxnode];
47.     for(int i=1; i<=n; ++i)CurEdge[i] = Net[i];
48.     u = src;
49.     while(dist[src] < n){
50.         if(u == des){    // find an augmenting path
51.             int augflow = infinity;
52.             for(int i = src; i != des; i = CurEdge[i]->ver)
53.                 augflow = min(augflow, CurEdge[i]->cap);
54.             for(int i = src; i != des; i = CurEdge[i]->ver){
55.                 CurEdge[i]->cap -= augflow;
56.                 CurEdge[i]->rev->cap += augflow;
57.                 CurEdge[i]->flow += augflow;
58.                 CurEdge[i]->rev->flow -= augflow;
59.             }
60.             totalflow += augflow;
61.             u = src;
62.         }
63.  
64.         edge *e;
65.         for(e = CurEdge[u]; e; e = e->next)
66.             if(e->cap > 0 && dist[u] == dist[e->ver] + 1)break;
67.         if(e){    // find an admissible arc, then Advance
68.             CurEdge[u] = e;
69.             revpath[e->ver] = e->rev;
70.             u = e->ver;
71.         } else {    // no admissible arc, then relabel this vertex
72.             if(0 == (–numbs[dist[u]]))break;    // GAP cut, Important!
73.             CurEdge[u] = Net[u];
74.             int mindist = n;
75.             for(edge *te = Net[u]; te; te = te->next)
76.                 if(te->cap > 0)mindist = min(mindist, dist[te->ver]);
77.             dist[u] = mindist + 1;
78.             ++numbs[dist[u]];
79.             if(u != src)
80.                 u = revpath[u]->ver;    // Backtrack
81.         }
82.     }
83.     return totalflow;
84. }
85.  
86. int main(){
87.     int m, u, v, w;
88.     freopen("ditch.in", "r", stdin);
89.     freopen("ditch.out", "w", stdout);
90.     while(scanf("%d%d", &m, &n) != EOF){    // POJ 1273 need this while loop
91.         edge *buffer = new edge[2*m];
92.         edge *data = buffer;
93.         src = 1; des = n;
94.         while(m–){
95.             scanf("%d%d%d", &u, &v, &w);
96.             Net[u] = new((void*) data++) edge(v, w, Net[u]);
97.             Net[v] = new((void*) data++) edge(u, 0, Net[v]);
98.             Net[u]->rev = Net[v];
99.             Net[v]->rev = Net[u];
100.         }
101.         rev_BFS();
102.         printf("%d\n", maxflow());
103.         delete [] buffer;
104.     }
105.     return 0;
106. }

Sound Horizon – Elysion ～楽園幻想物語組曲～

译文转自Popgo
http://popgo.net/bbs/showthread.php?s=&threadid=413602

对歌词的说明：

1．带下划线的词，实际须念成下划线后( )中的词。如：乐园(Elysion)，念作Elysion。

2．歌中的念白，用白字表示。
　 歌中的唱词，用蓝色表示。
　 歌中作为背景声的唱词或念白，用粉色表示。
　 极少数有二人对唱的部分，用其它两种不同彩色表示。

欢迎转载，但转载须保留本段
玖羽 2006.8.22

演出：

作词·作曲·编曲：    ——Revo
主唱·女性念白：     ——Aramary
假面男人ABYSS：   ——Jimang (#1,3,4,7,9,11)
女高音和声：          ——Miyoshi Harito (#3,4,8,11)

=========================================
=========================================
01 – エルの楽園 [→ Side：E →]
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-01.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

01. EL的乐园 [→ Side：E →]

私は…生涯彼女を愛することはないだろう…
我…大概这一辈子都不会爱她…
しかし…彼女という存在は…私にとって特別な意味を孕むだろう…
但…那个被称为“她”的人…对我来说，也许孕育着极特别的意义…
何故なら…生まれてくる娘の名は…遠い昔にもう決めてあるのだから…
为什么呢…因为那生下来的女儿的名字…在很久以前就已经定好了…

──そして…幾度目かの楽園の扉が開かれる……
——于是…乐园的门扉不知第几次被打开……

(Elysion, who ah… Elysion, who ah…)

白い大地に　緋い雫で　描かれた軌跡　罪の道標
白色的大地　绯红的血滴　绘出的轨迹　是罪孽的路标
古びた金貨(コイン)　握りしめたまま　這い擦りながらも　男は笑った
古旧的金币(Coin)　在手中紧握　艰难地爬着　那男人笑了

廻るように　浮かんでくる　愛しい笑顔　すぐ其処に
仿佛盘旋着　浮现在眼前　可爱的笑脸　就快要看见
無限の果てに　手を伸ばす様に　扉に手を掛けた
如同向梦幻的尽头　伸出手一般　那手扶上门扉

──そして…彼の現実は朽ち果てる……
——于是…他的现实朽腐了……
(Come Down to the Elysion)

少女が小さく　咳をする度　胸の痛みが　春を遠ざける
少女每一次　轻轻地咳嗽　胸口的疼痛　都使春天远离
襤褸い毛布でも　夢は見られる　愛を知った日の　温もり忘れない
裹在破烂(诅咒)的毛毯中　依然做着梦　知晓爱的日子　温暖难忘

眠るように　沈んでゆく　愛しい世界　水底に
仿佛睡觉一样　缓缓沉入　可爱的世界　的水底
夢幻の果てが　手を招く様に　扉は開かれた
如同在梦幻的尽头　招着手一般　那门扉打开了

──そして…彼女の現実は砕け散る……
——于是…她的现实碎散了……
(Come Down to the Elysion)

ねぇ…お父様(パパ)　その楽園ではどんな花が咲くの？
喂……爸爸　要是在乐园里的话，会有怎样的花在开着哪？
ねぇ…お父様(パパ)　その楽園ではどんな鳥が歌うの？
喂……爸爸　要是在乐园里的话，会有怎样的鸟在唱着哪？
ねぇ…お父様(パパ)　その楽園では体はもう痛くないの？
喂……爸爸　要是在乐园里的话，这身体就不会再痛了吧？
ねぇ…お父様(パパ)　その楽園ではずっと一緒にいられるの？
喂……爸爸　要是在乐园里的话，我们就永远在一起了吧？
ねぇ…お父様(パパ)…
喂……爸爸…

窓を叩く夜風　弾む吐息　薄暗い部屋　楽しそうな談笑
窗外的夜风　急促的吐息　微暗的房间　似乎很快乐的谈笑
虚ろな月明かり　白い吐息　薄汚い部屋　痩せた膝の少女
空虚的月光　白色的吐息　微脏的房间　那双膝瘦弱的少女

幾度となく繰り返される問い掛け　尽きることのない『楽園』への興味
多少次反反复复地问着　对“乐园”无尽的兴趣
嗚呼…少女にはもう見えていないのだ　傍らに横たわるその屍体が…
啊…少女已经看不到了　那横倒在身旁的尸体…

「ねえ、お父様(パパ)」
“喂，爸爸”
「なんだい、エル？」
“怎么了，EL？”
「明日はなんの日か知ってる？」
“你知道明天是什么日子吗？”
「世界で一番可愛い女の子の誕生日」
“是世界上最可爱的女孩子的生日啦”

“…我想啊，在生日的时候有画册当礼物就好了…”

(Cross Talk)…男の夢想は残酷な現実となり
(Cross Talk)…男人的梦想变成残酷的现实
(Cross Talk)…少女の現実は幽幻な夢想となる
(Cross Talk)…少女的现实变成幽幻的梦想
(Cross Talk)…男の楽園は永遠の奈落となり
(Cross Talk)…男人的乐园变成永恒的深渊
(Cross Talk)…少女の奈落は束の間の楽園となる
(Cross Talk)…少女的深渊变成刹那的乐园

…お父様(パパ)──　その楽園ではどんな恋が咲くの？
…爸爸——　要是在乐园里的话，会有怎样的恋情开着哪？
ねぇ…お父様(パパ)　その楽園ではどんな愛を歌うの？
喂……爸爸　要是在乐园里的话，会有怎样的爱意唱着哪？
…お父様(パパ)──　その楽園では心はもう痛くないの？
…爸爸——　要是在乐园里的话，这心中就不会再痛了吧？
ねぇ…お父様(パパ)　その楽園ではずっと一緒にいられるの？
喂……爸爸　要是在乐园里的话，我们就永远在一起了吧？

ねぇ…お父様(パパ)　その楽園ではどんな花が咲くの？
喂……爸爸　要是在乐园里的话，会有怎样的花在开着哪？
ねぇ…お父様(パパ)　その楽園ではどんな鳥が歌うの？
喂……爸爸　要是在乐园里的话，会有怎样的鸟在唱着哪？
ねぇ…お父様(パパ)　その楽園では体はもう痛くないの？
喂……爸爸　要是在乐园里的话，这身体就不会再痛了吧？
ねぇ…お父様(パパ)　その楽園ではずっと一緒にいられるの？
喂……爸爸　要是在乐园里的话，我们就永远在一起了吧？

ねぇ…お父様(パパ)…
喂……爸爸…

(Elysion, who ah…Elysion, who ah…)
(Elysion, who ah…Elysion, who ah…)

=========================================
=========================================
02 – Ark
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-02.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

02. Ark

「彼女こそ…私のエリスなのだろうか…」
“只有她…才是我的Alice吧…”

「──箱庭を騙る檻の中で　禁断の海馬(器官)に手を加えて
“——在伪装成盆景的牢笼之中　将禁忌的海马体(器官)加工
驕れる無能な創造神(かみ)にでも成った心算なの…」
要成为自大而又无能的造物主(神)　只要这样就可以了……”

…Love wishing to the "Ark"

(崩壊　其れは孕み続けた季節　二月の雪の日　『妹』(Soror)の記憶(ゆめ))
崩溃　那是一直在孕育的季节　二月里下雪的日子　『妹』(Soror)的记忆(梦)

「我々を楽園へ導ける箱舟は 哀れなる魂を大地から解き放つ
“引导我们向乐园而去的方舟 将悲哀的灵魂从大地上解放
救いを求める貴女にアークを与えよう」
现在就赐给祈求救赎的你以Ark”
『アークと呼ばれた物』(それ)は月光を受けて銀色に煌めいた…
「被称为Ark的东西」(它)在月光下闪耀着银色的光芒…

想い出まで裏切った　冷たい言葉の雨
那冰冷的言辞之雨　将回忆背叛
幸せだった二人　永遠に届かなくなる前に…
幸福的两人 在无法获得永恒之前…

「ねぇ…何故変わってしまったの？　あんなにも愛し合っていたのに」
“喂…为什么变了啊？　明明是那么地相爱”
涙を微笑みに換え詰め寄る　『アークと呼ばれた物』(Knife)を握って…
把眼泪换成微笑缓缓靠近　手里握住「被称为Ark的东西」(Knife)

──愛憎の『箱舟』(Ark)
——爱憎之方舟(Ark)

「さぁ…楽園へ帰りましょう、お兄様…」
“来…回到乐园去吧，哥哥…”

(因果　其れは手繰り寄せた糸　六月の雨の日　『兄』(Frater)の記憶(ゆめ))
因果　那是操纵在手中的丝线　六月里下雨的日子　『兄』(Frater)的记忆(梦)

信じてたその人に裏切られた少女
被自己相信的那个人背叛的少女
逃げ込んだ楽園は信仰という狂気
逃入的乐园是被称为信仰的疯狂
新しい世界へと羽ばたける自己暗示
向新世界中展翼飞翔的自我暗示
澄み渡る覚醒は『進行』という凶器
明白的觉醒是被称为恶化的凶器

最期の瞬間に廻った　歪な愛の記憶
最后的瞬间(时刻)中重复的　是扭曲的爱之记忆
脆弱な精神(ココロ)が耐えきれず　あの日嘘を吐いた
脆弱的精神(心灵)不堪重负　那一天欺骗的话语…

律すれば律する程堕ちる　赦されぬ想いに灼かれながら
刻骨蚀心的思念焚烧其身　被违心的拒绝痛苦折磨
まぐわう傷は深く甘く　破滅へ誘う…
交欢的伤口深刻而又甜蜜　诱向毁灭之中…

──背徳の『箱舟』(Ark)
——悖德之方舟(Ark)

「さぁ…楽園へ帰りましょう、お兄様…」
“来…回到乐园去吧，哥哥…”

被験体１０９６　通称『妹』(Soror)同じく
试验体＃1096　通称『妹』(Soror)将同为
(Soror with the "Ark", Frater in the Dark)
被験体１０７６　通称『兄』(Frater)を殺害
试验体＃1076　通称『兄』(Frater)者杀害
(Soror with the "Ark", Frater it’s Dead)

＜症例番号(Case Number)１２＞
＜病例编号(Case Number)12＞
過剰投影型依存における袋小路の模型(モデル)
过度投射型依赖导致走入死胡同的模型(Model)
即ち『虚妄型箱舟依存症候群』(Ark)
亦即“妄想型方舟依赖症候群”(Ark)

限りなく同一に近づける　追憶は狂気にも似た幻想
无限地追求着合二为一　回忆宛如那疯狂的幻想
求める儘に唇を奪い合い　少しずつ楽園を追われてゆく
竭尽所能地亲吻着嘴唇　一点点从乐园远离流放
同じ心的外傷(トラウマ)重ねれば響き会う　けれどそれ以上には…
即使同样的心灵创伤(Trauma)互相重叠回响　但却无法再…

「──箱庭を騙る檻の中で　禁断の海馬(器官)に手を加えて
“——在伪装成盆景的牢笼之中　将禁忌的海马体(器官)加工
驕れる無能な創造神(かみ)にでも成った心算なの…」か…
要成为自大而又无能的造物主(神)　只要这样就可以了”吗…

在りし日に咲かせた花弁は　暗闇に散り逝くように凛と
那往昔悉心浇灌的花瓣　是宛如在黑暗中凋散般地凄凉
少女の声音で響(ささや)く　「楽園へ帰りましょう」…
少女的声音低吟着“回到乐园去吧”…

…Love wishing to the "Ark"

──監視卿(Watcher)は天を仰ぎ深い溜息を吐く
监视官(Watcher)仰天长叹
失った筈の『左手の薬指』(場所)が虚しく疼いた
理应失去的“左手无名指”(地方)空虚地痛着

ふと彼が監視鏡(Monitor)の向こうへ視線を戻すと
——旋即把视线投回到监视镜(Monitor)的方向
嗚呼…いつの間にか少女の背後には仮面の男が立っていた──
啊…不知何时“假面的男人”竟站在少女身后——

=========================================
=========================================
03 – エルの絵本【魔女とラフレンツェ】
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-03.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

03. EL的画册 【魔女与Lafrenze】

いかにして　楽園の扉は開かれたのか…
乐园的门扉是怎样打开的呢……

鬱蒼と茂る暗緑の樹々　不気味な鳥の鳴き声
茂密繁盛的暗绿树林　令人不快的鸟的鸣叫
ある人里離れた森に　その赤ん坊は捨てられていた
一片远离人烟的森林里　那个孩子被遗弃了

幸か…不幸か…人目を憚（はば）かるように捨てられていたその子を拾ったのは
幸运吗…不幸吗…仿佛是怕别人看见，这个孩子才被遗弃；而把她捡去的是
王国を追われた隻眼の魔女　《深紅の魔女と謳われた》（クリムゾンの）オルドローズ
从王国中放逐的独眼魔女　“被称为深红之魔女的”(Crimson之) Old Rose

銀色の髪に　緋色の瞳　雪のように白い肌
银色的秀发　绯红的眼眸　雪一般洁白的肌肤
拾われた赤ん坊は　いつしか背筋が凍る程美しい娘へと育った…
那个被捡回去的孩子　不知不觉地已经长成美得令人背脊发冷的少女了…

流転こそ万物の基本　流れる以上時もまた然り
流转乃是万物的基础　同样在流动的时间亦然
二つの楽園を巡る物語は　人知れず幕を開ける…
在两个乐园之间循环的故事　无人知晓的幕布被拉开…

(可恨啊…让我出去…救救我吧…)

「ラフレンツェや、忘れてはいけないよ。」
“Lafrenze呀…千万不要忘记……”

銀色の髪を風になびかせて　祈るラフレンツェ　死者の為に…
微风吹拂银色的秀发　祈祷吧Lafrenze　为了死者…
小さな唇が奏でる鎮魂歌（レクイエム） 　歌えラフレンツェ　永遠に響け…
薄薄双唇编织出的安魂曲(Requiem)　歌唱吧Lafrenze　在永远(永恒)中回荡…

時を食らう大蛇（セルペンス）　灼けた鎖の追走曲（カノン）
吞噬时间的大蛇(Serpens)　灼热锁缚的轮唱曲(Canon)
狂い咲いた曼珠沙華（リコリス）　還れない楽園（エリュシオン）
疯狂盛开的曼珠沙华(Lycoris)　无法归去的乐园(Elysion)
蝋燭が消えれば　渡れない川がある
烛火一旦熄灭　就见到无可渡过的长河
始まりも忘れて　終わらない虚空（そら）を抱く…
将起源遗忘　拥抱着无尽无终的虚空(穹苍)……

――Creature’s voice
亡者们的声音
「―おのれラフレンツェ」…悲痛な叫びの不響和音（ハーモニー）
“——可恶啊Lafrenze”…悲痛地呼喊着的不协和音(Harmony)

――Un-satisfied
无止境的渴望
「――憎きラフレンツェ」…呪怨の焔は燃ゆる
“——可恨啊Lafrenze”…诅咒怨恨的火焰熊熊燃烧

儚い幻想と知りながら　生者は彼岸に楽園を求め
抱着虚幻的梦想　生者将彼岸的乐园寻求
死者もまた　還れざる彼岸に楽園を求める
而死者也　竭力想回到对岸的乐园
彼らを別つ流れ　深く冷たい冥府の川
将他们分隔的流水　那深冷的冥府之河
乙女の流す涙は　永遠に尽きることなく
女郎流下的眼泪　永远不会停歇
唯…嘆きの川の水嵩を増すばかり…
只是…使叹息之河的水位加增而已…

――少女を悪夢から呼び醒ます　美しき竪琴の調べ
——把少女从恶梦中唤醒的　竖琴美妙的声调
哀しい瞳（め）をした弾き手　麗しきその青年の名は――
眼神哀伤的竖琴手　那英俊的青年名叫……

「ラフレンツェや、忘れてはいけないよ。
“Lafrenze呀…千万不要忘记……
お前は冥府に巣くう亡者共の手からこの世界を護る為の最後の門の番人。
　你是从那盘踞在冥府的亡者们手中守护这个世界的，最后的黄泉守护者。
純潔の結界を破らせてはいけないよ。」
　纯洁的结界，千万不能让它破坏啊……”

祖母が居なくなって　唇を閉ざした
祖母已经不在了　将双唇紧闭
吹き抜ける風　寂しさ孤独と知った
吹过的风　诉说着寂寞的凄凉
彼が訪れて　唇を開いた
当他到来的时候　将双唇轻启
嬉しくなって　誓いも忘れていった…
是那样快乐　连誓言也被遗忘…

――それは手と手が触れあった　瞬間の魔法
——那是　手与手互相碰触　瞬间的魔法
高鳴る鼓動　小さな銀鈴（ベル）を鳴らす
　强烈的心跳　小小的银铃(Bell)轻响
瞳（め）と瞳（め）見つめ合った　瞬間の魔法
　眼与眼互相对视　瞬间的魔法
禁断の焔　少女は恋を知った――
　禁忌的火焰　少女将恋爱知晓…

一つ奪えば十が欲しくなり　十を奪えば百が欲しくなる
夺得了一就想要十　夺得了十更想要百
その焔は彼の全てを　灼き尽くすまで消えはしない…
那火焰即使把他全身　烧尽也不会平息…

「ラフレンツェや　忘れてはいけないよ。」
“Lafrenze呀…千万不要忘记……”

愛欲に咽ぶラフレンツェ　純潔の花を散らして
接受爱欲的Lafrenze　纯洁的花朵被摘下
愛憎も知らぬラフレンツェ　漆黒の焔を抱いて
不知爱憎的Lafrenze　将漆黑的火焰拥抱
彼は手探りで闇に繋がれた　獣の檻を外して
他的手摸索着打开了　黑暗中野兽的牢笼
少女の胎内（なか）に繋がれた　冥府の底へ堕りてゆく…
少女却因腹中之物　堕入冥府的奥深……

――近づいてくる足音
——逐渐接近的脚步声
やがて彼（オルフェウス）が乙女（エウリディケ）の手を引いて　暗闇の階段を駈け上がって来る
终于他(Orpheus)牵着女郎(Eurydice)的手　向黑暗的楼梯上跑去
けれど少女は裏切りの代償として　残酷な呪いを歌った
然而背叛了少女的代价　是残酷的诅咒之歌
嗚呼…もう直ぐ彼は…彼は振り返ってしまうだろう
啊…很快他就…他就要回过头来了——

――魔女がラフレンツェを生んだのか　ラフレンツェが魔女を生んだのか――
——是魔女变成了Lafrenze呢…还是Lafrenze变成了魔女…
――物語は本（ページ）の外側に――
——故事走到了书页之外…

就这样…乐园的门扉打开了……

=========================================
=========================================
04 – Baroque
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-04.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

04. Baroque

「彼女こそ…私のエリスなのだろうか…」
“只有她…才是我的Alice吧…”

主よ、私は人間を殺めました。
主啊，我杀了人。
私は、この手で大切な女性を殺めました。
是我，亲手杀死了那对我无比重要的女性。

思えば私は、幼い時分より酷く臆病な性格でした。
回想起来，我从小就相当地胆怯。
他人というものが、私には何だかとても恐ろしく思えたのです。
所谓的“别人”，对我来说总是无比可怕的存在。

私が認識している世界と、他人が認識している世界。
我认知中的世界和、别人认知中的世界。
私が感じている感覚と、他人が感じている感覚。
我感受到的感觉和、别人感受到的感觉。
『違う』ということは、私にとって耐え難い恐怖でした。
对于这种“不同”，我感到难以忍受的恐怖。
それがいづれ『拒絶』に繋がるということを、無意識の内に知っていたからです。
而那就和“拒绝”联系到了一起，我在冥冥之中也能明白。

楽しそうな会話の輪にさえ、加わることは恐ろしく思えました。
即使是快乐的对话，我也害怕加入其中。
私には判らなかったのです、他人に合わせる為の笑い方が。
我完全不能理解，别人为了互相接近而露出的笑容。
いっそ空気にならたら素敵なのにと、いつも口を閉ざしていました。
干脆变成像空气那样就好了，我一直紧闭双唇。
そんな私に初めて声を掛けてくれたのが、彼女だったのです。
而第一次与那样的我搭话的，就是她。

美しい少女でした、優しい少女でした。
美丽的少女(人)，温柔的少女(人)。
月のように柔らかな微笑みが、印象的な少女でした。
有着如月儿般柔雅的微笑，令人印象深刻的少女。
最初こそ戸惑いはしましたが、私はすぐに彼女が好きになりました。
在起初的迷惑之后，我很快就喜欢上了她。
私は彼女との長い交わりの中から、多くを学びました。
我在与她长久的交往之中，学到了许多东西。

『違う』ということは『個性』であり、『他人』という存在を『認める』ということ。
所谓的“不同”其实只是“个性”，是人借以“认同”所谓“别人”的东西。
大切なのは『同一であること』ではなく、お互いを『理解し合うこと』なのだと。
重要的并不是“相同的事物”，而是人与人之间的“互相理解”。

しかし、ある一点において、私と彼女は『違い過ぎて』いたのです。
不过，只有一点，我是和她“完全不同”的。

狂おしい愛欲の焔が、身を灼く苦しみを知りました。
疯狂的爱欲之火将我焚烧烤炙，痛苦万分。
もう自分ではどうする事も出来ない程、私は『彼女を愛してしまっていた』のです。
我完全无法自已，因为我“已经爱上了她”。
私は勇気を振り絞り、想いの全てを告白しました。
我鼓足全身勇气，把情感全部向她告白。
那时她说出的话语，是何等地悲哀。
しかし、私の想いは彼女に『拒絶』されてしまいました。
然而，我的感情却被她“拒绝”了。
その時の彼女の言葉は、とても哀しいものでした。
那时她说出的话语，是何等地悲哀。
その決定的な『違い』は、到底『解り合えない』と知りました。
我明白了，那决定性的“不同”，终究还是“无法理解”。

そこから先の記憶は、不思議と客観的なものでした。
到此为止的记忆，很不可思议地，都十分客观。
泣きながら逃げてゆく彼女を、私が追い駆けていました。
她哭着逃开，而我则追了过去。
縺れ合うように石畳を転がる、《性的倒錯性歪曲》の乙女達。
仿佛纠结缠绕一般从石阶上滚落，“性别倒错扭曲”(Baroque)的女郎们。
愛を呪いながら、石段を転がり落ちてゆきました……。
一边诅咒着爱情，一边从石阶上滚落……。

この歪な心は、この歪な貝殻は、
这扭曲的心灵，这扭曲的贝壳，
私の紅い真珠は歪んでいるのでしょうか？
我的红色珍珠也已经扭曲了吗？

誰も赦しが欲しくて告白している訳ではないのです。
我的告解并不指望得到谁的宽赦。
この罪こそが、私と彼女を繋ぐ絆なのですから。
这罪孽的缘由，就是我和她之间的羁绊相牵。
この罪だけは、神にさえも赦させはしない……。
这罪孽的深重，即使是神也无法宽赦吧……。

“那么，就让我来宽赦你吧……”
扭曲珍珠般的女郎，在扭曲之日逝去……(Baroque Vierge, Baroque zi le fine…)

──激しい雷鳴　浮かび上がる人影
——巨响的雷鸣　浮现的人影
いつの間にか祭壇の奥に『仮面の男』が立っていた──
不知何时在祭坛之后站立着“假面的男人”——

=========================================
=========================================
05 – エルの肖像
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-05.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

05. EL的肖像

白い結晶の宝石は　風を纏って踊る
白色结晶的宝石　被风包裹着舞跃
樹氷の円舞曲　遠く朽ちた楽園
雾凇之圆舞曲　遥远的湮灭的乐园

黒い瞳孔の少年は　風を掃って通る
黑色瞳孔(眼眸)的少年　被风吹开的
樹氷の並木道　深い森の廃屋
雾凇的林荫道　深深森林中的废屋
少年が見つけた　少女の肖像画
少年见到了　少女的肖像画
「彼」は病的に白い　「彼女」に恋をしてしまった…
“他”对那病态的白皙的　“她”一见倾心…

幼い筆跡の署名　妙に歪な題名は
稚拙地写下的名字(Sign)　奇怪地扭曲的标题(Title)是
【最愛の娘エリスの８つの誕生日に…】
《于最爱的女儿Alice的第八个生日…》

退廃へと至る幻想　背徳を紡ぎ続ける恋物語
——陷于极至颓废(Decadence)的幻想　永续编织的悖德的罗曼史(Romance)
痛みを抱く為に生まれてくる　哀しみ
为承负痛苦而诞生　是多么悲哀
第四の地平線──その楽園の名は「ELYSION」
第四道地平线——那乐园名为『ELYSION』

──そして…幾度目かの楽園の扉が開かれる……
——于是…乐园的门扉不知第几次被打开……

やがて少年は彼の＜理想＞を求めるだろう…
终有一日少年会将他的“理想”(ideaＬ)寻求吧…
やがて少年は彼の＜鍵穴＞を見つけるだろう…
终有一日少年会将他的“匙孔”(keyhoＬe)寻见吧…
やがて少年は彼の＜楽園＞を求めるだろう…
终有一日少年会将他的“乐园”(eＬysion)寻求吧…
やがて少年は彼の＜少女＞を見つけるだろう…
终有一日少年会将他的“少女”(girＬ)寻见吧…

娘もまた母になり　娘を産むのならば
女儿也会成为母亲　然后再生下女儿的话
楽園を失った原罪を　永遠に繰り返す……
使人失去乐园的原罪　就永远往复循环……

始まりの扉と　終わりの扉の狭間で
开始的门扉与　终结的门扉的夹缝之间
惹かれ合う「Ｅ」と「Ａ」──愛憎の肖像
相互靠近的『E』(EL)与『A』(ABYSS)——爱憎之肖像

禁断に手を染め　幾度も恋に堕ちてゆく
触碰禁忌之物　多少次地陷入恋爱之中
求め合う「Ｅ」と「Ａ」──愛憎の肖像
相互寻求的『E』(EVA)与『A』(ADAM)——爱憎之肖像

やがて少年は♂の為に自らを殺し　少女は♀の為に自らを殺す
终有一日少年会因♂(男人)而使自己丧生　少女会因♀(女人)而令自己身亡
時の荒野を彷徨う罪人達は　其処にどんな楽園を築くのだろうか？
在时间的荒野中徘徊的罪人们　在那里会将怎样的乐园建筑？

──幾度となく「Ｅ」が魅せる幻影　それは失ったはずの「Ｅ」の面影
——不知几次被『E』(Elysion)的幻影魅惑　那是已然失去的『E』(Eden)的面容
嗚呼…その美しき不毛の世界は　幾つの幻想を疾らせてゆくのだろう──
啊…这美丽而荒凉的世界　又有多少幻想在其中奔走——

=========================================
=========================================
06 – Yield
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-06.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

06. Yield

「彼女こそ…私のエリスなのだろうか…」
“只有她…才是我的Alice吧…”

一人娘は　せっせと種を蒔く
那女儿独自一人　不断播撒着种子
変わらぬ過去に　訪れぬ未来に
为不会改变的过去　为不会来到的未来
不毛な行為と　君は笑うだろうか？
无果的行为　你会嘲笑的吧？
それなら君は　幸せなんだろうね…
这样的你　真的很幸福呢…

根雪の下で春を待つの　夏が過ぎれば実りの秋ね…
在积雪之下将春天等待　夏季过后就是那收获之秋…

成果…収穫…それは果実を産む
长成…收获…它产下了果实(harvest harvest it yields fruits)
最も遅い収穫…それは甘い果実を産む
最迟来的收获…它产下了甜美的果实(la la, latest harvest it yields sweets)

一夜限りの　情事でも構わない
只有一夜的话　温存(梦想)一下也没关系的
それをも女は　永遠に出来るから
那对女孩来说　就算得到永远(永恒)了
不毛な恋と　君は笑うだろうか？
无果的恋情　你会嘲笑的吧？
やっぱり君は　幸せなんだろうね…
果然你还是　真的很幸福呢…

凍える夜は夢を見るの　夏が過ぎれば想いが実る…
在冰冷的夜里看到了梦　夏季过后就是思念的果实…

結果…収穫…それは果実を産む
结果…收获…它产下了果实(harvest harvest it yields fruits)
最も遅い収穫…それは甘い果実を産む
最迟来的收获…它产下了甜美的果实(la la, latest harvest it yields sweets)

…不安定な数字　…模範的な数式
「3」…不安定的数字　「3-1」…标准的算式
問題となるのは個の性質ではなく　唯…記号としての数量
问题并不在个体的性质　唯有…作为符号的数量而已
世界が安定を求める以上　早くどれか一つを引かなければ…
为了使世界安定下来　赶快把其中的哪个给排除吧…

何故人間は恋をする　相応しい季節に出会えないの？
为什么人们(人)恋爱了　却不能在合适的季节(时候)相遇？
嗚呼…お父さん…お母さん
啊…爸爸(Dad)…妈妈(Mam)

「──それでも私は幸せになりたいのです……」
“——就算这样，我也想得到幸福……”

恋心　甘い果実　真っ赤な果実
恋情　甜美的果实　鲜红的果实(Sweets, lala Sweets, lala 鲜红的Fruits)
もぎ獲れないのなら　刈り取れば良いと…
要是摘不到它的话　就砍下来好了…
恋心　甘い果実　真っ赤な果実
恋情　甜美的果实　鲜红的果实(Sweets, lala Sweets, lala 鲜红的Fruits)
嗚呼…でもそれは首じゃないか……
啊…可那不是脑袋吗……

(La La La La La La La　La La La La La La La La
La La La La La La La　La La La La La La La La…)

二人の♀　一人の♂　一番不幸なのは誰？
两个♀(女人)　一个♂(男人)　其中最不幸的是谁？
落ちた果実…転がる音　余剰な数字…引かれる音
落下的果实…滚动的声音　余剩的数字…排除的声响

「3-1+1-2」

──最後に現れたのは「仮面の男」
——最后出现的是“假面的男人”
彼らが消え去った後　荒野に一人取り残されるのは誰──
当他的身影消失之后　荒野上剩下的一人究竟是谁——

=========================================
=========================================
07 – エルの天秤
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-07.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

07. EL的天秤

杀人…偷盗…诱拐…黑市…

──悪魔に
——就像向恶魔
魂を売り渡すかのように　金になる事なら何でもやった
出卖了灵魂一般　为了金钱什么都能做
問うべきは手段では無い　その男にとって目的こそが全て
不管任何手段　那个男人只为达成目标
切実な現実　彼には金が必要だった…
切实的现实　他需要金钱…

傾き続けてゆく天秤　その左皿が沈み切る前に
一直在倾斜的天秤　那左盘完全落下之前
力づくでも浮き上がらせるだけの金が　右皿には必要だった…
为了使它升起　必须把金钱放在右盘之上…
そして…その夜も天秤は仮面を躍らせる……
就这样……这一夜，假面也在天秤上跃动……

闇を纏うように　夜の静寂を探り　瞳と瞳を見つめ合って
仿佛被黑暗包裹　在寂静的夜中探求　眼与眼互相凝视
夢想的な月灯りに　そっと唇重ね　息を潜めた…
梦幻般(Romantic)的月光照耀　轻轻地将双唇重合　屏住呼吸…
慌しく通り過ぎる　追っ手達を遣り過ごし　手と手を取り合って
慌张地逃跑　追逐的人们从身边跑过　手与手互相交握
戯曲的な逃避行に　酔った二つの人生　愛に捧げた…
戏剧性(Dramatic)的逃亡之旅　迷醉的两个人生(生命)　把爱献上…

再见了吧…(权力走狗手中方便的一张牌)
再见了吧…(卖掉女儿来买得至尊的位置)

身分違いの恋　許されないと知っても　♂と♀は惹かれ合った
身份不符的恋爱　明知不会被允许　♂(男)与♀(女)仍然互相追求
嗜虐的な貴族主義を　蹴って檻を抜け出す　嗚呼それは悲劇…
嗜虐(Sadistic)的贵族主义被踢开　从牢笼中逃脱　啊，那样的悲剧…
運命の遊戯盤の上で　支配力を求めて　生と死は奪い合った
在命运的游戏盘(Board)上　寻求支配的力量　生与死互相争斗
徹底的な追悼劇を　笑う事こそ人生　嗚呼むしろ喜劇…
激烈(Drastic)的悼亡剧　可笑的正是人生　啊，毋宁说是喜剧…

再见了吧…(用金币就能让人背叛的世界)
再见了吧…(是外人就能恣意压榨的惨况)

楽園への旅路　自由への船出　逃走の果てに辿りついた岸辺
通向乐园的旅程　通向自由的航行　逃亡的尽头走到了岸边
船頭に扮した男が指を鳴らすと　黒衣の影が船を取り囲んだ……
扮成船夫的男人一打响指　黑衣的影子将船团团围住……

“回去的船资不用担心，已经预付了足够的数目。不过至于他，就在这里再见了吧”
“真可惜啊…”

「娘さえ無事に戻るならばそれで良い　使用人の方など殺しても構わんわ」
“只要女儿能平安回来就好，佣人(男的)宰了就宰了也没关系”
一度も眼を合わせずに伯爵はそう言った…　金貨の詰まった袋が机叩いた…
伯爵眼都不眨地这么说道…　装满金币(Coin)的口袋扔在了桌子(Table)上…

いつも人間は何も知らない方が幸福だろうに
无论何时人类(人)还是一无所知才比较幸福
けれど他人を求める限り全てを知りたがる
但却总向别人(人)尽可能地将全部事情问询
──何故破滅へと歩みだす？
——为何要走上毁灭的道路？

華やかな婚礼　幸せな花嫁　運命の女神はどんな脚本を好むのか…
盛大的婚礼　幸福的新娘　命运女神中意的是怎样的脚本(Scenario)呢…
虚構の婚礼　消えた花嫁　破滅の女神はどんな綻びも見逃さない…
矫饰的婚礼　消失的新娘　毁灭女神无论怎样的破绽都不会放过…

嗚呼…燃えるように背中が熱い　その男が伸ばした手の先には何かが刺さっていた
啊…背后如火烧似地灼热　那男人伸手摸到了刺中他的什么东西
嗚呼…緋く染まった手を見つめながら　仮面の男は緩やかに崩れ落ちてゆく…
啊…看着手完全染成红色　假面的男人缓缓瘫倒在地上…
嗚呼…その背後には娘が立っていた　凄まじい形相で地に臥せた男を凝視していた
啊…在他背后站着那女儿　凝视着凄惨地横卧在地上的男人
嗚呼…一歩後ずさり何か叫びながら　深まりゆく闇の彼方へ走り去ってゆく…
啊…她倒退一步，一边呼喊着什么　一边跑向愈发深邃的黑暗中…

──徐々に薄れゆく意識の水底で　錆付いた鍵を掴もうと足掻き続ける
——渐渐模糊的感觉　沉入意识的水底　却还抓住生锈的钥匙挣扎
扉は目の前にある　急がなければ　もうすぐ　もうすぐ約束した娘の──
门就在眼前了　不快点的话　再一点　再一点就能把女儿的约定——

=========================================
=========================================
08 – Sacrifice
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-08.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

08. Sacrifice

「彼女こそ…私のエリスなのだろうか…」
“只有她…才是我的Alice吧…”

(Sacrifice, Sacrifice, ah… Sacrifice, Sacrifice, ah…)

無邪気な笑顔が　愛らしい妹は
天真无邪的笑脸　我亲爱的妹妹啊
神に愛されたから　生まれつき幸福だった
她是被神所爱　只为幸福而生
一人では何も　出来ない可愛い天使
自己一个人　就什么都做不了的可爱天使
誰からも愛される　彼女が妬ましかった
无论谁都会去爱　我开始嫉妒那样的她

器量の悪い私を　憐れみないでよ…
器量狭窄的我　没有必要怜悯…

「──惨めな思いにさせる　妹なんて死んじゃえば良いのに…
“——我屈辱地想着，妹妹(那孩子)还不如当初就死了的好…”

(Sacrifice, Sacrifice, ah… Sacrifice, Sacrifice, ah…)

あくる日妹は　高熱を出して寝込んだ
第二天妹妹　就发着高烧躺在床上
ごめんなさい神様　あの願いは嘘なんです
对不起神啊　那祈求只是我胡说的
懺悔が届いたのか　やがて熱は下がった
忏悔被听见了吗　终于热度下去了
けれど今度は母が　病の淵に倒れた
可接下来是妈妈　被病魔缠到身上

母が今際の時に遺した言葉は…
妈妈在临终之时留下的话…
「──妹は他人とは違うから　お姉ちゃんが助けてあげてね…
“——妹妹(那孩子)和别人不一样，当姐姐的(你)要注意照顾她…”

(Sacrifice, Sacrifice, ah… Sacrifice, Sacrifice, ah…)

母が亡くなって　暮らしにも変化が訪れ
妈妈已经不在了　生活发生了变化
生きる為に私は　朝な夕な働いた
为了生计的我　从早到晚都在劳作
村の男達は　優しくしてくれたけど
村子里的男人们　还是那样地温和
村の女達は　次第に冷たくなっていった
可村里的女人们　却愈发地冷淡了

貧しい暮らしだったけど　温もりがあった…
日子虽然清苦　却有浓浓的温情在啊
「──肩を寄せ合い生きてた　それなりに幸福だった…」
“——相依为命地生活，这就是幸福了吧…”
それなのにどうして…こんな残酷な仕打ちを…教えて神様！
可是为什么…会有这么残酷的事呢…告诉我，神啊！
妹が授かった子は　主が遣わし給うた　神の御子ではないのでしょうか？
妹妹(那孩子)得赐的　难道不是主送来的　神之御子吗？

──妹が子供を身篭っていることが発覚した夜
——妹妹怀孕的事情被发现的夜里
村の男達は互いに顔を見合わせ口を噤んだ
村里的男人们互相交换着眼色噤口不言
重い静寂を引き裂いたのは耳を疑う様な派手な打音
我听错了吗？打破沉重静寂的是一声脆响
仕立屋の若女将が妹の頬を張り飛ばした音…
成衣店的女店主抽在妹妹脸上的耳光声……

偷腥的猫…还说什么“可怜的孩子”…这么照顾她…忘恩负义…

──断片的な記憶…断罪的な罵倒…
断片的记忆…判罪的骂声…
嗚呼…この女は何を喚いているんだろう？　気持ち悪い
啊…这女的(人)在喊什么？真讨厌
ぐらりと世界が揺れ　私は弾け飛ぶように若女将に掴み掛かっていた…
世界剧烈地摇晃着　女店主紧紧揪住我，像是要把我扔出去一样…

緋く染まった視界　苦い土と錆びの味　頭上を飛び交う口論　神父様の怒声
被染成红色的视野　苦涩的泥土和生锈的味道　在头顶起伏的讨论　神父大人愤怒的声音

纯洁被…与恶魔的契约…灾祸之子种…圣母玛利亚…谁都应是加百列…用火焚烧…
“啊…恶魔不正是你们这些家伙吗！”

──そして…妹は最期に「ありがとう」と言った…
——然而…妹妹最后只说了一句“谢谢”而已…

心無い言葉　心無い仕打ちが　どれ程あの娘を傷付けただろう
无情的话语　无情的作为　她受到的伤害难以言表
それでも全てを…優しい娘だから…全てを赦すのでしょうね…
可即使这样却全都…她真是温柔…全都宽赦了呢…

“但是，我却绝对不会宽赦啊…”
“这个世界毕竟，只是乐园的代用品不是吗。罪孽深重的家伙们全都，一起归于灰烬就好了！”

──はだしの娘　凍りつくような微笑を浮かべ
——赤脚的女孩　脸上浮现出寒冰一般的微笑
揺らめく焔　その闇の向こうに『仮面の男』を見ていた
摇荡的火光　“假面的男人”在它烧灼的黑暗中现出身形——

=========================================
=========================================
09 – エルの絵本【笛吹き男とパレード】
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-09.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

09. EL的画册 【吹笛人与游行队】

そのパレードは何処からやって来たのだろうか
那游行的队伍是从何处而来呢……

あぁそのパレードは何処までも続いてゆく
啊…这游行不管到哪里都在前进着…

(La La La La La La La La　La La La La La La La
La La La La La La　La La La…)

おぉ友よ、罪もなき囚人達よ
“哦，朋友啊！无罪的囚犯们啊
我等はこの世界という鎖から解き放たれた
我们已从这名为世界的枷锁中解放。
来るものは拒まないが去るものは決して許さない
想来的决不拒绝，想走的决不宽赦。
黄昏の咎に墜ちる　楽園パレードへようこそ
黄昏之葬列…欢迎来到乐园的游行！”

パレードは何処までも続いてゆく
游行不管到哪里都在前进着　→
世界の果てを目指して
　走向世界的尽头
先頭で仮面の男が笛を吹く
前面那假面的男人吹着笛子　→
沈む夕日に背を受けて
　背向沉没的夕阳
(La La)
パレードは何処までも続いてゆく
游行不管到哪里都在前进着　→
世界の果てを目指して
　走向世界的尽头
男の肩に座った少女が歌う
少女正坐在男人的肩上歌唱　→
その笛の音に合わせて
　应和这笛子的声响

心に深い傷を負った者にとって抗えない魔性の音
那是心中刻下深深伤迹的人　绝对无法抗拒的魔性之音…

やぁ友よ幸薄き隣人達よ
“哟，朋友啊！不幸的邻居们啊
我等はこの世界という鎖から解き放たれた
我们已从这名为世界的枷锁中解放。
来るものは拒まないが去るものは決して許さない
想来的决不拒绝，想走的决不宽赦。
仮初の終焉　楽園パレードへようこそ
暂短之终焉…欢迎来到乐园的游行！”

パレードは何処までも続いてゆく
游行不管到哪里都在前进着　→
世界の果てを目指して
　走向世界的尽头
燃えるような赤い髪の女が踊る
红发的女人像火焰一样舞动　→
沈む夕日を背を受けて
　背向沉没的夕阳
(La La)
パレードは何処までも続いてゆく
游行不管到哪里都在前进着　→
世界の果てを目指して
　走向世界的尽头
黒い首吊りピエロのタトゥーが笑う
“可厌的”(黑色)小丑(Pierrot)被绞首的纹身(Tattoo)在笑　→
彼の笛の音に合わせて
　应和那笛子的声响

心に深い闇を被った者にとって逆らえない魔性の音
那是心中养育深深黑暗的人　绝对无法违逆的魔性之音…

笛の音に誘われ一人また一人列に並んでゆく
被笛子(相逢)的声音诱惑　人们一个个走进队伍之中
やがてそのパレードは　夕日を遮って地平線を埋め尽くす
很快这游行的行列　就遮住夕阳，将地平线全部覆满…

例えば、箱舟を信じた少女…
譬如那信从着方舟的少女……
例えば、歪んだ真珠の乙女…
譬如那扭曲珍珠般的女郎……
例えば、収穫を誤った娘…
譬如那错误地收获的女儿……
例えば、妹を犠牲にされた姉…
譬如那妹妹被牺牲的姐姐……
例えば、星屑に踊らされた女…
譬如那为星尘操纵的女人……
誰も仮面の男Abyssからは逃げられない
没有人能从假面的男人ABYSS那里逃脱……

ごきげんよう、可哀想なお嬢ちゃん
“日安，可怜的小姐啊。
楽園パレードへようこそ
欢迎来到乐园的游行！”

笛の音を操って一人また一人列に加えてゆく
被笛子(相逢)的声音操纵　人们一个个加入队伍之中
やがてそのパレードは夕日を裏切って地平線を焼き尽くす
很快这游行的行列　就背叛夕阳，走向地平线的边缘……

(La La La La La La La La　La La La La La La La
La La La La La La　La La La…)

嗚呼…そのパレードは何処までも続いてゆく…
啊…这游行不管到哪里都在前进着…

そのパレードは何処へ向って行くのだろうか…
那游行的队伍将要向何处而往……

=========================================
=========================================
10 – StarDust
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-10.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

10. StarDust

「彼女こそ…私のエリスなのだろうか…」
“只有她…才是我的Alice吧…”

お揃いね私達　これでお揃いねあぁ幸せ…
在一起的我们　这样就在一起了呢　啊，幸福……

Lulululu… StarDust

女は物言わぬ　可愛いだけの<お人形>じゃないわ
别把女人当物品　她并不是可爱的“玩偶”(Doll)啊
愛しい貴方解って?
——亲爱的你能明白吗？

ちっぽけな自尊心　満たすための道具じゃないわ
那一丁点的自尊(东西)　也不是让你满足它的道具啊
月夜の<別人格>は勝手
——月夜中的“另一重人格”(Another)随意而行？

首を締めれば　締まるに決まってるじゃない
虽然勒住脖子　却不能下决心绞紧
<月>が貴方を狂わせたの？
——月亮(Luna)会使你迷狂吗？

だってしょうがないじゃない　愛してしまったんだもの
这也没有办法　人家已经爱上他了嘛
<星>が私を 狂わせたのは何故？
——星星(Stella)为何使我迷狂如此？

真っ赤な衣装　真っ赤な洋靴
真っ赤な口紅　真っ赤な薔薇
赤红色的衣服(Dress)　赤红色的洋鞋(Heel)
赤红色的口红(Rouge)　赤红色的薔薇(Rose)

すれ違う男達　誰もが振り返る
擦肩而过的男人们　无不回头张望……
左手には花束　右手には約束を
左手里拿着花束　右手里抓着约定
疾りだした衝動は　もう止まらない
疾跃的冲动　已不可阻止…

お揃いね私達　これでお揃いね　あぁ幸せ
在一起的我们　这样就在一起了呢　啊，幸福……
あなたの白い衣装も　今は鮮やかな深紅
你那白色的衣服(Shirt)　现在已是鲜艳的深红(Scarlet)
お揃いね私達　これでお揃いね　あぁ幸せ
在一起的我们　这样就在一起了呢　啊，幸福……

屑でも構わないわ　いつか星になれるなら
“…即使是尘土也没有关系，总有一天它也会成为星星
輝いてる？　ねぇ私輝いてる？
闪闪发亮吧？看…我是多么闪耀啊？”

綺麗な星空で　それは艶やかな女のため息
“美丽的星空”…那是女人娇艳的吐息
君の方が綺麗だよ　それは甘い男の囁き
“比不上你的美丽”…那是男人甜蜜的低语
夜空を見上げる恋人達　ありふれた風景
仰望夜空的恋人们　是常见的风景
繰り返される恋模様　 ほんの些細な事
循环往复的恋爱的模样　是细微的事情

そんな気まぐれな一時を　永遠だと信じたりして
将那样变化无常的时光　当作永恒相信
そんな不確かなものを　運命だと信じたりして
将那样无从确知的事物　当作命运相信
泣いたり　笑ったり　愛したり　憎んだりして
哭泣　欢笑　爱恋　憎恨
そのつかの間　遥か過去の光に思いをはせたりして
在那夹缝之中　从遥远过去而来的思念之光在飞驰

あの星々はもう滅んでしまっているのだろうか
那些星星是永远不会毁灭的吗？
それとも今もまだ滅びに向かって輝き続けているのだろうか
还是说，它们现在已经毁灭，只是发出的光辉还在持续呢？
光年という名の途方もない尺度の前では
在连光年都无法计算的遥远的尺度之前
人の一生など刹那の幻に過ぎないのかも知れない
人的一生只是刹那之中的虚幻也说不定…

そんな些細なこと　されど偶然とはいえ
——就是那细微的事情　该说是巧合吧
嗚呼…偶然とはいえ彼女は見てしまった
啊…所谓巧合地，让她看到了
お揃いの白い服を着て幸せそうに寄り添い歩く
穿着白色衣服的两人在一起幸福地漫步
彼と見知らぬ女の姿を
他和从未见过的女人的身形…

お揃いね私達　これでお揃いね　あぁ幸せ
在一起的我们　这样就在一起了呢　啊，幸福……
あなたの白い衣装も　今は…
你那白色的衣服(Shirt)　现在——

なぜ…　なぜなの…　なぜなのよーー!!
“为什…为什么…为什么啊——！！”

酸素に触れた赤は　やがて黒に近づき示す
与氧气接触的红色　迅速变黑
二人はもう永遠に　一つには なれないという事実を
两人已永远地　不能走在一起的事实…

凍てついた銀琉璃の星々　燃え上がる滅びの煌きよ
冰冻的银琉璃般的群星　仿佛要燃烧殆尽般地煌煌闪亮
失くした楽園の夢を見る　私を導け<星屑の幻灯>
在梦里看见失去的乐园　引导着我的“星尘之幻象”(The Light of StarDust)

思い出を過去の光として埋葬できない限り
——只要过去的思念之光还没有被埋葬
孤独な亡霊は荒野を彷徨い続けるだろう
那孤独的亡灵就将永远在荒野之中彷徨
女の手は悲しいほどに短く星屑には届かない
女人的手悲哀而无望地伸向遥远的星尘
嗚呼…その手を握り返したのは「仮面の男」だった
啊……握住了那只手的是“假面的男人”——

=========================================
=========================================
11 – エルの楽園［→ side：Ａ →］
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-11.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

11. EL的乐园 [→ Side：A →]

誰かの呼ぶ声が聞こえた　少女はそれで目を覚ます
听到了什么人的呼唤　少女睁开眼睛
心地よい嵐に抱かれて　澄んだ空へと舞い上がる
被舒畅的风包裹　飞翔在澄净的天空

誰かがね…泣いているの…
是谁在…哭泣呢…

それは気の所為かしら？
是我自己听错了吗？(对，是你听错了哦)
もう…そういうことじゃないわ
不……不是那样的事(那，是风的缘故吗)
楽園で泣くはずないわ
在乐园中应没有泪水(对，所以不要哭了)
だって楽園なんだもの
因为这样才是乐园啊(因为这就是乐园啊)

何処かでね…泣いているの…
在哪里…哭泣呢…

悲しみも苦しみも？
无论悲哀还是痛苦？(对，在这里都没有)
幸せ満ち溢れる世界？
世界中满溢着幸福？(对，乐园就是这样)
楽園で泣くはずないわ
在乐园中应没有泪水(对，所以不要哭了)
だって楽園なんだもの
因为这样才是乐园啊(因为这才是乐园啊)

本当はね…知っているの…
其实呢…我是知道的…

第四道地平线　那乐园的真实是…

空は荒れ　木々は枯れて　花は崩れ朽ち果て
荒凉的天空　枯萎的森林　花儿衰朽败落
腐敗した大地が　闇の底へと堕ちてゆく…
腐坏的大地　堕向黑暗深渊的最深处……
エルは生まれ　エルは痛み　エルは望みの果て
那是EL的诞生　EL的痛苦　EL希望的结果
安らぎの眠りを求め　笑顔で堕ちてゆく…
将安乐的睡眠寻求　带着笑容堕向其中…

"Ark"
托付给方舟的那些愿望…

"Baroque"
扭曲的恋爱互相寻求融合…

"Yield"
一直在盼望着理想的收获…

"Sacrifice"
不管多大的牺牲都盲目地献奉…

"StarDust"
终于能够向星尘伸出自己的手…

挟み込まれた四つの＜楽園＞に惑わされずに
不为自己周边的那四个“乐园”(EL)迷惑
垂直に堕ちれば其処は＜奈落＞
径直堕下的地方，那里是“深渊”(ABYSS)

何処から来て　何処へ逝くの　全ては誰の幻想？
从何处而来　消逝在何处　一切都是谁的幻想(梦)？
差し出された手に　気付かないままに堕ちてゆく…
完全没有注意伸过来的手　就这样堕入…
エルは倦まれ　エルは悼み　エルは望みの涯
那是EL的疲倦　EL的悼念　EL希求的终末
安らぎの眠りを求め　笑顔で堕ちてゆく…
将安乐的睡眠寻求　带着笑容堕向其中…

──退廃へと至る幻想　背徳を紡ぎ続ける恋物語
——陷于极至颓废(Decadence)的幻想　永续编织的悖德的罗曼史(Romance)
痛みを抱く為に生まれてくる　哀しみ
为承负痛苦而诞生　是多么悲哀
幾度となく開かれる扉　第四の地平線──
一次次低鸣着被打开的门扉　第四道地平线——
その楽園の名は「ELYSION」またの名を「ABYSS」──
那乐园名为『ELYSION』又名『ABYSS』——

=========================================
=========================================
44 – bonustrack
  http://www.blogcastone.net/audio/player.swf?soundFile=http://dl.getdropbox.com/u/2128104/SH-Elysion-44.mp3&playerID=10&bg=0xeeeeee&leftbg=0x99ff00&lefticon=0x666666&rightbg=0x666666&rightbghover=0x99ff00&righticon=0xffffff&righticonhover=0xffffff&text=0x666666&slider=0x666666&track=0xFFFFFF&border=0x666666&loader=0x99ff00&loop=no&autostart=no

44. Ending

（＊：全CD的音轨共45首，“44”为隐藏的数字。音轨12到43各无声5秒，音轨45无声7秒）

“我回来了…EL……”
“欢迎回来…爸爸…”

只要那男人的妄念　仍永远孕育下去
被称为故事的历史　就会无尽循环吧

——陷于极至颓废(Decadence)的幻想　永续编织的悖德的罗曼史(Romance)
承负着痛苦而诞生的　第四道地平线——
它真实的名字是——

===========================================
由一条假面男主线穿插出5个女子的悲惨故事。。。
Ark Baroque Yield Sacrifice Stardust —-> ABYSS
背景似乎有多种解读，有兴趣可以查一下

虽然这张CD已经有几年了，但时不时回味一下仍然很有感觉。听多了大概有洗脑效果吧。。。:~)

locale的使用总结

locale 是多种 facet 的容器，每种 facet 管理与 locale 相关的一种功能。
facet 除了按名称区别外，更常用的是按 category 来分类。分类情况如下：

 

locale::ctype 类别，包括以下 facet 模板
ctype // 字符分类和转换
codecvt // 字符编码转换
locale::collate 类别，包括以下 facet 模板
collate // 字符串校对
locale::message 类别，包括以下 facet 模板
messages // 从信息目录中获得本地化信息
locale::numeric 类别，包括以下 facet 模板
numpunct // 有关数字和布尔运算表达式中标点符号及格式信息
num_get // 代表数字或布尔值的字符串的解析
num_put   // 代表数字或布尔值的格式化字符串的生成
locale::monetary 类别，包括以下 facet 模板
moneypunct // 货币表达式中的标点符号及格式
money_get   // 代表货币值的字符串的解析
money_put   // 代表货币值的格式化字符串的生成
locale::time 类别，包括以下 facet 模板
time_get // 代表日期和时间的字符串的解析
time_put // 代表日期和时间的格式化字符串的生成

 

使用方法：
locale 对象是不可变的，即在它们的生命周期中，它们的内容不可改变。所包含的 facet 不能进行修改或替换，同时 facet 不能增加或删除。
鉴于以上特性，在使用 locale 时一般都是根据需要生成新的 locale 对象，然后选入IO流中。因此 locale 的构造函数就变得十分多样，方便我们以各种形式构造所需要的locale 对象。
例如，需要 std::wostream 输出中文，我们就需要 locale("chs") 中编码转换相关的功能，但若直接选择 locale("chs")，输出数字时也会进行转换处理，例如将 1234 输出为 "1,234"。为了避免这一转换，就需要保留原 locale("C") 中除了字符相关的其他facet。如下处理即可
locale loc("chs", locale::ctype);
此函数以 global 对应的 locale （一般是 locale("C") ） 初始化 loc 并选择 locale("chs") 的字符相关 facet ，这样我们就可以用 loc 正确输出中文，并保持输出数字时不进行其他处理
其他可参阅 MSDN 中关于 locale 的构造函数说明，解释很详细，用法很简单。

此外，locale 对象还可使用 combine 成员函数 选取其他 locale 中指定 facet 进行组合。总之接口多样，不过也一定程度上增加了对 locale 学习的复杂性。

 

最后，还有更简便的解决方案，即全局 locale 对象。
如果你建立了一个流对象，并且没有规定流使用的 locale 对象，那么流使用全局 locale 对象。如果我们在程序开始处改变全局 locale 对象为我们需要的形式，以后就不需再反复设定每个流的 locale 了。如
locale::global(locale("",locale::ctype));
除了将字符处理部分改为当前系统默认的编码方式外其他不变，这样一般就满足需求了。
再加一条，当流建立后再改变全局locale，则对已建立的流无影响。还有改变 C++ 的全局 locale 对象可能会影响 C 的全局 locale 设定，请不要混用。既然用 locale 对象，就全部采用 C++ 的风格吧

C++ STL IO流 与 Unicode (UTF-16 UTF-8) 的协同工作

凡用到文件读写，输入输出，就得和编码、Unicode 打交道。这系列实验来测试一下 C++ STL 的 IO流 对 ANSI 编码、Unicode 编码的支持特性，看能否找到一个自动识别编码，自动转码的解决方案。从基础开始，一步一步来：

 

平台 Win32 XP sp3 + VS2008. (+ Boost 1.36.0)

 

实验 01:

#include<string>
#include<iostream>
#include<locale>

using namespace std;

 

locale prevloc;
locale loc("chs");

 

string str1("string class");
string str2("汉字与字符");
wstring wstr1(L"wstring class");          //去掉L前缀则编译错误
wstring wstr2(L"汉字与字符");

 

prevloc = cout.imbue(locale(""));
cout<<"Default Locale: "<<prevloc.name()<<endl;
cout<<"System Locale: "<<locale("").name()<<endl;
cout<<"C风格字符串\n"<<L"w-string\n"<<str1<<‘\n’<<str2<<‘\n’<<endl;

 

prevloc = wcout.imbue(loc);   //若去掉此句，则wstr2无法正常输出
wcout<<"Default Locale: "<<prevloc.name().c_str()<<endl;    //若不加 .c_str() 则编译错误
wcout<<"chs Locale Name: "<<loc.name().c_str()<<endl;
wcout<<"C-string\n"<<"C风格字符串\n"<<L"宽字符串\n"<<wstr1<<‘\n’<<wstr2<<‘\n’<<endl;

 

结论：

        1.cout 与 string 配合使用，wcout 与 wstring 配合使用，交错则编译错误(类型问题)
        2.wstring 初始化时需用 L"xxx" 的宽字符形式，同样 string 初始化时不能加 L 前缀
        3.默认locale ("C")下 cout 可以正常输出 C风格字符串与std::string类型，包括汉字也能正常显示
    但对 L"xxx" 宽字符串无能为力
          默认locale ("C")下 wcout 不能输出中文，包括C风格字符串、宽字符串与std::wstring
    设定系统 locale ("chs")后，正常输出宽字符串与std::wstring，但 C风格字符串 中的汉字无法显示

 

        总之，string cout "C-style 字符串" 自成体系

                  wstring wcout L"宽字符串" 自成体系，但 wcout 要选择 locale 后才能正常输出中文。

 

实验 02:

cout.imbue(locale(""));
wcout.imbue(locale(""));

 

string  str3 ( "abc汉字");
wstring wstr3(L"abc汉字");

 

cout<<"str1 length: "<<str1.length()<<‘\n’; // 12
cout<<"str2 length: "<<str2.length()<<‘\n’; // 10
cout<<"str3 length: "<<str3.length()<<‘\n’; // 7
cout<<str2[0]<<‘ ‘<<str2[1]<<‘\n’;  // 输出：?
cout<<endl;

wcout<<L"wstr1 length: "<<wstr1.length()<<‘\n’; // 13
wcout<<L"wstr2 length: "<<wstr2.length()<<‘\n’; // 5
wcout<<L"wstr3 length: "<<wstr3.length()<<‘\n’; // 5
wcout<<wstr2[0]<<‘ ‘<<wstr2[1]<<‘\n’;   // 输出：汉 字

 

结论：

        4.std::string 内部以 char 类型储存字符，当有汉字时以双字节存储，此时 length() 给出
    字符串所占字节数而不是字符数
          std::wstring 内部以 wchar_t 类型存储字符，字母汉字统一都是双字节，此时 length()
    给出是正确的字符数。
        5.当std::string中有汉字存在时，通过下标访问不能得到正确的字符。这是显而易见的，
    一方面字符宽度不统一无法随机访问，另一方面 std::string[] 返回 char 类型。std::wstring

    不存在此问题。

 

实验 03:

// test.txt 为 ANSI 编码(GB2312)，内容为以上 str1 ~ str3 的3行。

#include<fstream>

 

string str;
wstring wstr;

 

ifstream fin("test.txt");
//fin.imbue(locale(""));
while(fin>>str)
    cout<<str<<‘\n’;
fin.close();

 

wifstream wfin("test.txt");
//wfin.imbue(locale(""));

//wfin.imbue(locale(".936"));
while(wfin>>wstr)
    wcout<<wstr<<‘\n’;
wfin.close();

 

结论：

       6.std::ifstream 读取 ANSI 编码正常，std::wifstream 读取 ANSI 编码错误…默认 locale("C") 不能识别中文字符
          std::wifstream 设置 imbue(locale("")) 或 locale(".936") 后正常读取。936 为 GB2312 的代码页。

 

 实验 04:
 test.txt 为 Shift-JIS 编码，内容为
 うみねこのなく頃に

 程序代码同实验3

 ifstream 输出为
 偆傒偹偙偺側偔崰偵
 wifstream 设定 imbue(locale("")) 后输出相同

 

结论：

       7.显而易见的，其他地区的编码无法正确识别。这也是很多日本游戏和文本文件运行
    或读取时产生乱码的原因。

 

 实验 05:
 test.txt 为 Shift-JIS 编码，内容同上
 ifstream 与 wifstream 都添加 imbue(locale("jpn")) 或 locale(".932")

932 为 Shift-JIS 的代码页
 输出为：

 偆傒偹偙偺側偔崰偵
 うみねこのなく頃に

 

 

结论：

       8.这里可以看出一个显著性差异。wifstream 在读取时按照 Shift-JIS 编码将其转换为
    Unicode 储存，在 wcout 输出时又按照 ANSI (GB2312) 转换，其结果是 —— 正确显示

    了其他地区编码的字符。而 ifstream 与 cout 则缺少那两步转换，结果与上例相同

    以后的实验将不再考虑 ifstream 而只实验 wifstream。

 

 实验 06:
 test.txt 存为 UTF-16 编码(Win32 默认的 little endian)，内容同上。
 wifstream 设定为 imbue(locale(".1200"))
 1200 为 UTF-16 的 code page

 

 结果，运行出错…发现是 imbue(locale(".1200")); 这句的问题
 试着将 ".1200" 改为 ".936" 则运行正常，输出乱码。(936是 GB2312 的代码页)
 翻 MSDN 时在 Code Page 那页1200 UTF-16 后面发现一行小字：
 "available only to managed applications"…郁闷
 看来用 locale 转Unicode的想法到此结束了？记得 STL 书中貌似说过，locale 的名
 字在各平台上是不统一的，因为关系到各平台的支持问题。这样的话，要么自己写
 代码，要么就只好用 API 显式转换了：MultiByteToWideChar

 另外，在 setlocale 函数说明中也写到，UTF-8 和 UTF-7 等每字符有可能大于2字节
 的编码不被支持，所以 UTF-8 也只能用 MultiByteToWideChar 转咯…
 目前大概只能得出结论 C++ STL locale 在 Win32 平台上支持不完善吧

 

 实验 07: 用 API 重写读文件部分代码

#include<windows.h>

HANDLE hFile;
if(INVALID_HANDLE_VALUE != (hFile = CreateFileW(L"test.txt",
        GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL))){

    int iFileLength, iUniTest, i;
    iFileLength = GetFileSize(hFile,NULL);
    char *pBuffer, *pText;
    pBuffer = new char[iFileLength+2];
    DWORD dwBytesRead;

    ReadFile(hFile,pBuffer,iFileLength,&dwBytesRead,NULL);
    CloseHandle(hFile);
    pBuffer[iFileLength] = ”;
    pBuffer[iFileLength + 1] = ”;

 

    iUniTest = IS_TEXT_UNICODE_SIGNATURE | IS_TEXT_UNICODE_REVERSE_SIGNATURE;
    if(IsTextUnicode(pBuffer,iFileLength,&iUniTest)){
        pText = pBuffer + 2;
        iFileLength -= 2;
        if(iUniTest & IS_TEXT_UNICODE_REVERSE_SIGNATURE){
            for(i = 0;i < iFileLength; i+=2)
                swap(pText[i],pText[i+1]);
        }
        wstr = (wchar_t*)(pBuffer+2);
    }
    delete [] pBuffer;

    wcout<<wstr<<‘\n’;
}

 

        输出正确。以上程序段自动识别 Unicode 编码文件开头的 0xFFFE 标记判断是 Little Endian 还是

    Big Endian 并做相应转换。但是代码量较大，且与 C++ 的 IO流 很不搭调…

 

结论：

       9.可以看到，只是把输入内容去掉UTF-16开头的0xFFFE，直接把内存指针改为
    wchar_t* 后 std::wstring 即可正确识别，说明程序中的宽字符存储格式实际上用的就是
    UTF-16 little endian

 

 实验 08:
 不死心又去翻了 boost 库，发现 codecvt_null 这个好东西，看下实现是把文件存储内容
 按照 wchar_t 为单位直接读入内存不做任何转换。这其实不正好是 UTF-16 需要做的么
 以下把 test.txt 存为 UTF-16 little endian 再次实验

#include<boost/archive/codecvt_null.hpp>

wifstream wfin(L"test.txt");
locale utf16(loc, new boost::archive::codecvt_null<wchar_t>);
wfin.imbue(utf16);
while(wfin>>wstr){
    wcout<<wstr<<endl;

}
wfin.close();

 

输出正确。

 

结论：

       10. 看来可以把 codecvt_null 作为 UTF-16 的 codecvt_facet 读入 locale
    来使用，避免使用类似上面 API 那么多代码。

 

 实验 09:
 将 test.txt 存为 UTF-16 Big Endian ,内容不变。程序不变

 

无法输出任何内容。

结论：

       11. wcout 不认识 big endian 的 wchar_t …

    看来想读取 UTF-16 Big Endian，仅靠 codecvt_null 还不够。稍微翻了一下

    《C++ 输入输出流与本地化》这本书，现在可以考虑写一个自己的 codecvt_facet

    了。有了 codecvt_null 的代码，稍作改动即可用于 UTF-16 big endian。虽说有了

    现在的知识自己写个 utf-16 的codecvt_facet 也可以，但效率大概比不上 boost 里的。

 

代码准备：用类似的方法写出了自己的 codecvt_utf16 和 codecvt_utf16_reverse 两个

codecvt_facet…然后继续实验。自己写的内容放入咱自己的头文件吧：codecvt_utf.h，

内容加入自己的 namespace : tvt

 

 实验 10: 用 codecvt_utf.h 代替 codecvt_null.hpp。用 codecvt_utf16 和
 codecvt_utf16_reverse 实现 little endian 与 big endian 的输入。

wifstream wfin(L"test.txt");
locale utf16(loc,new tvt::codecvt_utf16<wchar_t>);
wfin.imbue(utf16);
while(wfin>>wstr){
    wcout<<wstr<<endl;

}
wfin.close();

///////////////////////////////////////

wifstream wfin(L"test.txt");
locale utf16(loc,new tvt::codecvt_utf16_reverse<wchar_t>);
wfin.imbue(utf16);
while(wfin>>wstr){
    wcout<<wstr<<endl;

}
wfin.close();

 

第一段程序读取 UTF-16 little endian 编码的 text.txt 正确输出

第二段程序读取 UTF-16 big endian 编码的 text.txt 正确输出

 

UTF-16 的转码顺利完成。下面考虑 UTF-8 ，写法类似。在 boost 库中继续寻找，发现

这个东东 boost/detail/utf8_codecvt_facet.hpp 。看下说明，不支持直接使用此文件，这文件

是专门提供其他 boost 组件使用的。仅 include 它的话编译出问题。再寻找到同名的 cpp 文件

后即可看到 do_in do_out 这两个转码关键的虚函数。有了上面 UTF-16 的基础，我们类似可写

出 UTF-8 的转码 codecvt_facet。我给他起名为 codecvt_utf8, 依然加入 codecvt_utf.h 文件。

现在此文件有一两百行了。经试验可正确输入 UTF-8 编码。

 

对应编码有了处理方法后，下一个问题是编码识别。

 

实验 11:

wchar_t wc;

wchar_t buf[2];

wifstream wfin(L"text.txt");

wfin.read(&wc,1);

wfin.read(&buf[0],2);

 

将 wc 和 buf 的内容按2进制或16进制输出。

结论：

       12. wistream.read(buffer,count) 操作每次读入 count 个字节，但将每个字节存入一个
 wchar_t 类型的 buffer[i] 中。其实 buffer 中每个 wchar_t 的高位都字节是 0 …

 

 实验 12:
 加入判断条件，在 wfin 中自动加入合适的 utf16 facet，使得自动识别并读取
 little endian 和 big endian 编码的文件：

wchar_t buf[2];
wifstream wfin(L"test.txt");
wfin.read(buf,2);

if(buf[0] == wchar_t(0xFF) && buf[1] == wchar_t(0xFE)){
    cout<<"little endian"<<endl;
    wfin.imbue(locale(loc,new tvt::codecvt_utf16<wchar_t>));
}
else if(buf[0] == wchar_t(0xFE) && buf[1] == wchar_t(0xFF)){
    cout<<"big endian"<<endl;
    wfin.imbue(locale(loc,new tvt::codecvt_utf16_reverse<wchar_t>));
}
while(wfin>>wstr){
    wcout<<wstr<<endl;
}

 

对于两种编码的 text.txt 都实现了自动识别并正确读取。输出正确！

 

结论：

       13.UFT-16在传输时几乎都会加上 0xFFFE 等传输标志很容易判断，即使没有， Win32 下
    也有 IsTextUnicode 这 API 用专门方法判断。UTF-8 就很麻烦了，开头不一定都有 BOM 标

    记，与各地区字符集一样都可以用一个或多字节表示一个字符，编码长度不固定，如果是

    很长一段 ASCII 字符，那么用 UTF-8 和 GB2312 编码出来结果一样，就很难分辨

 

代码准备：经过一段时间思考，打算用这种算法。先读取前3字节，若是 BOM 头标记最好。若

不是则排除 UTF-16 ，下面集中力量分辨 UTF-8 与 ANSI 。从头开始寻找第一个 >127 的字节

若此字节内容 < 0xC0 或 >0xEF 则可判断不是 UTF-8 。否则，根据 UTF-8 的规则，在后面1 或

2 字节中看开头两位是不是 10 。若不是则断定不是 UTF-8 ，否则就算得到一个 UTF-8 字符。

如果能够找到 10个 满足条件的 UTF-8 字符就判断为 UTF-8 编码。若未到 10 个即遇到文件结

尾，那么找到 UTF-8 字符数大于 1 即断定为 UTF-8 否则断定为 ANSI …

用这种方式选择对应转码 facet:

wistrm.imbue(std::locale(wistrm.getloc(), new codecvt_utf8));

 

按以上想法写成函数 int IsStreamUnicode(std::wistream &wistrm); UTF-16 LE 返回1，BE 返回2，

UTF-8 返回3，否则返回 0 (判断为ANSI)

 

实验 13:

 

std::wifstream wfin(L"test.txt");
if(!tvt::IsStreamUnicode(wfin))
    wfin.imbue(loc);
while(wfin>>wstr)
    wcout<<wstr<<endl;

 

 在我试验的各种情况下，均能自动识别 UTF-16 LE UTF-16 BE UTF-8 与 ANSI 编码
 并正确设定转码 locale .

 

 

————————————————————————————-

8小时后，关于后续实验的补充：

 

使用中发现某些情况下 UTF-16 的读写出现问题，特别是有换行符或某字节中编码刚好

等于控制符时。经过反复测试认定是 读写mode 问题。在读写 Unicode 文件时，

wifstream 与 wofstream 都设定为 ios_base::binary 模式即可。后来又补充了一个添加

BOM 头的小东西。为了使用简便把 utf_16 的 template 也去掉了。最终情形使用起来

像这个样子：

 

#include<iostream>

#include<fstream>

#include<codecvt_utf.h>

using namespace std;

 

wstring wstr;

wcout.imbue(locale(""));

 

// Open the Input and Output Files:

std::wifstream wfin(L"test.txt", ios_base::binary);
std::wofstream wfout(L"testout.txt", ios_base::binary);

 

// Set Output Format and Write BOM tag:
wfout.imbue(locale(locale(""), new tvt::codecvt_utf16));

wfout<<tvt::utf_bom;

 

// Detect the Format of the Input File

if(!tvt::IsStreamUnicode(wfin))
    wfin.imbue(locale(""));

 

// Read and Write

//while(wfin>>wstr){
//    wcout<<wstr<<endl;
//    wfout<<wstr<<endl;
//}

 

// Another way:

while(getline(wfin,wstr)){
    wcout<<wstr<<endl;
    wfout<<wstr<<endl;
}

 

// Close Files:

wfin.close();
wfout.close();

 

读写测试全部通过！

 

感谢 记事本、EditPlus 和 HxDen 的大力支持…

 至此，关于 Unicode 编码和 C++ STL IO流 的协作算是大功告成了吧，呵呵。以后有需要再

在实践中改进

 花了整整一天时间 + 8 小时 = = 还算有价值吧，因为在网上看到很多人都在问且没有结果

 

 ===========分隔线============

 再加一点关于 locale 的使用总结

 另附：现在来看用 c++ 的 IO stream locale 系列实现转码并不是一个经济的选择，如果用 STLport 的话还好些，用 VC STL 则存在较严重的效率问题：

 File I/O 效率 C vs C++ (一)

Python os.walk() 函数中的陷阱

用 VC 写程序多了会留下很多中间文件和辅助文件，浪费不少空间，一个个去清理项目又费时费力，写个脚本吧，以后也好用。

 

然后想当然的写下了这样的语句：

for root, dirs, files in os.walk(path):
    for name in files:  
        if splitext(name)[1] == ‘.sln’:
            print "Cleaning",join(root,splitext(name)[0]),"…"
            dirs = []
            CleanSolution(root,splitext(name)[0])

 

在某文件夹下发现 ‘.sln’ 项目文件则不需再往下层文件夹寻找。根据 os.walk() 函数的解释，在循环中修改 dirs 变量即可控制下层递归访问的文件夹，语句 dirs = [] 把 dirs 置空，则递归访问应到此结束。但是在跟踪执行中发现，虽然 dirs 确实被置空了，os.walk() 的递归访问却并没有终止，仍然依次访问了下层的所有文件夹…为什么呢？

尝试着把 dirs = [] 改为 for dir in dirs: dirs.remove(dir) 后运行得到了理想的结果

但为何 remove() 函数可以，赋值却不行？猛然间想到以前实验的一个例子：

 

例一：

>>> a = [1,2,3]
>>> b = a
>>> b.remove(2)
>>> a
[1, 3]

 

此例很能说明问题，虽然在 b 上执行了 remove(2) 操作，但 a 中的元素也被改动了，说明 b = a 实际上并没有复制 list 中的元素，而只是相当于把一个指针传给了 b，a、b实际都指向同一个 list

 

例二：

>>> a = [1,2,3]
>>> b = a
>>> b = []
>>> a
[1, 2, 3]

 

有了上例的基础再看这个应当很好理解了，b = [] 只相当于把一个空 list 的指针给了 b，a 中的元素自然不受影响

 

例三：

>>> a = [1,2,3]
>>> b = a
>>> b[:] = []
>>> a
[]

 

只是把 b 变成了 b[:]，这次 a 中的元素被全部清空

 

最后再次回到一开始的 os.walk() 上，递归中 dirs 实际上是以类似 b = 内部 list 的形式得到了所有子文件夹列表，dirs = [] 就不会有任何结果了。把程序改为

dirs[:] = [] 或

del dirs[:]

即可正确实现。

 

看来还是实践比较有锻炼效果，以前专门注意过 list 的赋值动作，结果这次藏在 os.walk() 函数中依然没有发现，造成了潜在错误…

 

PS. 脚本挺好用，居然腾出了 1GB 多空间

最小环 与 Floyd

Floyd 的 改进写法可以解决最小环问题，时间复杂度依然是 O(n^3)，储存结构也是邻接矩阵

 

int mincircle = infinity;

Dist = Graph;

for(int k=0;k<nVertex;++k){

    //新增部分:
    for(int i=0;i<k;++i)
        for(int j=0;j<i;++j)
            mincircle = min(mincircle,Dist[i][j]+Graph[j][k]+Graph[k][i]);

    //通常的 floyd 部分:

    for(int i=0;i<nVertex;++i)
        for(int j=0;j<i;++j){

            int temp = Dist[i][k] + Disk[k][j];

            if(temp < Dist[i][j])

                Dist[i][j] = Dist[j][i] = temp;

        }

}

 

上面是对无向图的情况。

Floyd 算法保证了最外层循环到 k 时所有顶点间已求得以 0…k-1 为中间点的最短路径。一个环至少有3个顶点，设某环编号最大的顶点为 L ，在环中直接与之相连的两个顶点编号分别为 M 和 N (M,N < L)，则最大编号为 L 的最小环长度即为 Graph(M,L) + Graph(N,L) + Dist(M,N) ，其中 Dist(M,N) 表示以 0…L-1 号顶点为中间点时的最短路径，刚好符合 Floyd 算法最外层循环到 k=L 时的情况，则此时对 M 和 N 循环所有编号小于 L 的顶点组合即可找到最大编号为 L 的最小环。再经过最外层 k 的循环，即可找到整个图的最小环。

 

若是有向图，只需稍作改动。注意考虑有向图中2顶点即可组成环的情况。

WMA 2-pass vs. Ogg 低音质

以前都是用播放器直接转音乐格式，没怎么研究过参数，当时大致比较过 128kbps 以下 ogg 的音质体积比最优。

大于 128kbps 时几乎听不出差别，没法继续……

 

今天试着把 WMA 的参数调成 -a_mode 3 (bitrate-based 2-pass) 和 -a_mode 4 (peak bitrate-based 2-pass)，即传说中的 2 遍扫描，使得编码器可以完整掌握一首曲子的全部信息后再编码，应该算是最优模式了吧。再拿来与 Ogg 比试下，结果大失所望…48kbps 下文件体积比 ogg 大了约 10% ，然而音质却依然比不上 ogg 。不过 ogg 的编码时间倒是比 WMA 的两遍扫描都要久 = =

 

爸爸野猪之歌

爸爸野猪之歌

 

呜～
爸爸 野猪 野猪 阿里耶
病顾你 野猪 野猪 爱米那
爸爸 野猪 野猪 阿里耶
顾吉娜 拉阔 爱你猪肚耶
爸爸 野猪 野猪 阿里耶
病顾你 野猪 野猪 爱米那
爸爸 野猪 野猪 阿里耶
顾吉娜 喇叭 爱你猪肚撒
有兔皮 来哦 叉库拉 吃一兔
吐那处那他吉 呵吐死买河
妈阔撒 也吐 嘿
卡玛 那丝 吐那位哟挖啥没呵咧
哇咧偶吐阔西 阿死吐铁
卡提卡 马甲日不拉KEY你
阿脱快 那有了 米了列啦 米了列
爸爸 野猪 野猪 阿里耶
病顾你 野猪 野猪 爱米那
爸爸 野猪 野猪 阿里耶
顾吉娜 拉阔 爱你猪肚撒
爸爸 野猪 野猪 阿里耶
病顾你 野猪 野猪 爱米那
爸爸 野猪 野猪 阿里耶
顾吉娜 拉不 爱你猪肚耶

阿发卖偶挖阔 阿飞可 阿那卡罗
粒饭 一克度年 啊一妈妈病古你啊病啊嗯

爸爸 野猪 野猪 阿里耶
病顾你 野猪 野猪 爱米那
爸爸 野猪 野猪 阿里耶
顾吉娜 喇叭 爱你猪肚耶
爸爸 野猪 野猪 阿里耶
病顾你 野猪 野猪 爱米那
爸爸 野猪 野猪 阿里耶
顾吉娜 喇叭 爱你猪肚撒
阿土伯 累哦 叉库拉 吃一兔
吐那处那他吉 啊吐死买河
妈阔撒 也吐 嘿
卡玛 那丝 吐那位哟挖啥没呵咧
哇咧偶吐阔西 阿死吐铁
卡提卡 马甲日不 拉KEY你
阿土阔哎 那有了 死妈妈 木外呼耶
爸爸 野猪 野猪 阿里耶
吉娜 拉不 爱你猪肚撒耶
爸爸 野猪 野猪 阿里耶
吉娜 拉阔 爱你猪肚撒耶

 

文明 IV 开场动画和标题菜单的BGM 《Baba Yetu》，和着动画中从地平线升起的太阳，想到古代文明之火穿越中世纪、工业时代直到现代一路走来日渐兴旺，音乐也随之变得大气磅礴，真的是感触良多。歌词是非洲洲班图语系中的斯瓦希里语，基督教的主祷文。

 

 

原文：

CHORUS
Baba yetu, yetu uliye
Mbinguni yetu, yetu, amina!
Baba yetu, yetu, uliye
Jina lako litukuzwe.
(x2)

Utupe leo chakula chetu
Tunachohitaji utusamehe
Makosa yetu, hey!
Kama nasi tunavyowasamehe
Waliotukosea usitutie
Katika majaribu, lakini
Utuokoe, na yule, milelea milele!

CHORUS

Ufalme wako ufike utakalo
Lifanyike duniani kama mbinguni. (Amina)

CHORUS

Utupe leo chakula chetu
Tunachohitaji utusamehe
Makosa yetu, hey!
Kama nasi tunavyowasamehe
Waliotukosea usitutie
Katika majaribu, lakini
Utuokoe, na yule, simama mwehu

Baba yetu, yetu, uliye
Jina lako litukuzwe.
(x2)

译文：

Our Father, 我们的父，
who art in Heaven. Amen! 在天堂中创造，阿门！
Our Father, 我们的父
Hallowed be thy name. 您的名字是那么神圣！
(x2)
Give us this day our daily bread, 您给了我们今天的面包
Forgive us of 饶恕了
our trespasses 我们的过失
As we forgive others 如同我们饶恕他人
Who tresspass against us 无论谁要对我们进行侵害
Lead us not into temptation, 不会让我们陷于诱惑
but deiver us from Evil, 但救我们免于凶恶
and you are forever and ever! 您是永恒！

Thy kingdom come, thy will be done 当您的国度降临，您将会让
On Earth as it is in Heaven. (Amen) 这个地球成为一个天堂。

Our Father, 我们的父，
who art in Heaven. Amen! 在天堂中创造，阿门！
Our Father, 我们的父
Hallowed be thy name. 您的名字是那么神圣！
(x2)
Give us this day our daily bread, 您给了我们今天的面包
Forgive us of 饶恕了
our trespasses 我们的过失
As we forgive others 如同我们饶恕他人
Who tresspass against us 无论谁要对我们进行侵害
Lead us not into temptation, 不会让我们陷于诱惑
but deiver us from Evil, 但救我们免于凶恶
and you wake the dead (?) 您是主宰！

Our Father, 我们的父，
who art… 创造……
Our Father, 我们的父，
Hallowed be thy name. 您的名字是那么神圣！

 

杂七杂八

终于从千千静听全面转向Foobar了…

反正咱也没硬件条件，音质好坏听不出也无所谓，也懒得调试各种插件，千千在操作上还是比较方便的，顶多需要自己配几个命令行编码器所以一直都没换。不过最近的发展方向越来越奇怪了，一个劲增强网络播放在线音乐什么的，而视大量新出现的编码格式于不顾，内嵌cue也不支持……

刚好赶上 foobar0.9.6 Release ，便拿来稍研究了一番，配上几个常用插件后果然是相当的好用。外观就用分栏界面+下拉列表，可定制性极强也很稳定，几个解码插件自不必说，歌词秀、批量标签+addons、DSP一个回旋混响算了，咱也不追求音效，最后再加一个流媒体……能想到的需要基本都齐了。格式转换的话自己加几行命令即可，要转 wma 得再装个 WMEncoder，自己设参数 2-pass 绝对比千千转出来的强。还有一个优点是可以直接播放压缩包里的内容，这样从驴子上抓下来的东东为了上传就不用再多占地方了。唯一不爽的一点是那个流媒体插件 mslive 貌似不太稳定，对 URL 有时候反映很慢，暂时也没找到比较好的替代插件。好在需要在线听的机会也不多影响不大。

 

经常玩游戏，修改器是必备。一个金山游侠用了这么多年，偶尔也该换换了，最近发现一个叫 Cheat Engine 的东东感觉很强，不光提供多种数值查找，内存修改，多级指针锁定，甚至还自带调试器，反汇编、还有方便的代码注入、脚本注入工具…OTL 快赶上那帮搞破解的了。入门教程也很有趣，通过九关挑战来熟悉软件的各种应用，除了 Step8 的多级指针稍微麻烦一些，其他题目还算厚道。

 

终于也该接触 boost 了，不过这玩意编译完可真大，那几个组件只挑了些用得到的参数编译还是占了五六百MB，再加上之前 wxWidgets 的600多MB，就这么1GB多就没了。以前还想一个VC++居然都有1-2GB是怎么来的，现在大概知道了，原来库的体积这么大，估计 MFC 也不会小。 Sonar 在电脑里也荒废了挺久，几日不见版本号从6变成了8，算了就我这还停留在换换音色调调参数的水平不管也罢，不过现在硬盘大了，那个1.7GB的 Hypersonic 2 还是要爽一下滴