Microsoft word xml parsing error

Updated on October 28, 2022

“Yesterday night, while I was working on a Word file it crashed suddenly and I had to close it forcefully. After refreshing my system, I tried to open a Word file to resume my work but got an error message that ‘sorry, you cannot open word document XXX.docx because there is a problem with its contents. The below error message has two options called OK and details. I clicked on ‘details’ in order to get information about the error message. However, I found another error message that said ‘unspecified error Part: /word/document.xml, Line 2, Column: 0’. I would greatly appreciate it if someone has any solution for my problem”

Sometimes at the time of working on the Microsoft tool, it might suddenly crash and upon restarting it, you may get an XML error message that makes entire contents inaccessible.

What Causes the XML Parsing Error with Microsoft Word?

Windows update used for parsing is not installed – This is by far the most common problem. This particular update should be included among the WSUS, but for some reason, Windows Update does not install it on all machines, which produces the XML Parsing Error.

An SVG graphic included in the document is not parsed correctly – This problem might also occur because of the XMLlite, which returns an out of memory error code unexpectedly during the parsing of an SVG graphic.

Encoding errors inside the XML code belonging to the document – Most likely, the XML file contains encoding errors that the Word editor is unable to understand.

If you’re currently struggling to resolve the XML Parsing Error try the below-mentioned troubleshooting methods.

How to Fix XML Parsing Error In Word?

Method 1: Using Built-in Options

One can use the built-in method to fix this issue and view a Word file. Below provided is the procedure to repair XML errors in Word file:

• First of all right click on the Word file and select Rename option
• Rename the Word file along with extension to ZIP file format
• You will find XML document in ZIP file. Open the XML file using Notepad
• In order to find which element is causing problem with your Word file, you have to format XML content using plug-in
• Choose Pretty Print(XML only – with line breaks). This will format content of XML
• Now convert back the XML document to ZIP and then change the extension from ZIP to DOCX

After going through these procedures, try to open the DOCX file. You will find some error messages, but when you choose the details option you can view which line has an error. Search for the line in an XML document and then delete the whole tag. Copy XML back into the ZIP file and then rename the extension again to the DOCX file and try to open the document. In case you get another error message, then repeat the process unless the document opens.

Method 2: Resolving the error via Notepad++ and Winrar or Winzip

If the first method was not successful in resolving the issue, it’s very likely that the XML code accompanying your Word document is not according to the XML specification. Most likely, the XML code accompanying the text contains encoding errors.
Luckily, the error window will provide you with additional helpful details that will help us to pinpoint the problem more precisely. To be precise, the Location attribute right under the XML parsing error message will point you to the line and column where the faulty code lies.
You might notice that the Location attribute points towards a .xml file, while you’re trying to open a word file. Wondering why that is? It’s because the .doc file is actually a .zip file that contains a collection of .xml files.
Follow the instructions down below to use Notepad++ and WinRar to resolve the issue and open the Word document without the XML parsing error:

1. Right-click on the document that is causing the error and changes the extension from .doc to .zip. When asked to confirm the extension name change, click Yes to confirm.
2. If the .DOC or .DOCX file is safely converted into a .zip file, you can double-click to open it. You will see a collection of files that you never knew existed before
3. Next, let’s take a look at the error message and see which XML document is causing the error. In our case, the document responsible was document.xml. With this in mind, go ahead and extract the XML file outside the ZIP archive so we can begin editing
4. You can open the XML file with a lot of text editors, but we recommend Notepad++ because it’s reliable and has a code highlight feature that will make things a lot easier for us.
5. Once Notepad++ is installed on your system, right-click on the XML file that you extracted at step 3 and choose Edit with NotePad
6. Next, we’ll need to install a plugin called XML Tools in order to view the correct lines and columns. This will help us identify the error a lot more easily. To do this, go to Plugins (using the ribbon at the top) and then go to Plugin Manager > Show Plugin Manager
7. Then, go to the Available tab, find the XML Tools plugin from the list, select it and press the Install button. Next, restart NotePad++ to allow the plugin to be enforced.
8. Once XML Tools is installed in Notepad++, go to Plugins > XML Tools and click on Pretty print (XML only – with line breaks).
9. Once the file is formatted, go to the line mentioned in the error while keeping in mind the column.

Once the XML file is passed back, rename the file back to what it was (.doc or .docx) and open it again. If the error was resolved correctly, you should have no issues opening the document now. Once the error has been resolved, save the XML file and paste it back in the .ZIP file.

Method 3: Fix XML error in Word File Using Yodot Doc Repair Software

To eliminate all kinds of errors including XML error in Word, you are suggested to download Yodot DOC Repair software on your Windows computer. As this is the Word file repair software, it can completely remove error messages from Word documents and create a healthy copy with its attributes intact with formatting. Even though this software has simple functionality, it can take you out from all sorts of corruption including Macro errors in Word files, Word file encoding errors, error 4605, file permission errors, file association errors, and other issues that make Word documents inaccessible. The application delivers a high degree of scalability by allowing you to repair Word DOC files by yourself without needing any professional help or assistance.

Steps for Repair Word XML error:

• Step 1: Download Yodot DOC Repair software on your computer and install it. Run the utility and select the Word file showing unreadable content error by clicking the Browse button.
• Step 2: Click on the Repair button to scan the Word file and fix Word found an unreadable content error with it.
• Step 3: Once the scan process completes, you can click on “Click Here to preview file” to preview the repaired Word file. In the end, save repaired Word file using the Save option.

Источник

Parsing an XML File Using SAX

In real-life applications, you will want to use the SAX parser to process XML data and do something useful with it. This section examines an example JAXP program, SAXLocalNameCount, that counts the number of elements using only the localName component of the element, in an XML document. Namespace names are ignored for simplicity. This example also shows how to use a SAX ErrorHandler.

Creating the Skeleton

The SAXLocalNameCount program is created in a file named SAXLocalNameCount.java.

Because you will run it standalone, you need a main() method. And you need command-line arguments so that you can tell the application which file to process. Find the example’s complete code in the SAXLocalNameCount.java file.

Importing Classes

The import statements for the classes the application will use are the following.

The javax.xml.parsers package contains the SAXParserFactory class that creates the parser instance used. It throws a ParserConfigurationException if it cannot produce a parser that matches the specified configuration of options. (Later, you will see more about the configuration options). The javax.xml.parsers package also contains the SAXParser class, which is what the factory returns for parsing. The org.xml.sax package defines all the interfaces used for the SAX parser. The org.xml.sax.helpers package contains DefaultHandler, which defines the class that will handle the SAX events that the parser generates. The classes in java.util and java.io, are needed to provide hash tables and output.

Setting Up I/O

The first order of business is to process the command-line arguments, which at this stage only serve to get the name of the file to process. The following code in the main method tells the application what file you want SAXLocalNameCount to process.

This code sets the main method to throw an Exception when it encounters problems, and defines the command-line options which are required to tell the application the name of the XML file to be processed. Other command line arguments in this part of the code will be examined later in this lesson, when we start looking at validation.

The filename String that you give when you run the application will be converted to a java.io.File URL by an internal method, convertToFileURL(). This is done by the following code in SAXLocalNameCount.

If the incorrect command-line arguments are specified when the program is run, then the SAXLocalNameCount application’s usage() method is invoked, to print out the correct options onscreen.

Further usage() options will be examined later in this lesson, when validation is addressed.

Implementing the ContentHandler Interface

The most important interface in SAXLocalNameCount is ContentHandler. This interface requires a number of methods that the SAX parser invokes in response to various parsing events. The major event-handling methods are: startDocument, endDocument, startElement, and endElement.

The easiest way to implement this interface is to extend the DefaultHandler class, defined in the org.xml.sax.helpers package. That class provides do-nothing methods for all the ContentHandler events. The example program extends that class.

Note — DefaultHandler also defines do-nothing methods for the other major events, defined in the DTDHandler, EntityResolver, and ErrorHandler interfaces. You will learn more about those methods later in this lesson.

Each of these methods is required by the interface to throw a SAXException. An exception thrown here is sent back to the parser, which sends it on to the code that invoked the parser.

Handling Content Events

This section shows the code that processes the ContentHandler events.

When a start tag or end tag is encountered, the name of the tag is passed as a String to the startElement or the endElement method, as appropriate. When a start tag is encountered, any attributes it defines are also passed in an Attributes list. Characters found within the element are passed as an array of characters, along with the number of characters (length) and an offset into the array that points to the first character.

Document Events

The following code handles the start-document and end-document events:

This code defines what the application does when the parser encounters the start and end points of the document being parsed. The ContentHandler interface’s startDocument() method creates a java.util.Hashtable instance, which in Element Events will be populated with the XML elements the parser finds in the document. When the parser reaches the end of the document, the endDocument() method is invoked, to get the names and counts of the elements contained in the hash table, and print out a message onscreen to tell the user how many incidences of each element were found.

Both of these ContentHandler methods throw SAXExceptions. You will learn more about SAX exceptions in Setting up Error Handling.

Element Events

As mentioned in Document Events, the hash table created by the startDocument method needs to be populated with the various elements that the parser finds in the document. The following code processes the start-element event:

This code processes the element tags, including any attributes defined in the start tag, to obtain the namespace universal resource identifier (URI), the local name and the qualified name of that element. The startElement() method then populates the hash map created by startDocument() with the local names and the counts thereof, for each type of element. Note that when the startElement() method is invoked, if namespace processing is not enabled, then the local name for elements and attributes could turn out to be an empty string. The code handles that case by using the qualified name whenever the simple name is an empty string.

Character Events

The JAXP SAX API also allows you to handle the characters that the parser delivers to your application, using the ContentHandler.characters() method.

Note — Character events are not demonstrated in the SAXLocalNameCount example, but a brief description is included in this section, for completeness.

Parsers are not required to return any particular number of characters at one time. A parser can return anything from a single character at a time up to several thousand and still be a standard-conforming implementation. So if your application needs to process the characters it sees, it is wise to have the characters() method accumulate the characters in a java.lang.StringBuffer and operate on them only when you are sure that all of them have been found.

You finish parsing text when an element ends, so you normally perform your character processing at that point. But you might also want to process text when an element starts. This is necessary for document-style data, which can contain XML elements that are intermixed with text. For example, consider this document fragment:

The initial text, This paragraph contains, is terminated by the start of the element. The text important is terminated by the end tag, , and the final text, ideas., is terminated by the end tag,

To be strictly accurate, the character handler should scan for ampersand characters (&) and left-angle bracket characters ( &entityName;

When you are handling large blocks of XML or HTML that include many special characters, you can use a CDATA section. A CDATA section works like . in HTML, only more so: all white space in a CDATA section is significant, and characters in it are not interpreted as XML. A CDATA section starts with .

An example of a CDATA section is shown below.

CDATA sections may occur anywhere character data may occur; they are used to escape blocks of text containing characters which would otherwise be recognized as markup. CDATA sections begin with the string » » and end with the string » ]]> «

Once parsed, this text would be displayed as follows:

CDATA sections may occur anywhere character data may occur; they are used to escape blocks of text containing characters which would otherwise be recognized as markup. CDATA sections begin with the string » «.

The existence of CDATA makes the proper echoing of XML a bit tricky. If the text to be output is not in a CDATA section, then any angle brackets, ampersands, and other special characters in the text should be replaced with the appropriate entity reference. (Replacing left angle brackets and ampersands is most important, other characters will be interpreted properly without misleading the parser.) But if the output text is in a CDATA section, then the substitutions should not occur, resulting in text like that in the earlier example. In a simple program such as our SAXLocalNameCount application, this is not particularly serious. But many XML-filtering applications will want to keep track of whether the text appears in a CDATA section, so that they can treat special characters properly.

Setting up the Parser

The following code sets up the parser and gets it started:

These lines of code create a SAXParserFactory instance, as determined by the setting of the javax.xml.parsers.SAXParserFactory system property. The factory to be created is set up to support XML namespaces by setting setNamespaceAware to true, and then a SAXParser instance is obtained from the factory by invoking its newSAXParser() method.

Note — The javax.xml.parsers.SAXParser class is a wrapper that defines a number of convenience methods. It wraps the (somewhat less friendly) org.xml.sax.Parser object. If needed, you can obtain that parser using the getParser() method of the SAXParser class.

You now need to implement the XMLReader that all parsers must implement. The XMLReader is used by the application to tell the SAX parser what processing it is to perform on the document in question. The XMLReader is implemented by the following code in the main method.

Here, you obtain an XMLReader instance for your parser by invoking your SAXParser instance’s getXMLReader() method. The XMLReader then registers the SAXLocalNameCount class as its content handler, so that the actions performed by the parser will be those of the startDocument(), startElement(), and endDocument() methods shown in Handling Content Events. Finally, the XMLReader tells the parser which document to parse by passing it the location of the XML file in question, in the form of the File URL generated by the convertToFileURL() method defined in Setting Up I/O.

Setting up Error Handling

You could start using your parser now, but it is safer to implement some error handling. The parser can generate three kinds of errors: a fatal error, an error, and a warning. When a fatal error occurs, the parser cannot continue. So if the application does not generate an exception, then the default error-event handler generates one. But for nonfatal errors and warnings, exceptions are never generated by the default error handler, and no messages are displayed.

As shown in Document Events, the application’s event handling methods throw SAXException. For example, the signature of the startDocument() method in the ContentHandler interface is defined as returning a SAXException.

A SAXException can be constructed using a message, another exception, or both.

Because the default parser only generates exceptions for fatal errors, and because the information about the errors provided by the default parser is somewhat limited, the SAXLocalNameCount program defines its own error handling, through the MyErrorHandler class.

In the same way as in Setting up the Parser, which showed the XMLReader being pointed to the correct content handler, here the XMLReader is pointed to the new error handler by calling its setErrorHandler() method.

The MyErrorHandler class implements the standard org.xml.sax.ErrorHandler interface, and defines a method to obtain the exception information that is provided by any SAXParseException instances generated by the parser. This method, getParseExceptionInfo(), simply obtains the line number at which the error occurs in the XML document and the identifier of the system on which it is running by calling the standard SAXParseException methods getLineNumber() and getSystemId(). This exception information is then fed into implementations of the basic SAX error handling methods error(), warning(), and fatalError(), which are updated to send the appropriate messages about the nature and location of the errors in the document.

Handling NonFatal Errors

A nonfatal error occurs when an XML document fails a validity constraint. If the parser finds that the document is not valid, then an error event is generated. Such errors are generated by a validating parser, given a document type definition (DTD) or schema, when a document has an invalid tag, when a tag is found where it is not allowed, or (in the case of a schema) when the element contains invalid data.

The most important principle to understand about nonfatal errors is that they are ignored by default. But if a validation error occurs in a document, you probably do not want to continue processing it. You probably want to treat such errors as fatal.

To take over error handling, you override the DefaultHandler methods that handle fatal errors, nonfatal errors, and warnings as part of the ErrorHandler interface. As shown in the code extract in the previous section, the SAX parser delivers a SAXParseException to each of these methods, so generating an exception when an error occurs is as simple as throwing it back.

Note — It can be instructive to examine the error-handling methods defined in org.xml.sax.helpers.DefaultHandler. You will see that the error() and warning() methods do nothing, whereas fatalError() throws an exception. Of course, you could always override the fatalError() method to throw a different exception. But if your code does not throw an exception when a fatal error occurs, then the SAX parser will. The XML specification requires it.

Handling Warnings

Warnings, too, are ignored by default. Warnings are informative and can only be generated in the presence of a DTD or schema. For example, if an element is defined twice in a DTD, a warning is generated. It is not illegal, and it does not cause problems, but it is something you might like to know about because it might not have been intentional. Validating an XML document against a DTD will be shown in the section .

Running the SAX Parser Example without Validation

The following steps explain how to run the SAX parser example without validation.

To Run the SAXLocalNameCount Example without Validation

1. Save the SAXLocalNameCount.java file in a directory named sax .
2. Compile the file as follows:

Choose one of the XML files in the data directory and run the SAXLocalNameCount program on it. Here, we have chosen to run the program on the file rich_iii.xml.

The XML file rich_iii.xml contains an XML version of William Shakespeare’s play Richard III. When you run the SAXLocalNameCount on it, you should see the following output.

The SAXLocalNameCount program parses the XML file, and provides a count of the number of instances of each type of XML tag that it contains.

Open the file data/rich_iii.xml in a text editor.

To check that the error handling is working, delete the closing tag from an entry in the XML file, for example the closing tag

, from line 21, shown below.

EDWARD, Prince of Wales, afterwards King Edward V.

Run SAXLocalNameCount again.

This time, you should see the following fatal error message.

As you can see, when the error was encountered, the parser generated a SAXParseException, a subclass of SAXException that identifies the file and the location where the error occurred.

Источник