File corruption after replacing hyperlinks with Aspose.Words

Aspose.Words Product Family
1

We’ve recently run into an issue while replacing hyperlinks in a number of customer sample files using Aspose.Words. Although the links appear to be updated in the resulting documents, they do not work as expected when viewed through SharePoint Online’s web view.

The symptoms we’ve observed are:

  • The URL starts with "ttps://" instead of "https://".
  • A strange "\l" fragment is appended to the end of the URL.
  • In some cases, the hyperlink text is replaced with something like "HYPERLINK URL" and begins with an unusual character.

Unfortunately, we are unable to share the original customer files, but we’ve created a simplified sample file and a sample C# console application that demonstrate the first two issues. You can download them here:

Steps to reproduce the issue:

  1. Run the provided console application.
  2. Check the output folder under \bin\Debug\Sample File\.
  3. Observe the generated files:
  • "Sample File - Updated.docx" (simple link change)
  • "Sample File - Updated1.docx" (link change + setting the SubAddress element to an empty string)

What we noticed:

  • Both output files are flagged as corrupt when opened in Microsoft Word. After letting Word repair and save them, we uploaded the repaired documents to SharePoint Online.
  • In "Sample File - Updated.docx", the first and sixth links (after being changed from google.com to yahoo.com) do not work in SharePoint Online.
  • In "Sample File - Updated1.docx", those same links appear visually broken or corrupted in SharePoint Online.

1691×852 45.6 KB

Also, we tried to check the XML structure of the file and noticed that even though the original sample file has a single “<w:instrText” XML element for each hyperlink, after modifying the file with Aspose, it splits into different “<w:instrText” XML elements where the last of them holds that strange “\l” character.

1951×538 72.5 KB

1972×646 92.8 KB

We also want to tell that this issue reminds us of another issue we reported 3 years ago - Links in SharePoint Online's web view are broken in Aspose.Words 22.2 and other versions. That issue was solved in Aspose.Words 22.4, but apparently Aspose.Words still produces the same behavior when it tries to modify these specific Word (.docx) files.

We’d appreciate your insights into why this might be happening.

Best, Vahe.

2

@vahem

It seems you are experiencing issues with hyperlink replacements in documents processed by Aspose.Words, particularly when viewed in SharePoint Online. The problems you’ve described, such as URLs starting with "ttps://" instead of "https://" and the addition of a "\l" fragment, suggest that there may be an issue with how the hyperlinks are being modified in the document.

Here are some steps and considerations that might help you troubleshoot and resolve the issue:

  1. Check Hyperlink Replacement Logic: Ensure that your hyperlink replacement logic correctly formats the URLs. When setting the hyperlink address, make sure to validate the URL format before assignment. For example, you can use a regular expression to ensure that the URL starts with "http://" or "https://".

  2. Review the Hyperlink Structure: The structure of hyperlinks in Word documents can be complex. Each hyperlink is represented as a field, and it consists of several nodes. When modifying hyperlinks, ensure that you are correctly updating both the field code and the display name. The field code should be formatted as HYPERLINK "url" without any additional characters.

  3. Use the Provided Code Example: You can refer to the provided code example for replacing hyperlinks. It demonstrates how to find and modify hyperlinks in a Word document. Make sure to adapt it to your specific needs, especially regarding the URL formatting.

    Here’s a simplified version of how you might replace hyperlinks:

    Document doc = new Document("path/to/your/document.docx");
foreach (Field field in doc.Range.Fields)
{
    if (field.Type == FieldType.FieldHyperlink)
    {
        FieldHyperlink hyperlink = (FieldHyperlink)field;
        if (!hyperlink.IsLocal) // Ensure it's not a local hyperlink
        {
            hyperlink.Address = "https://new-url.com"; // Ensure the URL is correctly formatted
            hyperlink.Result = "New Display Text"; // Update the display text
        }
    }
}
doc.Save("path/to/save/updated-document.docx");

  4. Inspect the XML Structure: If you have access to the XML structure of the original and modified documents, compare them closely. Look for discrepancies in the <w:instrText> elements, as these can affect how hyperlinks are rendered in applications like SharePoint.

  5. Test with Different Versions: Since you mentioned a previous issue that was resolved in a specific version of Aspose.Words, consider testing your code with the latest version of the library. There may have been additional fixes or improvements related to hyperlink handling.

  6. Contact Support: If the issue persists, consider reaching out to Aspose support with detailed information about your findings, including the sample files and code snippets. They may provide insights or fixes specific to your scenario.

By following these steps, you should be able to identify and resolve the hyperlink issues in your documents. If you have further questions or need additional assistance, feel free to ask!

3

@vahem It looks like the problem is not in Aspose.Words, but in the way how you work with file streams. Please try modifying your code like this:

private static void UpdateHyperlinkAndSaveFile(bool setEmptySubAddress)
{
    string filePath = @"C:\Temp\in.docx";
    string updatedFilePath = !setEmptySubAddress
        ? @"C:\Temp\out_1.docx"
        : @"C:\Temp\out_2.docx";

    string fromLink = @"https://www.google.com/";
    string toLink = @"https://www.yahoo.com/";

    using (FileStream fs = File.OpenRead(filePath))
    {
        var loadOptions = new Aspose.Words.Loading.LoadOptions();
        Document document = new Document(filePath, loadOptions);

        foreach (Node node in document.Sections)
        {
            if (!(node is Section section))
                continue;

            foreach (Field rangeField in section.Body.Range.Fields)
            {
                if (rangeField.Type == FieldType.FieldHyperlink)
                {
                    FieldHyperlink hyperlink = (FieldHyperlink)rangeField;
                    if (hyperlink.Address == null || hyperlink.Address != fromLink)
                        continue;

                    Console.WriteLine("Old hyperlink address: " + fromLink);
                    Console.WriteLine("New hyperlink address: " + toLink);
                    Console.WriteLine($"Updating (setEmptySubAddress={setEmptySubAddress})...");

                    hyperlink.SubAddress = setEmptySubAddress ? string.Empty : null;
                    hyperlink.Address = toLink;

                    Console.WriteLine("Updated hyperlink address: " + hyperlink.Address);

                    using (FileStream updatedFs = File.Create(updatedFilePath))
                    {
                        document.Save(updatedFs, SaveFormat.Docx);
                    }
                }
            }
        }
    }
}
4

@alexey.noskov Thanks for your response. Unfortunately, that does not make much difference. Even though, the “corruption” dialog does not appear, Aspose.Words still modifies the file the way that makes the links corrupt when you view the file in SharePoint Online web view.

Sample File - Updated.docx (21.8 KB)

Sample File - Updated1.docx (21.9 KB)

Sample File.docx (26.5 KB)

2454×1017 135 KB

We see the same symptoms in the XML - the single instrText element is separated into 4 different elements and the last of them includes a strange “\l” character.

5

@vahem I do not see this problem in MS Word. Most likely this is a bug in SharePoint Online web view.

If this is really a problem for SharePoint Online web view, please try calling Document.JoinRunsWithSameFormatting() before saving.

6

@alexey.noskov That’s correct, visually the issue is not seen in MS Word, but is seen in the SharePoint Online web view.
I tried the Document.JoinRunsWithSameFormatting() solution and even though it reduced the number of “<w:instrText>” elements by one, Aspose.Words still splits the single “<w:instrText” element into multiple elements and adds this strange “\l” character in the end. This is not an issue in the original file, so we are almost certain that this is a bug in Aspose.Words.

1987×579 88.9 KB

As a result, the link is still broken in SharePoint online web view

1582×811 44.5 KB

Can we know why Aspose.Words splits single “<w:instrText>” element into multiple elements? What is the “\l” character in the end of the new URL? Is there any connection between this issue and Links in SharePoint Online's web view are broken in Aspose.Words 22.2 and other versions?

7

@vahem Splitting field code into multiple run nodes does not violate OOXML specification, so there is no bug here.
\l flag in HYPERLINK field code specifies a location in the file, such as a bookmark, where this hyperlink will jump.

In your case it is empty, because sub address is set to empty string. As a workaround you can simply set sub address to null if it is an empty string.

We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): WORDSNET-28170

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

8

@alexey.noskov Thanks for opening the internal ticket, we are looking forward to it!

P.S. Our console application already includes both versions (setting sub address to empty string and null). As I mentioned, in both cases links are being not functional. We do not see the “\l” character when the sub address is set to null, but the links are simply not clickable in the SharePoint Online web view.

9

@vahem As I have mentioned, the hyperlink written by Aspose.Words is correct and does not violate OOXML specification. The bug seems to be in SharePoint Online web view, since the problem is not reproducible in other DOCX readers such as MS Word, WPS Office, Open Office or Libre Office.