Rapid SCADA 4.5.6 can export a table correctly in Internet Explorer 11 while giving the downloaded Excel file a garbled Cyrillic name. Rename the underlying view file with Latin characters; changing the KP name or the visible report content does not address the fault. This workaround keeps IE11 available for the Windows 7 and Silverlight-dependent project without requiring an upgrade to version 7.
Symptom interpretation
The reported name УзлыУчета 2016-08-26 is mojibake: readable characters were converted through incompatible character encodings and displayed as a different sequence. The corruption occurs in the download filename path. It does not, by itself, prove that the worksheet cells or exported data use the wrong encoding.
Separate the three observable results before modifying the project:
| Test condition | Observed result | Diagnostic meaning |
|---|---|---|
| IE11 on Windows 7 | Excel export receives a garbled Cyrillic filename | The IE11 download path does not preserve the non-Latin view filename correctly in this installation. |
| Chrome | The filename is correct | The source name is available to the web application, but Chrome cannot satisfy the installation's Silverlight requirement for displaying diagrams. |
| Firefox | The filename encoding is correct | The failure is browser-specific rather than a universal Rapid SCADA export failure. |
Open one exported workbook and inspect its cells separately from its filename. If the cell values are readable, limit the correction to filename generation. If the cells are also corrupted, treat that as a second encoding problem and diagnose the export data independently.
Filename generation mechanism
For a table-view report in this Rapid SCADA configuration, the exported filename comes from the view file name. The KP name does not control the download name. The term here means the project file that defines the view, not merely a caption shown inside the view or a KP label elsewhere in the configuration.
IE11 receives a proposed download name from the web application and passes it through its download-handling components. Non-ASCII characters require every component to agree on the character encoding. When one component interprets encoded Cyrillic bytes using another character set, the name becomes mojibake. Latin letters, digits, hyphens, and underscores occupy the ASCII range and retain the same byte values across the relevant legacy and Unicode encodings, which is why a Latin view filename avoids the failing conversion path.
This also explains why changing the KP name is ineffective: the export does not derive its filename from that field. Browser cache clearing, Excel repair, and worksheet formatting likewise act outside the point where the displayed download name is being corrupted.
IE11-compatible correction procedure
- Identify the exact view used to produce the table report. Confirm its underlying file name rather than relying on the KP name or displayed caption.
- Record where that view is referenced in the project. Make a recoverable copy of the affected configuration before changing the file name.
- Rename the view file using Latin characters only. Preserve its file extension and use a stable name such as
report,table_view, or a project-approved transliteration. Digits, hyphens, and underscores are also suitable. - If the configuration stores a path or file reference separately, update that reference to the renamed view file. A filesystem rename alone can leave the project pointing at the old Cyrillic path.
- Reload the web application or begin a fresh IE11 session so that the renamed view is loaded. Navigate to the same table view and verify that it still displays the intended process data.
- Run the Excel export again from IE11 and save the download. The generated name should now use the Latin view filename, with any existing date suffix retained by the export function.
The correction does not require renaming every KP or converting every project label to English. Apply it to view files whose names become exported filenames. Visible Cyrillic captions may remain when they are stored independently from the physical file name.
Verification checks
- Check 1: view loading. Open the renamed view in IE11. Expect the same table layout, channels, and current values that appeared before the rename. A missing-view response indicates that a stored path still uses the former filename.
- Check 2: export completion. Start the table export. Expect IE11 to present or save an Excel file without an application error. Failure before the download prompt points to a broken view reference rather than filename encoding.
-
Check 3: downloaded name. Inspect the saved file in Windows Explorer. Expect readable Latin characters matching the renamed view file, plus the export-generated date such as
2016-08-26when that suffix is part of the report name. - Check 4: workbook contents. Open the file in Excel. Expect the same report columns, timestamps, and values as the source table view. This distinguishes a corrected filename from an incomplete or incorrect export.
- Check 5: repeatability. Export the same view again from a fresh IE11 session. Expect the filename to remain readable and the view's Silverlight-dependent diagrams to remain available in the required browser workflow.
Recurring implementation pitfalls
| Wrong practice | Why it fails | Correct action |
|---|---|---|
| Renaming the KP | The export name follows the view file, not the KP name. | Rename the underlying view file. |
| Changing only a visible caption | A caption may not alter the physical file name used by export. | Confirm the actual project filename after the change. |
| Renaming the file without updating its reference | The web application may continue requesting the old path. | Update stored paths and reopen the view. |
| Troubleshooting Excel first | Excel does not select the HTTP download filename. | Verify workbook data once, then correct the view filename path. |
| Switching permanently to Chrome | It corrects the name but does not meet this project's Silverlight diagram requirement. | Use the Latin-name workaround with IE11 for project acceptance. |
| Upgrading during commissioning solely for this symptom | It expands the change scope when a configuration workaround exists. | Apply and validate the filename change in Rapid SCADA 4.5.6. |
A later beta web application was intended to omit IE support because of IE's JavaScript limitations and target Chrome, Edge, and Firefox. Treat migration as a separate lifecycle decision; it is not the corrective action for a project that must retain IE11 and Silverlight during acceptance.
Frequently asked questions
How do I fix garbled Rapid SCADA Excel filenames in IE11?
Rename the underlying table-view file with Latin characters, update any stored reference to that file, reload the view, and export again. The saved name should match the Latin view filename instead of showing mojibake.
How do I choose which Rapid SCADA name to change?
Change the view file name, not the KP name. Confirm the physical filename used by the table view; changing only its visible caption may leave the export name unchanged.
How do I verify the IE11 workaround did not break the report?
Open the renamed view, export it in IE11, and open the workbook in Excel. As the final verification step, expect a readable Latin filename and the same columns, timestamps, and values as the source table.