查看完整版本: [-- [原创/更新]TransText 2.2.264 - 字符串提取、回写以及替换工具 --]

汉化新世纪论坛 -> 汉化工具 -> [原创/更新]TransText 2.2.264 - 字符串提取、回写以及替换工具 [打印本页] 登录 -> 注册 -> 回复主题 -> 发表主题

<<   1   2   3  >>  Pages: ( 3 total )

Yonsm 2007-04-17 00:01

[原创/更新]TransText 2.2.264 - 字符串提取、回写以及替换工具

更新了TransText,加入了最新  Android 4.0 风格的 UTF-8 前导个数的字符串格式支持,修改了程序UI,更直观的地设置字符串格式。

功能:

1. 提取英文字符串,保存为 PASSOLO 支持的 INI 格式,以便工程化翻译(供汉化工作者使用)。
2. 回写英文字符串。
3. 查找和替换字符串。
4. 所有操作均支持文件或文件夹批量处理,支持通配符搜索文件。
5. 全面支持 BSTR (带长度的字符串模式)提取、回写和搜索。2.0 新增

6. 支持 Visual Studio 2005/2008 项目文件转换(小功能):拖动.sln文件到“搜索”页面时,自动检测 Visual Studio 2005/2008 方案文件,并询问是否转换方案和工程文件的格式(2005/2008互转)。

[attachment=30904]


最新版本,2.2.264(包含源代码):http://www.yonsm.net/post/316

[attachment=30903]  (VS 2012 编译,好多人都说XP中不行运行,仔细了解后发现,目前只能用Visual Studio 2010来编译才能支持XP。2012要等晚些时候微软会发布一个新的update才能支持XP运行程序的编译。我懒得去下载了2010了,有需要的自己编译一下吧,源代码一直都公开的。)


补充,88楼的网友编译的XP可运行,91楼我有补充新老版本的源代码和VS2010的编译方法。

终于可以大规模工业化汉化 Android 程序了TransText 提取,配合 Passolo,完美实现……
从此可以不用小打小闹了。汉化最怕的就是不能重用资源,利用Passolo的强大功能可以解决这个问题。但Passolo并不支持 Android 的资源文件,配合TransText就行了,步骤大概是:
1. 用 TransText 提取 .arsrc的字符串(勾选UNICODE字符串模式,勾选带长度的字符串模式,只提取英文字符串也可以勾选,避免其他字符串)

2. 用 Passolo 添加 .ttt 文件看工程中(建议创建 .ttt 文件的规则,复制INI规则既可,或者不会的话,直接把 .ttt改名为.ini),汉化ttt文件并输出汉化后的文件。(同时把汉化后的字典导出保存一下,下次升级后再用)

3.用 TransText 回写Passolo的输出ini(ttt)到.arsrc中,重新打包apk即可。

感谢 汉化新世纪 乾(qian.hanzify.org)在此工具制作过程中的意见和建议。


2007-04-17 01:30
这两天在等你这个工具了,呵呵
看中的不是转换,而是提取,希望多一些提取方面的功能。比如能够提取非PE文件(目前会出错),能够实现不截断强制加长写入--目前都是为了安全,不能写入超过原长度的字串,事实上一些非PE格式的特异语言包,是可以允许加长写入的。这个功能可以作为可选项嘛,需要时勾选,默认是禁止。

http://teach.hanzify.org/index.php?Go=Show::637-1176744394

gnatix 2007-04-17 07:38
PE文件非标准资源的汉化:
1) 用点睛提取PE文件的 ASCII 或者 Delphi 或者 Unicode 字串,生成 XXX.a.txt 或者 XXX.d.txt 或者 XXX.u.txt 文件。
2) 用 Passolo 的文本文件解析器直接汉化上述文本文件(Passolo 汉化版中已包含有所需的文本解析规则)。
3) 用点睛的替换功能重新回写汉化了的字串。

Yonsm 2007-04-17 10:41
QUOTE(乾 @ 2007年 04月 17日 01时 30分) [snapback]328699[/snapback]

这两天在等你这个工具了,呵呵
看中的不是转换,而是提取,希望多一些提取方面的功能。比如能够提取非PE文件(目前会出错),能够实现不截断强制加长写入--目前都是为了安全,不能写入超过原长度的字串,事实上一些非PE格式的特异语言包,是可以允许加长写入的。这个功能可以作为可选项嘛,需要时勾选,默认是禁止。

http://teach.hanzify.org/index.php?Go=Show::637-1176744394
  • 提取方面,仔细看了想了,如果不使用反汇编代码段的方法,肯定会有很多非 UI 字符串的,反汇编的提取方法后面再看看。毕竟垃圾串太多不方便使用 PASSOLO 的字典全部翻译。
  • 现在也可以提取非 PE 文件的,如果会出错,那是程序的BUG,烦请告知处理什么文件出错:)——哦,非PE文件,现在不要选取智能提取的 CheckBox,这些小毛病马上会改掉的。
  • 能够实现不截断强制加长写入
    >>这个现在就能的,每个词条前面是Offset,Size=String,Size 就是最大长度。遇到了最大长度后,TransText 不会写入后面超常的部分——或许,此时应该给出一个警告。
  • 事实上一些非PE格式的特异语言包,是可以允许加长写入的。这个功能可以作为可选项嘛,需要时勾选,默认是禁止。>>这个……目前可以用这种方法解决:修改 Offset,Size=String 中 Size 的大小,10 进制的。如果需要全部修改,可以用 UE 替换“????=”为"9999="即可。后面我会考虑加入选项。
QUOTE(gnatix @ 2007年 04月 17日 07时 38分) [snapback]328706[/snapback]

PE文件非标准资源的汉化:
1) 用点睛提取PE文件的 ASCII 或者 Delphi 或者 Unicode 字串,生成 XXX.a.txt 或者 XXX.d.txt 或者 XXX.u.txt 文件。
2) 用 Passolo 的文本文件解析器直接汉化上述文本文件(Passolo 汉化版中已包含有所需的文本解析规则)。
3) 用点睛的替换功能重新回写汉化了的字串。


傻眼了我:)
以前也尝试过这样做,但点睛我总是没琢磨出怎么好用。你汉化的 PASSOLO 我一直在用,多谢!

顺便问一下,大家觉得那款软件在 非标提取 方面做得最好?我可以作为目标参考一下,否则做出来的东西必现有的差,那是白费工夫了。

HYQ9 2007-04-17 10:52
1、加入可提取中文字符的可选选项。

2、提取的 ini 文件,允许用户整行整行的删除不需要汉化的字符,把整理过的 ini 文件再用 PASSOLO 翻译,然后再写回 PE 文件中。我没有试,不知道有没有这个功能?如果有,再添加一个可以编辑 ini 文件的编辑器,能方便的删除不需要汉化的行。

2007-04-17 11:30
QUOTE
能够实现不截断强制加长写入
>>这个现在就能的,每个词条前面是Offset,Size=String,Size 就是最大长度。遇到了最大长度后,TransText 不会写入后面超常的部分——或许,此时应该给出一个警告。

我需要的是能强制写入,最好是做个总的选择项,平时不勾,勾上就不管任何情况都强制超长写入。
QUOTE
肯定会有很多非 UI 字符串的,反汇编的提取方法后面再看看。毕竟垃圾串太多不方便使用 PASSOLO 的字典全部翻译。

建议不要在这方面花太多精力,干扰字串肯定是有的,只要能实现
QUOTE
允许用户整行整行的删除不需要汉化的字符
,我觉得就可以了。让汉化人自己去判断吧。毕竟不同类型的非标太多了,尤其面对非PE格式,这个不值得太费神


QUOTE
1、加入可提取中文字符的可选选项。

区分简繁?提取日文?要求太多了,呵呵

黑色开裆裤 2007-04-17 11:36
同意乾的说法,能提取非PE文件最好!

Yonsm 2007-04-17 11:49
QUOTE(黑色开裆裤 @ 2007年 04月 17日 11时 36分) [snapback]328726[/snapback]

同意乾的说法,能提取非PE文件最好!



可以提取 非 PE,取消智能提取就可以了。我马上修改了,不需要取消这个也能提取非PE了。还没有上传。

QUOTE(HYQ9 @ 2007年 04月 17日 10时 52分) [snapback]328716[/snapback]

1、加入可提取中文字符的可选选项。

2、提取的 ini 文件,允许用户整行整行的删除不需要汉化的字符,把整理过的 ini 文件再用 PASSOLO 翻译,然后再写回 PE 文件中。我没有试,不知道有没有这个功能?如果有,再添加一个可以编辑 ini 文件的编辑器,能方便的删除不需要汉化的行。


1.暂时不想做这个了,主要是为了汉化。如果需要,可以支持更强大的提取规则,比如正则表达式或者,连续多少个英文字符,连续多少个汉字等等的。

2. 编辑器还是个人用个人喜欢的好,用记事本就可以整行整行的删除。

QUOTE
1.我需要的是能强制写入,最好是做个总的选择项,平时不勾,勾上就不管任何情况都强制超长写入。

马上加
QUOTE
2.建议不要在这方面花太多精力,干扰字串肯定是有的,只要能实现

也是,后面再说
QUOTE
3.我觉得就可以了。让汉化人自己去判断吧。毕竟不同类型的非标太多了,尤其面对非PE格式,这个不值得太费神


QUOTE
4.区分简繁?提取日文?要求太多了,呵呵

暂时先放放,如果确实很需要,可以支持提取规则。但我觉得最重要的还是提取英文,其它的用的很少,对我来说几乎没有用。

wanfu 2007-04-17 13:04
你好!同乡!辛苦了。
测试了一下Unicode的提取和回写,基本可以。但是希望补充:
1、有的提取不正确,如(xxx),只提取了xxx),xPush Button(x是控制符)应该只提取Push Button。
2、回写没有选择,应该是二种选择,不到原字串长度的用“00”或“20”替换。
3、建议增加回写检测功能(除了偏移量外,如果原字符串和翻译中的原字符串一样,则回写),以及超长字符被截断时,写入回写日子并提示。
建议看看点晴助手的帖子

黑色开裆裤 2007-04-17 13:12
[quote name='Yonsm' date='2007年 04月 17日 11时 49分' post='328727']
[quote name='黑色开裆裤' post='328726' date='2007年 04月 17日 11时 36分']
同意乾的说法,能提取非PE文件最好!
[/quote]


可以提取 非 PE,取消智能提取就可以了。我马上修改了,不需要取消这个也能提取非PE了。还没有上传。

太好了,这样估计能用来汉化S系统的手机软件了!赞!

Yonsm 2007-04-17 15:25
QUOTE(wanfu @ 2007年 04月 17日 13时 04分) [snapback]328736[/snapback]

你好!同乡!辛苦了。
测试了一下Unicode的提取和回写,基本可以。但是希望补充:
1、有的提取不正确,如(xxx),只提取了xxx),xPush Button(x是控制符)应该只提取Push Button。
2、回写没有选择,应该是二种选择,不到原字串长度的用“00”或“20”替换。
3、建议增加回写检测功能(除了偏移量外,如果原字符串和翻译中的原字符串一样,则回写),以及超长字符被截断时,写入回写日子并提示。
建议看看点晴助手的帖子


1. (xxx) 只提取了 xxx),这是因为我认为所有的翻译都是从英文字母开始的。这个提取规则,我正在考虑支持按表达式提取。
2.有选择,填充字符的值就是。32 就是0x20,表示填充空格。
3.正在完善中。

曾半仙 2007-04-17 15:39
tahoma rocks~~!!

2007-04-17 18:47
QUOTE
2. 编辑器还是个人用个人喜欢的好,用记事本就可以整行整行的删除。

我理解的整行是类似PA或其他类似的专用点睛编辑器那样——一个整行包括原文跟英文,还或许包括对应的空行,这样一次删掉三行,用来排除干扰字串就高效了。最好有复制功能,也是这样的“整行”复制

Yonsm 2007-04-19 03:27
深夜 3:25 了,没有精力做完整测试了,过两天我会发布正式版本。如有兴趣大家请先尝试看看,有问题请在此留言。

2007-04-19 04:31
辛苦辛苦,我也刚写完工作报告
帮你测试了一下,模拟飞行里面的非标,只测试一个字串,提取写入都正常,用PA设规则也很简单。
只是有一个不足:回写只有目标文件的路径,没有翻译文件ttt的路径,而PA默认生成到chs里面,即使不生成到子文件夹,也需要手动先备份原始ttt等等,这里建议学点睛,可以另外指定ttt。
另,有关不检查超长字串,今天暂时没有方法测试。不过有个新想法:当设置为不检查超长字串时,是否可以再增加一个选择--字串长度位置?
比如1600ABCDERYU...,这里16是长度控制,中间00是一个间隔,也有类似16000000ABCDERYU,中间有三个00间隔。
此时,只需让汉化人选长度控制是置前还是置后(好像没有后的吧?),间隔多少个00,然后写入时自动计算写入的超长长度,把16自动写为新的长度即可。

再次感谢辛苦劳动。

Yonsm 2007-04-19 10:32
QUOTE(乾 @ 2007年 04月 19日 04时 31分) [snapback]328873[/snapback]

辛苦辛苦,我也刚写完工作报告
帮你测试了一下,模拟飞行里面的非标,只测试一个字串,提取写入都正常,用PA设规则也很简单。
只是有一个不足:回写只有目标文件的路径,没有翻译文件ttt的路径,而PA默认生成到chs里面,即使不生成到子文件夹,也需要手动先备份原始ttt等等,这里建议学点睛,可以另外指定ttt。
另,有关不检查超长字串,今天暂时没有方法测试。不过有个新想法:当设置为不检查超长字串时,是否可以再增加一个选择--字串长度位置?
比如1600ABCDERYU...,这里16是长度控制,中间00是一个间隔,也有类似16000000ABCDERYU,中间有三个00间隔。
此时,只需让汉化人选长度控制是置前还是置后(好像没有后的吧?),间隔多少个00,然后写入时自动计算写入的超长长度,把16自动写为新的长度即可。

再次感谢辛苦劳动。



晕!还有更晚的!

1. chs 目录和 ttt 的问题:以前是有的,可指定的。但是后来我决定取消掉,因为现在是支持批量操作的,不好指定ttt的路径。就是说你可以批量提取 D:\Hanzify\*.exe;*gui.dll,回写也是,搜索也是,均支持批量文件。

我的想法是:

1) 先用 PASSOLO 汉化 .\A.EXE 标准资源,得到 .\chs\A.EXE;
2) 用 TransText 提取 .\chs\A.EXE 为 .\chs\A.EXE.ttt;
3) 复制 .\chs\A.EXE.ttt -> .\A.EXE.ttt;
4) 用 PASSOLO 汉化它,直接生成 .\chs\A.ttt,正好供 TransText 使用。

不知乾兄以为如何。

2. “新想法”暂时没怎么看明白:)

尚需工作:
1. 完整性和正确性测试。
2. 支持三行文本,以便无缝升级。
3. 支持按表达式规则提取(不一定会实现)。

2007-04-19 11:10
你的意思是软件只支持搜索chs目录?我还打算用来做非标繁体的,那还得手动改cht为chs?
我的想法是:既然有ini配置文件,能否利用这个配置文件让汉化人来设置?
举例:
;是否自动搜索ttt子文件夹(1-自动搜索,0-允许手动)
autoseek=0
;指定可搜索的子文件夹名称
seekpath=chs;cht;zh;zht
[attachmentid=23083]

这样可以自由一点,用来搭配Mu的ZH、zht目录也是可行的,方便不同工具的习惯用户

Yonsm 2007-04-19 11:19
再次仔细看了一下乾兄的意思,不知道我有没有没怎么理解正确:想在翻译字符串中的前面或中间填充 NULL 字符。这点现在可以实现的,请使用转义字符即可:“\0”

转义字符支持:
\r:回车
\n:换行
\t:制表符
\0:空字符
\x:自定义十六进制字符(字符码值),如“\xFF\xFE\x20ABCDE“。注意,使用了 \x???? 后,必须用非数字的字符跟紧,如前面的A;如果是数字,可以用\转义,如“\xFF\xFE\9”= FF FE 39。





QUOTE(乾 @ 2007年 04月 19日 11时 10分) [snapback]328897[/snapback]

你的意思是软件只支持搜索chs目录?我还打算用来做非标繁体的,那还得手动改cht为chs?
我的想法是:既然有ini配置文件,能否利用这个配置文件让汉化人来设置?
举例:
;是否自动搜索ttt子文件夹(1-自动搜索,0-允许手动)
autoseek=0
;指定可搜索的子文件夹名称
seekpath=chs;cht;zh;zht
[attachmentid=23083]

这样可以自由一点,用来搭配Mu的ZH、zht目录也是可行的,方便不同工具的习惯用户


我不是这个意思,我只是举例一个汉化过程,想说明并非你所说的不方便,请看看我说的流程(一般来说,我们是提取汉化标准资源之后的 EXE,而不是汉化之前的——尽管使用PE节排除可以排除掉标准资源)。

我说的搜索,是通用的搜索(代码中无特定目录指定,你可以自己指定*.*之类的,以及是否递归子目录),就是说可以批量提取。

2007-04-19 11:26
;长度符控制(0-无长度符,1-长度符置前,2-长度符置后)
;仅当“不检查超长字符串”勾选时有效
strLenctrl=1
;长度符和字串直接的00间隔,以00为单位
intnum=3
[attachmentid=23084]

补充长度符:
;是否自动修改长度符(0-不修改,1-自动修改)
AutoLen=1

QUOTE
我不是这个意思,我只是举例一个汉化过程,想说明并非你所说的不方便,请看看我说的流程(一般来说,我们是提取汉化标准资源之后的 EXE,而不是汉化之前的——尽管使用PE节排除可以排除掉标准资源)。

明白了

Yonsm 2007-04-19 11:29
QUOTE(乾 @ 2007年 04月 19日 11时 26分) [snapback]328901[/snapback]

;长度符控制(0-无长度符,1-长度符置前,2-长度符置后)
;仅当“不检查超长字符串”勾选时有效
strLenctrl=1
;长度符和字串直接的00间隔,以00为单位
intnum=3
[attachmentid=23084]

补充长度符:
;是否自动修改长度符(0-不修改,1-自动修改)
AutoLen=1

QUOTE
我不是这个意思,我只是举例一个汉化过程,想说明并非你所说的不方便,请看看我说的流程(一般来说,我们是提取汉化标准资源之后的 EXE,而不是汉化之前的——尽管使用PE节排除可以排除掉标准资源)。

明白了


晕了,我真的没看明白,白费你的对话框截图心思了:)

另外不知道有没有人可告知一下:点睛和点睛助手中所指的 VA 方式提取具体是指什么?大概怎么做到?想来他们用 VB 和 E 做的,应该不会反汇编:)

2007-04-19 11:30
再说ini,希望增加打开文件类型的自定义:
;此处可自定义文件类型扩展名称
ext1=*.exe;*.dll
exetxt1=可执行文件
ext2=*.lng;*.abc
exetxt2=语言包文件

这样可以适合很多非标文件,汉化人自行定义

Yonsm 2007-04-19 11:32
QUOTE(乾 @ 2007年 04月 19日 11时 26分) [snapback]328901[/snapback]

;长度符控制(0-无长度符,1-长度符置前,2-长度符置后)
;仅当“不检查超长字符串”勾选时有效
strLenctrl=1
;长度符和字串直接的00间隔,以00为单位
intnum=3
[attachmentid=23084]

补充长度符:
;是否自动修改长度符(0-不修改,1-自动修改)
AutoLen=1

QUOTE
我不是这个意思,我只是举例一个汉化过程,想说明并非你所说的不方便,请看看我说的流程(一般来说,我们是提取汉化标准资源之后的 EXE,而不是汉化之前的——尽管使用PE节排除可以排除掉标准资源)。

明白了



哈哈,有点明白了,你是不是指,比如VB字符串的格式,[长度][数据]这种?希望 TransText 在修改[数据]后,自动调整[长度]?

因为我对 VB 之类的程序一直不感冒,几乎没有汉化或破解过。所以一时没想到这里去。现在想到了,不知是否符合你的意思?

2007-04-19 11:32
QUOTE
晕了,我真的没看明白,白费你的对话框截图心思了:)

是我的问题,我找个例子

Yonsm 2007-04-19 11:33
QUOTE(乾 @ 2007年 04月 19日 11时 30分) [snapback]328903[/snapback]

再说ini,希望增加打开文件类型的自定义:
;此处可自定义文件类型扩展名称
ext1=*.exe;*.dll
exetxt1=可执行文件
ext2=*.lng;*.abc
exetxt2=语言包文件

这样可以适合很多非标文件,汉化人自行定义


OK!

2007-04-19 11:52
类似这种,这个03就是长度符。如果把OK改成“确定”,就要修改长度符,否则就会截断。我的希望是强制写入“确定”后,还能自动计算(应该用超出的长度加到原来长度上),把03自动改成05。
同时,这个例子中,03和OK间有3个00间隔,但不同软件是不同的,有些是一个00,有些是两个00,还有更长的。我想等汉化人手动分析完后,可以设置这几个内容,这样回写时就方便了。

曾经跟一个网友探讨过自动处理超长字串的情况,所以一直有这些想法。不过我也知道很复杂。我上面说的情况其实不能针对PE,反而主要是针对一些特异的非PE文件,允许修改者任意加长文件长度的。这种例子有,但不多——其实主要是我现在汉化的微软飞行就很多这种文件

不过,如果能够实现,还是有一定用处的。比如按这里的方案:http://teach.hanzify.org/index.php?Go=Show::317-1065888000
类似这种方案,如果能够对字符串长度有一些处理的作用,对于VB汉化或许还是有帮助的。VB汉化目前的可视化工具还是不好用,宁愿当非标算了。

QUOTE
因为我对 VB 之类的程序一直不感冒,几乎没有汉化或破解过。所以一时没想到这里去。现在想到了,不知是否符合你的意思?

先放着吧,把主要功能完善、稳定了,以后再说,只是提个想法。

Yonsm 2007-04-19 12:00
QUOTE(乾 @ 2007年 04月 19日 11时 52分) [snapback]328907[/snapback]

类似这种,这个03就是长度符。如果把OK改成“确定”,就要修改长度符,否则就会截断。我的希望是强制写入“确定”后,还能自动计算(应该用超出的长度加到原来长度上),把03自动改成05。
同时,这个例子中,03和OK间有3个00间隔,但不同软件是不同的,有些是一个00,有些是两个00,还有更长的。我想等汉化人手动分析完后,可以设置这几个内容,这样回写时就方便了。

曾经跟一个网友探讨过自动处理超长字串的情况,所以一直有这些想法。不过我也知道很复杂。我上面说的情况其实不能针对PE,反而主要是针对一些特异的非PE文件,允许修改者任意加长文件长度的。这种例子有,但不多——其实主要是我现在汉化的微软飞行就很多这种文件

不过,如果能够实现,还是有一定用处的。比如按这里的方案:http://teach.hanzify.org/index.php?Go=Show::317-1065888000
类似这种方案,如果能够对字符串长度有一些处理的作用,对于VB汉化或许还是有帮助的。VB汉化目前的可视化工具还是不好用,宁愿当非标算了。

QUOTE
因为我对 VB 之类的程序一直不感冒,几乎没有汉化或破解过。所以一时没想到这里去。现在想到了,不知是否符合你的意思?

先放着吧,把主要功能完善、稳定了,以后再说,只是提个想法。


终于理解对了,和你差不多的意思。
但我想知道的是,这种超长字串,回写后,文件不会不变长?
TransText 现在处理的都是文件不会变长的,这样方便使用内存映射文件。现在 TT 是不用载入整个文件的。

2007-04-19 12:04
上次深圳那个网友说,可以让软件智能判断PE文件内部大量00的地方,然后砍那里的字节。本来他希望拿到STA源代码来改进,联系原作者数次不果,这个议题就放下了。
我这次处理的文件,倒是不担心文件变长,所以就私心了一把

Yonsm 2007-04-19 12:18
QUOTE(乾 @ 2007年 04月 19日 12时 04分) [snapback]328913[/snapback]

上次深圳那个网友说,可以让软件智能判断PE文件内部大量00的地方,然后砍那里的字节。本来他希望拿到STA源代码来改进,联系原作者数次不果,这个议题就放下了。
我这次处理的文件,倒是不担心文件变长,所以就私心了一把


判断大量 00 是不保险的。且引用字符串的地方还需要更改。如果是这样的话,还不如增加一个 PE Section。
呵呵~~有点扯远了

我一般很少遇到这种情况,如果确实需要,具体遇到这样的软件时候再分析吧。如有需要,到时候联系我作特别的/不通用的版本——当然,如果支持通用提取规则的话,写入规则我会考虑支持这个。

2007-04-19 16:43
几个提取工具都各有特色,所以最好能有新的亮点。
我觉得规则的丰富、完善是个突破点。

还可增加:ttt的关联设置,设置好关联的编辑程序,直接按编辑即可马上调用,这个可以用来删除干扰字串然后再让PA整体处理。
嗯,批量提取、删除是个新亮点,可以写个完整的非标汉化方案了。

Yonsm 2007-04-20 12:43
QUOTE(乾 @ 2007年 04月 19日 16时 43分) [snapback]328943[/snapback]

几个提取工具都各有特色,所以最好能有新的亮点。
我觉得规则的丰富、完善是个突破点。

还可增加:ttt的关联设置,设置好关联的编辑程序,直接按编辑即可马上调用,这个可以用来删除干扰字串然后再让PA整体处理。
嗯,批量提取、删除是个新亮点,可以写个完整的非标汉化方案了。


更新了一下,暂时到此为止了。
我的想法是自己用着方便即可,如果需要做成专业产品,可能取名叫 TranStudio ——一个用来提取,编辑,回写字符串的完整工具(类似 PASSOLO,但处理方式是作为非标字串处理)。但没有精力去做了,比较耗时,用处也不多:)

2007-04-20 13:34
很不错了。方便的话,直接在主页上发布吧

Yonsm 2007-04-20 23:00
我先用两个星期,再准备些文档再发布。初衷也是小范围内使用就行了,毕竟不是大家通用的工具。

2007-04-20 23:22
以前用点睛和cxa,要跟练魔兽微操作一样,左手键盘,右手鼠标,快捷键切换到编辑,切换到替换...现在批量写出写入,上百个文件都不累了。。。
微软飞行那玩意,我正头疼,今天就把118个文件(这还只是其中一部分而已)统一处理了,也不用再担心逐个翻译用词不统一,确实好。
大范围用用也无妨,本来汉化人就是小范围了,莫担心,哈哈

Yonsm 2007-04-21 16:42
QUOTE(乾 @ 2007年 04月 20日 23时 22分) [snapback]329121[/snapback]

以前用点睛和cxa,要跟练魔兽微操作一样,左手键盘,右手鼠标,快捷键切换到编辑,切换到替换...现在批量写出写入,上百个文件都不累了。。。
微软飞行那玩意,我正头疼,今天就把118个文件(这还只是其中一部分而已)统一处理了,也不用再担心逐个翻译用词不统一,确实好。
大范围用用也无妨,本来汉化人就是小范围了,莫担心,哈哈


多谢赞誉:)
我的意思我不是用的人多不好,恰恰相反。汉化人不多,用的人不多(看这个贴子,似乎全天下只有我们两个在讨论,可见一斑:),所以我没有动力去做我不太用的到的功能。
我多次在BLOG中说这样的话,我做的任何东西的出发点都是我自己要用。然后如果可能,我希望其他更多的人能用到。汉化同仁毕竟还是少数。

另外,这个批量处理,其实就一个函数(但蛮满精妙的,确实花了些心思),以后我写类似的小工具的时候我都会支持类似的功能,毕竟有时候一点点小功能却能方便很多。

另外, 微软飞行,是那款模拟飞行的游戏吧?我玩过一下下2004版本,觉得挺有意思。不知道什么时候有乾兄的汉化版本(2007?)出来?

2007-04-21 16:47
http://www.fsxcn.com.cn/bbs/index.php
只是加入一个汉化小组,我负责界面部分,游戏教学那些我可不懂

不过这次介入,感觉微软的东西还是比较容易有迹可循,所以以后可以碰碰微软的游戏。

Yonsm 2007-04-21 17:21
QUOTE(乾 @ 2007年 04月 21日 16时 47分) [snapback]329200[/snapback]

http://www.fsxcn.com.cn/bbs/index.php
只是加入一个汉化小组,我负责界面部分,游戏教学那些我可不懂

不过这次介入,感觉微软的东西还是比较容易有迹可循,所以以后可以碰碰微软的游戏。



hoho`~竟然工程化协作了。其实我一向觉得汉化缺的就是这样的团队运作。非专业化操作都是小打小闹,特别是一看到用 ResHacker 和 eXeScope(正如你的签名中强调的) 来作为汉化的(SP和PPC上,这样操作的人不少)就晕。

Flight Simulator X 这个版本估计我的及其跑不起来,不知道好不好玩。正想下个看看。

2007-04-21 17:41
把效果调低一下应该可以的,好像说下net frame work 3.0会快很多
http://www.fsxcn.com.cn/?action_viewthread_tid_34.html

黑色开裆裤 2007-04-21 23:53
多谢赞誉:)
我的意思我不是用的人多不好,恰恰相反。汉化人不多,用的人不多(看这个贴子,似乎全天下只有我们两个在讨论,可见一斑:),所以我没有动力去做我不太用的到的功能。
我多次在BLOG中说这样的话,我做的任何东西的出发点都是我自己要用。然后如果可能,我希望其他更多的人能用到。汉化同仁毕竟还是少数。

这个应该关注的人很多,因为在这方面的工具是在是太少了,点睛也好久没有更新了!希望作者能更新下去!

2007-04-23 08:59
http://qian.hanzify.org/nhc.rar

这个软件是U码的,长度符紧贴第一个字母,所以造成无法提取,帮忙看看,比如:
37520065006600720065007300680020004200610074007400650072007900200049006E0066006F0072006D006100740069006F006E00

37就是长度符,连00间隔都没有了。

Yonsm 2007-04-23 12:55
QUOTE(乾 @ 2007年 04月 23日 08时 59分) [snapback]329410[/snapback]

http://qian.hanzify.org/nhc.rar

这个软件是U码的,长度符紧贴第一个字母,所以造成无法提取,帮忙看看,比如:
37520065006600720065007300680020004200610074007400650072007900200049006E0066006F0072006D006100740069006F006E00

37就是长度符,连00间隔都没有了。


因为我做了一个假定:UNICODE 字符串都是开始于偶数Offset——VC 编译出来的程序都是这样的。

我改写一下。

这种系统软件竟然用 .NET 编写的,启动真慢。

Yonsm 2007-04-23 13:11
不仅仅如此,还因为这种字符串不是用什么字符(不是NULL,也不是 $ 之类的)作为结尾的,而是依靠 37 作为长度。

Yonsm 2007-04-23 17:21
已经支持了(.NET 专用——未整合以前的版本)。

但是有个问题Qian兄有没有发现:
1.37520065006600720065007300680020004200610074007400650072007900200049006E0066006F0072006D006100740069006F006E00
2.2A4F00700065006E00530065006D006100700068006F007200650020004500720072006F0072003A002000

第一个字符串,长度是 37,是个奇数,第二个字符串,2A,是个偶数。理论上这两个一类的UNICODE字符串,这个长度到底表示什么?

就是说,我现在有个问题:怎样修正汉化后的长度。如果我按以前的方法不修正只补零的话,显示不正确;补空格的话当然显示不好看。如果修正为字符个数*2,那么永远都不会出来 37 这样的长度。

不知道那个才是对的,就是说现在 提取,然后即使不修改.ttt 文件, 重新回写后,都会造成很多字符串长度相差 1 字节(如上面的字符串 2)。如果都加 1 也不行(如上面的字符串 1)。也不行,郁闷。

不过如果你不选择修改字符串长度,可以用空格来填充,肯定不会有问题,就是难看些。


2007-04-23 21:10
刚才用PEID看到upolyx字样,或是因为加壳吧。
感谢重新修正

Yonsm 2007-04-24 00:27
QUOTE(乾 @ 2007年 04月 23日 21时 10分) [snapback]329488[/snapback]

刚才用PEID看到upolyx字样,或是因为加壳吧。
感谢重新修正



不太明白你的意思,谁加壳?
都没有啊,TransText 没有,你放的那个 .NET 的程序似乎也没有。

另外我想知道TransText这样能不能用于你贴出的软件的非标提取和回写,因为字符长度重写会造成很多变化。


2007-04-24 01:04
我上传那个程序检查出upolyx字样
可能要过些天才详细测试提取写入情况了

曾半仙 2007-04-24 10:45
那是因为某人提供的userdb.txt里面有不良的匹配规则, 导致多个合并了此数据的userdb全部被破坏了.
而那个貌似用IL可以看到是作为数组使用的

2007-04-27 03:45
今天做了批量回写,不错。
有几个想法:
有关超长写入:应该增加一个选项,即是否追加写入,还是覆盖写入。目前是覆盖写入,等于借用了后面的字串。我今天的写入有5个超长,但有两个后面超的较多,后面并非都是00,于是要对照原始文件复制回被覆盖的内容。建议增加追加或覆盖的选项。本例就应该使用追加写入。
关于修改字串长度:我觉得还是放弃算了——该打,前面要求实现的也是我...
本例而言:
原文是:0800000050726F6772616D,字串的真实长度是07,但软件里面长度是+1了,且中间有00间隔。当我使用修改字串长度功能时,没有修改08,而是在字串前面加了长度,且没有+1。
这里还是太复杂了,不如屏蔽掉吧。

再次感谢这个好工具。

Yonsm 2007-04-27 22:28
QUOTE(乾 @ 2007年 04月 27日 03时 45分) [snapback]329836[/snapback]

今天做了批量回写,不错。
有几个想法:
有关超长写入:应该增加一个选项,即是否追加写入,还是覆盖写入。目前是覆盖写入,等于借用了后面的字串。我今天的写入有5个超长,但有两个后面超的较多,后面并非都是00,于是要对照原始文件复制回被覆盖的内容。建议增加追加或覆盖的选项。本例就应该使用追加写入。
关于修改字串长度:我觉得还是放弃算了——该打,前面要求实现的也是我...
本例而言:
原文是:0800000050726F6772616D,字串的真实长度是07,但软件里面长度是+1了,且中间有00间隔。当我使用修改字串长度功能时,没有修改08,而是在字串前面加了长度,且没有+1。
这里还是太复杂了,不如屏蔽掉吧。

再次感谢这个好工具。


又是 3:45!要好好休息呀……

有关超长写入:晕了,又没明白。举个例子先。
修改字串长度:明白。不行就补空格没事:)

也多谢你仔细测试啊。没问题的话,我整理一下发布一下,你看看那些地方还要改(麻烦的功能就不想做了,已经够我用的了:)。

2007-04-28 00:04
原版:
0007000000264779726F3A000900000081
其中264779726F3A是要汉化的英文“&Gyro:”
汉化后的中文为“陀螺效应:”
0007000000CDD3C2DDD0A7D3A63A0081
由于超长较多,吧后面的0009等字串也“覆盖”掉了,而我不能确定这个0009有没有用,于是就从原版中复制,手动修补为(当然,长度符07已手动改为0A):
000A000000CDD3C2DDD0A7D3A63A000900000081

因此,我认为当前的超长强制写入是覆盖式写入,强制覆盖后面的内容,如果后面是有足够多的00,应该不用担心,如果不是,则需要追加式的写入,就是这种了:
000A000000CDD3C2DDD0A7D3A63A000900000081
不覆盖后面原有内容,自动加长。

当然,我这个的例子,目标对象是不检查文件总长度,所以怎么追加都无所谓。如果是PE或其他文件,还是需要追加后手动删除足够的空字节维持文件长度。但我这里讨论的关键是:
“不检查超长字符串”应该有两个选项:“覆盖写入”和“追加写入”。
当然,如果可行的话,当选择“追加写入”后,建议在全部回写完毕时提示“本次回写总共追加了0A字节”这样的文字。

2007-04-28 00:35
这几个文件都提示“◇ 未找到合适的字符串:...”
gsmission.spb需要提取MISSIONS,gspilotrecord.spb需要提取PILOT RECORDS,dlgassignbook.spb需要提取SETTINGS - CONTROLS、CALIBRATION、BUTTONS / KEYS、CONTROL AXES、FORCES等字串
[attachmentid=23157]

gssettings.spb提取不完整,如:
0x00000B22,0032=Low|Low|Medium Low|Medium High|H
0x00000BFA,0067=lick to choose sound settings for engines, air traffic control, coc
0x00000CC0,0032=to modify keyboard and joystick
0x00000D59,0067=lick to adjust flight model, crash detection, and other realism set

对了,同样的文件,我使用4月20号发布的版本做相同的提取,不存在上述问题,上述问题是最新版本才会出现。

如果是因为后面增加字符串长度修改所导致,那么不妨放弃吧。原来的功能就很好了,呵呵


查看完整版本: [-- [原创/更新]TransText 2.2.264 - 字符串提取、回写以及替换工具 --] [-- top --]



Powered by phpwind v8.7 Code ©2003-2011 phpwind
Time 0.015707 second(s),query:3 Gzip disabled