Check Garbled Text Before Saving a New Copy

You open a text export and find that café has become café. The tempting fix is to replace the strange characters and save. First, find out whether the file is being read incorrectly or whether an earlier step has already changed its contents.

Those situations need different responses. A correct opening setting may fix the view of an untouched file. It cannot automatically restore information that an earlier export discarded. Keep the original while you investigate.

Separate the source, the export and the view

Identify three things: the document or system that produced the text, the exported file, and the application displaying it. Note where you first noticed the problem. If the source still shows the intended wording, keep that available as a reference.

Make a separate working copy of the export without opening and resaving it. Copying the file itself preserves a better starting point than copying garbled text from the screen into a new document. Avoid uploading private text to an unfamiliar converter just to test a setting.

Choose two or three short passages whose correct text you can establish. Include the affected characters and some ordinary words around them. A file containing only simple English letters may look fine under more than one encoding, so it is a weak test for this problem.

Understand what the opening setting changes

A text encoding relates characters to stored bytes. The application reading a plain-text file must interpret those bytes using an encoding. Microsoft's documentation explains how a mismatch between the encoding used to write a file and the one used to read it can produce unexpected character sequences.

The following invented sentence demonstrates one specific mismatch:

• Intended text: The café has a blue façade.
• Saved as: UTF-8.
• Those same bytes interpreted as Windows-1252: The café has a blue façade.

In this example, the original bytes have not changed. Reading that untouched file as UTF-8 restores the intended sentence. The unusual sequences are evidence to investigate, not a universal instruction to replace every occurrence of à in every document.

Ask the exporting application’s documentation or the file’s sender which encoding was used. A filename ending in .txt does not settle that question. If the source provides a documented export setting, use it rather than cycling through options until one word looks plausible.

Reopen a copy before converting it

Use an editor that distinguishes opening or reopening with an encoding from saving with an encoding. Visual Studio Code's official documentation, for example, describes both choices through its encoding control. Other tools use different labels, so consult the instructions for the editor you already use.

On the working copy, choose the operation that rereads the saved bytes using the source's confirmed encoding. Do this before making edits. Reopening can replace the current editing buffer, so preserve any separate unsaved work first.

Compare all your reference passages. Check the accented letters, punctuation and surrounding words, not just the first repaired word. If one passage improves while another becomes wrong, stop. The file may have passed through inconsistent earlier processing, and one global setting may not resolve it.

Recognize when the wrong text was saved

Now change the fictional example. Someone opens the original UTF-8 file as Windows-1252, sees café and façade, then saves those displayed characters into a new UTF-8 file.

The new file is valid UTF-8, but its text is still wrong. Opening it as UTF-8 faithfully displays the wrong characters that were saved. An encoding label alone therefore does not prove that the wording survived correctly.

Return to the untouched original or produce a new export from the correct source. If neither is available, preserve the damaged copy and seek help with its processing history. Do not make a broad search-and-replace operation your first recovery method.

Separate missing information from display trouble

Another export might replace unsupported characters with question marks. In an illustrative ASCII conversion using replacement behavior, the sentence becomes “The caf? has a blue fa?ade.” Both é and ç have become the same symbol. That output alone no longer identifies the original characters; recover them from a reliable source rather than guessing.

A blank box or unusual symbol is not enough to diagnose the cause. The Unicode Consortium notes that fonts and application support can also affect character display. Check the same preserved file in a suitable viewer before concluding that the text itself has been lost.

Verify the new handoff

If the preserved export already uses the required encoding, correcting the receiving application's import setting may be enough. Do not convert the file merely because it initially opened incorrectly.

Once the content reads correctly, save any required converted version under a new name using the destination's documented requirements. Do not change unrelated settings simply to make the filename look standardized.

Close and reopen the saved output, then compare the same reference passages again. If another application will consume the text, test the checked copy there too. Record the source encoding, output encoding and unresolved differences alongside the file.

A few passages provide a focused diagnostic check, not proof that an entire large file is correct. Expand the comparison to match the importance of the content before replacing or distributing it.