This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=3936

bugmenot, posted Sat Mar 11, 2017 12:17 pm (21386)

---

Would it be possible to update the RGSSAD script so it'll be able to extract file names containing Japanese symbols?

Here is a link for testing: https://mega.nz/#!ic0XFL6B!HYK5qmQu9_a1SCssg5_eN-urJADrq6nahUv7p2j8cBo

P.S. If it'll be problematic/slow to leave the changes always on maybe create a non-ANSI version of the RGSSAD extractor?

aluigi, posted Sat Mar 11, 2017 12:38 pm (21388)

---

There is a Codepage instruction in the bms language, I'm not sure if it makes any difference but try to use it at the beginning of the script:

Code:

codepage 932

932 is shift_jis https://msdn.microsoft.com/en-us/librar ... 85).aspx

bugmenot, posted Sat Mar 11, 2017 12:51 pm (21391)

---

Already tried it and it didn't help also tried using utf16

aluigi, posted Sat Mar 11, 2017 4:30 pm (21394)

---

Quickbms just uses the fopen() API and _wfopen() if the filename is longer than how much supported by default (long story).
I have an idea in mind but I need something ready to test, can you provide one of these archives containing japanese filenames?
I need also the expected output name (image, hex, string or what you can provide).

aluigi, posted Sat Mar 11, 2017 5:46 pm (21395)

---

In the meantime my idea seems to work.
Just made a test with http://zenhax.com/viewtopic.php?p=7768#p7768 and the output is now (with my beta) different than the one of the current quickbms 0.7.7.
The only problem is that ccs=shift_jis returns an error with _wfopen so it goes by default on ccs=UTF-8.
This is something of the system not related to quickbms.

aluigi, posted Sat Mar 11, 2017 6:50 pm (21397)

---

I no longer need the files.
I confirm that the new version of quickbms will have the output filenames correctly working.
What's important is that the codepage is correct, there will be a runtime option (-P) to specify it.