听汉公的说明,看来LittleWitch所使用的FFD System在ver4之后解起来就有点麻烦。游戏里的资源归档文件里虽然还是有文件列表,但并没有保存原始的文件名而只是保存了文件名的MD5。这使得解出文件有困难,如果事先不知道想要解的文件的名字,即使把内容能解出来,其文件名也让人不知所云。
但总有办法的。在System.dat里有些定义界面元素用的*.def文件。例如这样:
Music.def
[quote]# サウンド定義ファイル
# "条件式", "サウンドファイル名", "サムネイルファイル名", "見出し"
"1" ,"m/BGM_01.ogg" , "SAM/music_thumb.bmp", "Regret"
"1" ,"m/BGM_02.ogg" , "SAM/music_thumb.bmp", "夕影"
"1" ,"m/BGM_03.ogg" , "SAM/music_thumb.bmp", "Reminiscene"
"1" ,"m/BGM_04.ogg" , "SAM/music_thumb.bmp", "Introduction"instrument
"1" ,"m/BGM_05.ogg" , "SAM/music_thumb.bmp", "陽春"
"1" ,"m/BGM_06.ogg" , "SAM/music_thumb.bmp", "沙友"
"1" ,"m/BGM_07.ogg" , "SAM/music_thumb.bmp", "透花 op02"
"1" ,"m/BGM_08.ogg" , "SAM/music_thumb.bmp", "透花"
"1" ,"m/BGM_09.ogg" , "SAM/music_thumb.bmp", "エマ op02"[/quote]
这些列表能提供足够信息解出相当多的资源,例如说背景音乐、CG等。但有些重要的资源文件名却不在*.def里,像是我们关心的脚本文件。
[url=http://rednaxelafx.iteye.com/blog/149811]前一篇[/url]里介绍了如何将Quartett!的二进制脚本转变回到一般可读的形式,这里就稍微说明一下我是如何从解出来的脚本中得到一份脚本里引用过的文件列表。
从前一篇的分析可以知道,token类型为0x83的是字符串token。在FFD脚本里,好几种内容都可能会是字符串类型:1、剧情文本;2、一般参数,如图像渐变的模式"Fade",图像的形状"Rect"之类;3、资源文件路径;等等。不进行文法分析的话,没有办法准确判断这些字符串中到底哪些代表资源文件的路径。但有些偷懒的方式可以试试。
我浏览了一下Quartett!的脚本,假定其引用的资源文件路径中必然有分隔符“.”。但是有一些剧情文本里也有“.”,为了尽量排除掉它们,我写了这样的判断方法:
将前一篇里提到的“反编译器”稍微修改了一下,让它收集所有脚本中满足上面的判断的token,并输出到一个单一的文本文件中。
于是得到了类似这样的一个文件:
(片段)
[code]../
Script/BaseInstruction.txt
Back/Lesson01.bmp
<FONT size=18 face='G'>フィル君.<BR>まだ<TYPE interval=500 speed=500 style='Spring'>~
I/100221/0221-#03b-02-2.bmp
BGM/B02_Juni.ogg
I/100221/0221-#03b-02-3.bmp
I/100221/0221-#03b-02-4.bmp
I/100221/0221-#03b-03-1.bmp
Face/Juni11R.png
<TYPE interval=55 style='Fade'>なっ ..なんて<BR>わかりやすい<BR>ゴマカシを・・・・・・ <TYPE style='Fade'><IMG src='Em/Ase18.png'>[/code]
使用UltraEdit打开该文件,并使用文件->排序->高级排序/选项。选择“升序”和“删除重复”,并开始排序。对这里的例子排序的话,结果是:
[code]../
<FONT size=18 face='G'>フィル君.<BR>まだ<TYPE interval=500 speed=500 style='Spring'>~
<TYPE interval=55 style='Fade'>なっ ..なんて<BR>わかりやすい<BR>ゴマカシを・・・・・・ <TYPE style='Fade'><IMG src='Em/Ase18.png'>
BGM/B02_Juni.ogg
Back/Lesson01.bmp
Face/Juni11R.png
I/100221/0221-#03b-02-2.bmp
I/100221/0221-#03b-02-3.bmp
I/100221/0221-#03b-02-4.bmp
I/100221/0221-#03b-03-1.bmp
Script/BaseInstruction.txt[/code]
可以看到,如果有重复的资源文本,它们已经被UltraEdit清除掉了。而且有一些我们所不关心的内容也堆在了一起,可以方便的选取并删除。
这里我们对FONT和TYPE标签都没兴趣,但在实际删除它们之前,留意到有些行里有IMG标签,里面有我们感兴趣的src属性指向的是资源文件,得留下。这部分我是自己做了苦力,在UltraEdit里逐个搜索<IMG src并将与其在同一行上的非文件路径内容都删除掉。再做一个排序,确认所有IMG标签都处理好了,然后把FONT、TYPE等标签,以及排在后面的纯剧情文本都删除掉。
经过处理,提取出来的记录里就只剩下这样的内容了:
[code]BGM/B01_Charlotte.ogg
BGM/B02_Juni.ogg
BGM/B03_Shuhua.ogg
BGM/B04_MyHome.ogg
BGM/B05_Serious.ogg
BGM/B07_AcademiaMusicae1.ogg
BGM/B08_AcademiaMusicae2.ogg
BGM/B09_AcademiaMusicae3.ogg
BGM/B10a_Bar1.ogg
BGM/B10b_Bar2.ogg
BGM/B11a_Title.ogg[/code]
我把这样的文件列表给了汉公,但之后又得到了新的要求:要把这个列表按归档文件拆分开来。
这是件简单的事。首先得知道路径上什么是归档的文件名,什么是归档里内容的文件名。通过分析,发现路径上最后一个/之后的是归档里内容的文件名,而在那之前的都是归档自身的路径。于是写了个简短的程序来对文件列表做二次处理:
split.cs
完事。来看看其中一个分离出来的lst文件长什么样:
Face.lst
[code]Char01L.png
Char04L.png
Char04R.png
Char15L.png
Gise12R.png
Gise17R.png
Hans03L.png
Hans03R.png
Juni05R.png
Juni10L.png
Juni10R.png
Juni11R.png
Lina02L.png
Lina06L.png
Lina06R.png
May15L.png
May16R.png
Phil00L.png
Phil00R.png
Phil02L.png
Phil02R.png
Phil03L.png
Phil03R.png
Phil04L.png
Phil04R.png
Phil05R.png
Phil07L.png
Phil07R.png
Phil12L.png
Shuh00R.png
Shuh11R.png
Sign09R.png
Sign10R.png[/code]
嗯,基本上满足要求了。
==========================================================
进一步的精确分析确实需要写出parser来做。我现在肯定是没时间做,不过计划以后做的时候用ANTLR来完成。难点是要设计出一个精确的上下文无关文法。到时候再说吧~
但总有办法的。在System.dat里有些定义界面元素用的*.def文件。例如这样:
Music.def
[quote]# サウンド定義ファイル
# "条件式", "サウンドファイル名", "サムネイルファイル名", "見出し"
"1" ,"m/BGM_01.ogg" , "SAM/music_thumb.bmp", "Regret"
"1" ,"m/BGM_02.ogg" , "SAM/music_thumb.bmp", "夕影"
"1" ,"m/BGM_03.ogg" , "SAM/music_thumb.bmp", "Reminiscene"
"1" ,"m/BGM_04.ogg" , "SAM/music_thumb.bmp", "Introduction"instrument
"1" ,"m/BGM_05.ogg" , "SAM/music_thumb.bmp", "陽春"
"1" ,"m/BGM_06.ogg" , "SAM/music_thumb.bmp", "沙友"
"1" ,"m/BGM_07.ogg" , "SAM/music_thumb.bmp", "透花 op02"
"1" ,"m/BGM_08.ogg" , "SAM/music_thumb.bmp", "透花"
"1" ,"m/BGM_09.ogg" , "SAM/music_thumb.bmp", "エマ op02"[/quote]
这些列表能提供足够信息解出相当多的资源,例如说背景音乐、CG等。但有些重要的资源文件名却不在*.def里,像是我们关心的脚本文件。
[url=http://rednaxelafx.iteye.com/blog/149811]前一篇[/url]里介绍了如何将Quartett!的二进制脚本转变回到一般可读的形式,这里就稍微说明一下我是如何从解出来的脚本中得到一份脚本里引用过的文件列表。
从前一篇的分析可以知道,token类型为0x83的是字符串token。在FFD脚本里,好几种内容都可能会是字符串类型:1、剧情文本;2、一般参数,如图像渐变的模式"Fade",图像的形状"Rect"之类;3、资源文件路径;等等。不进行文法分析的话,没有办法准确判断这些字符串中到底哪些代表资源文件的路径。但有些偷懒的方式可以试试。
我浏览了一下Quartett!的脚本,假定其引用的资源文件路径中必然有分隔符“.”。但是有一些剧情文本里也有“.”,为了尽量排除掉它们,我写了这样的判断方法:
static bool Match( string tokenString ) {
return ( tokenString.Contains( "." ) && !tokenString.Contains( "..." )
&& !tokenString.Contains( ">.." ) && !tokenString.Contains( ",.." )
&& !tokenString.Contains( "..<" ) && !tokenString.Contains( "\u3000.." )
) || tokenString.Contains( "<IMG" );
}
将前一篇里提到的“反编译器”稍微修改了一下,让它收集所有脚本中满足上面的判断的token,并输出到一个单一的文本文件中。
于是得到了类似这样的一个文件:
(片段)
[code]../
Script/BaseInstruction.txt
Back/Lesson01.bmp
<FONT size=18 face='G'>フィル君.<BR>まだ<TYPE interval=500 speed=500 style='Spring'>~
I/100221/0221-#03b-02-2.bmp
BGM/B02_Juni.ogg
I/100221/0221-#03b-02-3.bmp
I/100221/0221-#03b-02-4.bmp
I/100221/0221-#03b-03-1.bmp
Face/Juni11R.png
<TYPE interval=55 style='Fade'>なっ ..なんて<BR>わかりやすい<BR>ゴマカシを・・・・・・ <TYPE style='Fade'><IMG src='Em/Ase18.png'>[/code]
使用UltraEdit打开该文件,并使用文件->排序->高级排序/选项。选择“升序”和“删除重复”,并开始排序。对这里的例子排序的话,结果是:
[code]../
<FONT size=18 face='G'>フィル君.<BR>まだ<TYPE interval=500 speed=500 style='Spring'>~
<TYPE interval=55 style='Fade'>なっ ..なんて<BR>わかりやすい<BR>ゴマカシを・・・・・・ <TYPE style='Fade'><IMG src='Em/Ase18.png'>
BGM/B02_Juni.ogg
Back/Lesson01.bmp
Face/Juni11R.png
I/100221/0221-#03b-02-2.bmp
I/100221/0221-#03b-02-3.bmp
I/100221/0221-#03b-02-4.bmp
I/100221/0221-#03b-03-1.bmp
Script/BaseInstruction.txt[/code]
可以看到,如果有重复的资源文本,它们已经被UltraEdit清除掉了。而且有一些我们所不关心的内容也堆在了一起,可以方便的选取并删除。
这里我们对FONT和TYPE标签都没兴趣,但在实际删除它们之前,留意到有些行里有IMG标签,里面有我们感兴趣的src属性指向的是资源文件,得留下。这部分我是自己做了苦力,在UltraEdit里逐个搜索<IMG src并将与其在同一行上的非文件路径内容都删除掉。再做一个排序,确认所有IMG标签都处理好了,然后把FONT、TYPE等标签,以及排在后面的纯剧情文本都删除掉。
经过处理,提取出来的记录里就只剩下这样的内容了:
[code]BGM/B01_Charlotte.ogg
BGM/B02_Juni.ogg
BGM/B03_Shuhua.ogg
BGM/B04_MyHome.ogg
BGM/B05_Serious.ogg
BGM/B07_AcademiaMusicae1.ogg
BGM/B08_AcademiaMusicae2.ogg
BGM/B09_AcademiaMusicae3.ogg
BGM/B10a_Bar1.ogg
BGM/B10b_Bar2.ogg
BGM/B11a_Title.ogg[/code]
我把这样的文件列表给了汉公,但之后又得到了新的要求:要把这个列表按归档文件拆分开来。
这是件简单的事。首先得知道路径上什么是归档的文件名,什么是归档里内容的文件名。通过分析,发现路径上最后一个/之后的是归档里内容的文件名,而在那之前的都是归档自身的路径。于是写了个简短的程序来对文件列表做二次处理:
split.cs
// split.cs, 2007/12/21
// by RednaxelaFX
/*
* Copyright (c) 2007 着作权由RednaxelaFX所有。着作权人保留一切权利。
*
* 这份授权条款,在使用者符合以下三条件的情形下,授予使用者使用及再散播本
* 软件包装原始码及二进位可执行形式的权利,无论此包装是否经改作皆然:
*
* * 对于本软件源代码的再散播,必须保留上述的版权宣告、此三条件表列,以
* 及下述的免责声明。
* * 对于本套件二进位可执行形式的再散播,必须连带以文件以及/或者其他附
* 于散播包装中的媒介方式,重制上述之版权宣告、此三条件表列,以及下述
* 的免责声明。
* * 未获事前取得书面许可,不得使用RednaxelaFX之名称,
* 来为本软件之衍生物做任何表示支持、认可或推广、促销之行为。
*
* 免责声明:本软件是由RednaxelaFX以现状("as is")提供,
* 本软件包装不负任何明示或默示之担保责任,包括但不限于就适售性以及特定目
* 的的适用性为默示性担保。RednaxelaFX无论任何条件、
* 无论成因或任何责任主义、无论此责任为因合约关系、无过失责任主义或因非违
* 约之侵权(包括过失或其他原因等)而起,对于任何因使用本软件包装所产生的
* 任何直接性、间接性、偶发性、特殊性、惩罚性或任何结果的损害(包括但不限
* 于替代商品或劳务之购用、使用损失、资料损失、利益损失、业务中断等等),
* 不负任何责任,即在该种使用已获事前告知可能会造成此类损害的情形下亦然。
*/
using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
sealed class Splitter {
static void Main( string[ ] args ) {
if ( !File.Exists( args[ 0 ] ) ) return;
string infilelist = args[ 0 ];
// get the file names and sort them out by the archive they belong to
// paths that doesn't seem to be in an archive are ignored
Dictionary<string, List<string>> dic = new Dictionary<string, List<string>>( );
using ( StreamReader reader = new StreamReader(
File.OpenRead( infilelist ), Encoding.GetEncoding( "utf-16le" ), true ) ) {
string line = null;
while ( ( line = reader.ReadLine( ) ) != null ) {
int seperateIndex = line.LastIndexOf( "/" );
if ( -1 == seperateIndex ) continue;
string path = line.Substring( 0, seperateIndex );
string filename = line.Substring( seperateIndex + 1 );
if ( dic.ContainsKey( path ) ) {
List<string> list = dic[ path ];
list.Add( filename );
} else {
List<string> list = new List<string>( );
list.Add( filename );
dic.Add( path, list );
}
} // while
} // using
// write the file lists out
foreach ( string path in dic.Keys ) {
int seperateIndex = path.LastIndexOf( "/" );
if ( -1 != seperateIndex ) {
Directory.CreateDirectory( path.Substring( 0, seperateIndex ) );
}
using ( StreamWriter writer = new StreamWriter(
File.Create( path + ".lst" ), Encoding.GetEncoding( 932 ) ) ) {
foreach( string filename in dic[ path ] ) {
writer.WriteLine( filename );
} // foreach
} // using
} // foreach
}
}
完事。来看看其中一个分离出来的lst文件长什么样:
Face.lst
[code]Char01L.png
Char04L.png
Char04R.png
Char15L.png
Gise12R.png
Gise17R.png
Hans03L.png
Hans03R.png
Juni05R.png
Juni10L.png
Juni10R.png
Juni11R.png
Lina02L.png
Lina06L.png
Lina06R.png
May15L.png
May16R.png
Phil00L.png
Phil00R.png
Phil02L.png
Phil02R.png
Phil03L.png
Phil03R.png
Phil04L.png
Phil04R.png
Phil05R.png
Phil07L.png
Phil07R.png
Phil12L.png
Shuh00R.png
Shuh11R.png
Sign09R.png
Sign10R.png[/code]
嗯,基本上满足要求了。
==========================================================
进一步的精确分析确实需要写出parser来做。我现在肯定是没时间做,不过计划以后做的时候用ANTLR来完成。难点是要设计出一个精确的上下文无关文法。到时候再说吧~