Failed to Load Rigaku RASX Powder Data on Windows

[suzukikensuke1]

Description

GSAS-II fails to load a powder histogram file with the .rasx extension from Rigaku when running on a Windows 11 environment. The same file loads successfully on macOS and Ubuntu, so the issue appears to be platform-specific.

Steps to Reproduce

1. Download the installer: gsas2main-Latest-Windows-x86_64.exe(https://advancedphotonsource.github.io/GSAS-II-tutorials/install-g2f-win.html)
2. Install GSAS-II on a Windows 11 system.
3. Launch the application using the desktop shortcut.
4. Go to Import → Powder Data → from Rigaku .ras/.rasx file file.
5. Select the attached .rasx file (fail_to_read_on_windows.rasx).
6. Observe the error.

Error Message

Import path not found - set to current directory
The Rigaku .rasx file reader was not able to read file fail_to_read_on_windows.rasx
Error message(s):
Rigaku .rasx file validator error

Environment

• OS: Windows 11
• GSAS-II Version: 5823/v5.6.0 posted 19-Oct-25 11:23
• File: fail_to_read_on_windows.rasx (attached)

Additional Notes

• The issue is reproducible only on Windows 11.
• The same issue was also observed with a GSAS-II version from approximately one year ago on Windows11 (exact version not remembered).
• The same .rasx file works correctly on macOS and Ubuntu.

fail_to_read_on_windows.zip

[briantoby]

I was able to read the file you attached on Windows 11. I even tried doing an install of the latest GSAS-II on a fresh install of Windows and still did not see your problem. My only guess is that when the program creates some temporary files (the .rasx file is a zipped archive that is expanded and then examined and deleted), on your computer, you do not have the permissions to create or delete the files. In the hopes of learning what is different for you, I have added an additional error message in v5.6.1 (5824). Please update and try again and let me know if you see anything new.

[suzukikensuke1]

Thank you very much for taking the time to verify the issue I reported. I understand it doesn't reproduce in your environment.

After further testing on my side, I found that the issue is related to file encoding. Specifically, it occurs when the encoding of the three files in the RASX file is UTF-8 with BOM (Byte Order Mark). Once the files are encoded as UTF-8 (without BOM), everything works as expected.

Additionally, I observed that even a simple CSV file—which normally loads correctly—fails to load when encoded in UTF-8 with BOM. I've attached an example of such a CSV file that fails:
encode_with_utf-8-BOM.csv

If it's still not reproducible in your setup, the issue may be related to the system locale. My environment is Windows with Japanese locale, and the issue also occurred on another Windows with Japanese. So it may be reproducible in other Japanese or CJK-locale Windows systems.

This issue is not critical for us. We’re able to work around it by using other operating systems or by ensuring files are encoded without BOM. It might be sufficient to suggest removing BOM when file reading fails. Please consider this report as a reference rather than a request for immediate action.

[briantoby]

I can now understand the problem. With both Windows and Mac on a U.S. Locale, I do not see an error reading your .csv file, but Python does see the file as binary rather than text due to the extra characters at the head of the file. It does make sense that UTF processing may be different with language processing. From what I have read, Python would need to use a separate encoding (utf-8-sig) to handle this. Alas, even when I tried to set up Windows to use Japanese, I still am not able to reproduce this error with either file. I am very reluctant to make changes without being able to test their impact.

Since this problem can occur with any importer, it does not make sense to add it as an error message for the Rigaku files specifically, but I will add this to the help. That will appear next time there is a tutorials/web update (29fa7dd in GSASII-tutorials).

[briantoby]

I will leave this open for now, just in case anyone else can reproduce this and who might be willing to work on it. I could imagine adding a test for all files as part of the import process to see if they begin with this BOM. GSAS-II could then strip it as part of the read.

In the case of the .rasx files, this might need to be done after using zip to extract the files.