Resolving TIA Portal Export Project Texts XLSX Corruption

1. Problem Overview: Export Project Texts Produces an Unreadable XLSX

Engineers localizing HMI projects in TIA Portal V13 SP1 use the Project texts > Export workflow to produce an Office Open XML spreadsheet (.xlsx) for translators. The export action completes without any error dialog in TIA Portal, but the resulting workbook cannot be opened by Microsoft Excel 2007 (and later versions up through current Excel 365 builds) because the package contains an illegal XML 1.0 control character. Excel reports a recoverable-content error, refuses to load the workbook, and strips large portions of the data. Siemens official documentation on exporting project texts confirms that the Export command always produces an OOXML container, but does not validate the resulting package against the spreadsheet consumer.

Symptom stack as reported by Excel 2007 on first open:

• Dialog title: "Excel found unreadable content in 'TIAProjectTexts.xlsx'. Do you want to recover the content of the workbook?"
• On recovery attempt: "Removed Part: /xl/sharedStrings.xml part with XML error. (Strings) Illegal xml character. Line 1, column 5600."
• On recovery attempt: "Removed Records: Cell information from /xl/worksheets/sheet1.xml part"
• On recovery attempt: "Removed Records: Cell information from /xl/worksheets/sheet2.xml part"

Third-party spreadsheet applications such as LibreOffice 5.0.2.2 open the same .xlsx package without complaint, but they silently drop the corrupt string table, which makes the localization export unusable because the English source-language column (the only column the translator needs as a reference) becomes empty.

2. Affected Versions, Updates, and Engineering Environments

The defect is reproducible in the following stack that engineers have confirmed in field reports. Treat any TIA Portal release prior to the listed fixed update as potentially affected.

The Siemens support entry 109311724 — TIA Portal V13 SP1 Update 5 download & release notes is the first public update step relevant to this export path, but the issue is not fully resolved there. The matching 109475709 — TIA Translation Tool entry is referenced as a workaround path. Newer TIA Portal major versions (V14, V15, V15.1, V16, V17, V18, V19, V20) re-implemented the export with stricter source-text validation, which is why the symptom is documented predominantly against V13 SP1.

3. Anatomy of an Office Open XML (.xlsx) Spreadsheet

An .xlsx file is a ZIP archive that follows the ECMA-376 / ISO/IEC 29500 Office Open XML SpreadsheetML conventions. The two parts involved in this defect are:

• xl/sharedStrings.xml — the shared string table. Every distinct text value used by any cell is stored exactly once in this table, and cells reference the entries by integer index. This is the part that Excel flags as "(Strings) Illegal xml character."
• xl/worksheets/sheet1.xml, sheet2.xml, … — the per-sheet cell tables. Each cell is either a literal value, a number, a Boolean, a formula, or an index into the shared string table. When Excel removes the shared string table, the index references become orphan records and Excel strips them as Removed Records: Cell information from /xl/worksheets/sheet1.xml part.

Because the index references depend on the shared string table, a single bad entry cascades into thousands of stripped cell records on a large TIA export — which is why a single 4-character HMIscreen text can effectively wipe out the entire translation file.

4. Root Cause: Illegal XML 1.0 Control Character 0x1F in sharedStrings.xml

The XML 1.0 specification (W3C Recommendation, Fifth Edition) restricts the set of legal characters in well-formed documents to the following ranges:

Any byte below 0x20 other than TAB (0x09), LF (0x0A), and CR (0x0D) is illegal. The character that triggers the TIA Portal V13 SP1 defect is the ASCII Unit Separator (US):

When the bad text contains the literal byte 0x1F, TIA Portal's V13 SP1 export writer serializes the value verbatim into the shared string table. The character is not escaped to a numeric character reference and is not filtered. Microsoft's Open XML SDK then refuses to parse the part because raw 0x1F is a non-character control code in XML 1.0.

5. How the Character Enters the Project

The defect is concentrated in the HMI screen category of the project-text export. Reports consistently show that excluding the HMI-screen category yields a clean .xlsx, and that re-including it reproduces the corruption. The trigger is a single screen text — for example the on-screen label "  Service  " (with leading and trailing spaces) on a KP900 Comfort panel. The spaces themselves are legal; the illegal byte is typically introduced by:

1. Pasting the text from a clipboard populated by a third-party SCADA / MES / spreadsheet tool that emits ASCII control characters as field delimiters.
2. Importing a CSV / Unicode / ANSI text file that contains 0x1F as a Unit Separator between logical fields. The TIA Portal V13 SP1 text import does not strip 0x1F.
3. Programmatically writing into the HMI text database through a non-Siemens tool that does not validate against XML 1.0.

Text imported through a normal TIA Portal Project texts > Import action from a vendor-supplied translation file (.xlsx) can also carry the byte forward if the source .xlsx was originally produced by the same defective export. This is the most common propagation path: a translator is sent a corrupt file, opens it in LibreOffice, edits the strings, sends it back, and the next export re-emits the same byte.

6. Diagnostic Procedure: Isolating the Corrupting String

Before performing the archive surgery described in section 8, isolate the offending text so that the project database itself can be cleaned. If the database still contains the byte, every subsequent re-export will be corrupt again.

1. In TIA Portal, open Project tree > Languages & Resources > Project texts.
2. Click Export. In the Export project texts dialog, clear the checkbox for the HMI screen category only. Leave PLC text categories, alarm categories, and others selected. Click Export and open the resulting .xlsx in Excel.
3. If the file opens cleanly, the HMI-screen category is confirmed as the carrier. Re-export, this time selecting only the HMI-screen category, to obtain a smaller .xlsx that contains only the suspect strings.
4. Open the smaller .xlsx with 7-Zip (see section 8) and extract xl/sharedStrings.xml.
5. Open sharedStrings.xml in a hex-capable editor (Notepad++ with the HEX-Editor plugin, HxD, or VS Code with the Hex Editor extension). Search for the byte sequence 1F while in hex view. Each occurrence corresponds to one project-text entry that contains the illegal character.
6. For each hit, return to TIA Portal, open the matching screen, and re-type the text. Do not paste from the clipboard — type each character. This replaces the underlying 0x1F with a normal space or with the literal text you intended.
7. Save the project, repeat the export, and verify the new .xlsx opens in Excel without the recovery dialog.

7. Manual Recovery: 7-Zip XML Repair Procedure

Use the following procedure to repair an already-exported corrupt .xlsx. This is a stop-gap that recovers the data so the translator can begin work, but it does not fix the project database — combine it with section 6 for a complete remediation.

1. Install 7-Zip on the engineering workstation.
2. Right-click TIAProjectTexts.xlsx in Windows Explorer and choose 7-Zip > Open archive. The file is opened as a ZIP container.
3. Navigate into the xl/ folder of the archive.
4. Drag sharedStrings.xml from the archive to a working folder. Do not close the archive yet.
5. Open the extracted sharedStrings.xml in a plain-text editor (Notepad++, VS Code, or Notepad).
6. Use the editor's Find function. In the Find what field, enable Regular expression mode and search for the literal text:
   \x1F (if the editor uses C-style escapes) or the single byte 0x1F pasted in via a hex view.
7. Replace every match with an empty string. Save the file in UTF-8 (no BOM) encoding. Excel requires UTF-8 without a byte-order mark for the shared string table to be re-loaded correctly.
8. Return to 7-Zip, navigate back to xl/ inside the archive, and Add the modified sharedStrings.xml with the same path. In 7-Zip's Add to archive dialog, accept the default compression and the original path.
9. Close 7-Zip. Double-click the repaired .xlsx and confirm that Excel opens it without the recovery dialog and that the source-language column is intact.

8. The TIA Translation Tool Alternative Workflow

The TIA Translation Tool is the only Siemens-shipped utility designed to handle the import/export of localization data outside the TIA Portal main shell. The official entry point is:

• Siemens Support entry 109475709 — TIA Translation Tool description & download

Behavior of the Translation Tool in the affected versions:

• Import dialog: when the source directory is selected, the file list area is empty. The tool refuses to enumerate any .xlsx produced by the V13 SP1 export, because the tool's internal schema validator returns a parse error on the corrupt sharedStrings.xml before the file is even presented to the user.
• Workaround for the tool: apply the section 7 repair to the .xlsx first, then import the repaired file into the Translation Tool. The tool can then re-export the data in a format that a translator can consume.
• Direct in-tool use: open the project directly in the Translation Tool, perform the translation work in the tool's grid, and export the result as .xlsx. The tool's exporter uses a different code path than the TIA Portal export and is not affected by the 0x1F bug in V13 SP1.

9. Software Update Path: TIA Portal V13 SP1 Updates

The defect is documented against V13 SP1 base and is reproducible after Update 8. The recommended path forward, in priority order, is:

1. Migrate the project to a current TIA Portal version. The export code path was re-implemented in V14 and the string-table writer has additional validation in every release since. The Siemens documentation at TIA Portal V20 — Exporting project texts shows the modern workflow.
2. Apply Update 5 (or later) of V13 SP1 and re-test. The Siemens support entry 109311724 provides the link, but field reports indicate the export defect is not fixed by Update 5, Update 6, Update 7, or Update 8. Treat the update as a prerequisite for the runtime and as an opportunity to re-test, not as a fix.
3. Match the WinCC Runtime Advanced version to the TIA Portal engineering version. A V13 SP1 Update 5 or later runtime is required on the target system; otherwise the engineering project may not deploy cleanly even when the export defect is worked around.

Before upgrading, capture the project's text database (clean .xlsx produced via section 7 + section 6) so the localization work is not lost during the migration.

10. Preventive Workflow Practices for Multi-Language Projects

• Ban the byte in your localization SOP. Add an automated pre-import filter (PowerShell, Python) that strips every C0 control character (U+0000 to U+001F except TAB, LF, CR) from any text file before it is loaded into the TIA project.
• Sanitize clipboard pastes. When pasting multi-language strings into an HMI text field, paste first into Notepad (which normalizes line endings) and only then copy from Notepad into TIA Portal. This avoids Unit Separator and other field-delimiter bytes that clipboard providers may inject.
• Validate every export by running a script that opens the produced .xlsx with the Open XML SDK and parses sharedStrings.xml. Reject any project-text export that contains bytes outside the XML 1.0 Char production.
• Source-language column round-trip. After every export, open the .xlsx in Excel immediately. The English-US column must be populated; if it is blank, the file has been silently downgraded by a non-strict parser and must be regenerated.
• Translate outside TIA Portal. Use the TIA Translation Tool (or a CAT tool that emits clean UTF-8) as the system of record for translations, and only round-trip into the TIA project database. This isolates the localization workflow from the TIA Portal export bug.

11. Verification: Confirming a Healthy Workbook

After any repair, perform the following checks to confirm that the .xlsx is well-formed and the translation data is complete.

1. Excel open test. Double-click the file. The recovery dialog must not appear. If it appears, repeat the section 7 procedure on the new file.
2. Sheet enumeration. In Excel, the bottom tab bar must show all of the expected sheets (one per export category). A missing sheet indicates that a part was dropped during parse.
3. Cell count. Compare the cell count of the repaired file (visible in Excel's Name Box after pressing Ctrl+End) against the cell count of a known-good export from a clean project. A large drop indicates orphan index references.
4. String-table integrity. Use 7-Zip to extract xl/sharedStrings.xml and grep the file for the byte 0x1F. Zero hits is the only acceptable result.
5. Round-trip import. Re-import the repaired .xlsx into the TIA Portal project and confirm that the editing language column shows the expected translated strings. If the column is empty, the project database is still contaminated and you must apply the section 6 procedure.

12. Troubleshooting Matrix

Frequently Asked Questions