Closed mamift closed 7 months ago
marcominerva
commented
7 months ago I have just tried and I get no exception with a DOCX file that contains an URI like http:\\google.com. I'm using Kernel Memory v0.35.240318.1.
If you still experience the issue, could you please attach a file that showcases the problem?
mamift
commented
7 months ago OK did a bit of more digging. Recent versions of Word (don't know the earliest version exactly,) are autocorrecting the wrong slash with https:\\ and http:\\ protocol prefixes before saving the file. If you use a non-standard protocol prefix, such as quic:\\ or test:\\, Word won't auto correct and persist the \ in the file without allowing you to re-create the exception.
It seems the DOCX files I'm working with go back up to 20 years, and have been made using a range of different Word versions, such as Word 2007, 2010 (2011 for Mac), 2013, 2016, 2019, and 365 versions etc. And the exact pattern that triggers the error has to have at least 3 wrong slashes with non-whitespace characters after the 3rd slash. So these will trigger the error,
quic:\\1234\456
wss:\\blah\12Strangely the following don't trigger the error; there needs to be trailing non-whitespace chars after a 3rd \:
quic:\\1234\
wss:\\blah\
http:\\intranet\Edit: OK actually here's an example of a docx file that triggers it on my end. The files I'm working with have links to a specific custom document management system protocol:
marcominerva
commented
7 months ago Hi @mamift. With your file, I was able to recreate the problem.
This is an issue of the OpenXml library itself (see https://github.com/dotnet/Open-XML-SDK/issues/715). It seems to be resolved in version 3.x, but unfortunately ClosedXML (that is used to read Excel files), is still on version 2.x. A fix for this has been merged (https://github.com/ClosedXML/ClosedXML/pull/2248), but it has not been published yet. According to the milestone page (https://github.com/ClosedXML/ClosedXML/milestone/26?closed=1), it will be available in the next 0.104 version.
dluc
commented
7 months ago The latest ClosedXML 0.102.2 added a warning in case one uses a non-supported version of OpenXML, see https://github.com/ClosedXML/ClosedXML/pull/2246
Closing this issue since there's nothing we can do until https://github.com/ClosedXML/ClosedXML/issues/2220 is addressed and a new nuget is released. I would suggest following up with ClosedXML project, e.g. supporting with PRs and tests where possible.
mamift
commented
7 months ago OK well for anyone else who comes across this same issue, there's a workaround: just bulk remove all links in the document and keep the text. I wrote an extension method for it:
using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Wordprocessing;
namespace Program.Extensions;
public static class OpenXmlExtensions
{
/// <summary>
/// Assuming the current <paramref name="docStream"/> is a <see cref="WordprocessingDocument"/>, bulk flatten all hyperlinks (remove the link, but keep the text).
/// </summary>
/// <param name="docStream"></param>
public static void BulkRemoveHyperlinks(this Stream docStream)
{
using var doc = WordprocessingDocument.Open(docStream, true, new OpenSettings() {
AutoSave = true
});
doc.BulkRemoveHyperlinks();
}
/// <summary>
/// For the current <see cref="WordprocessingDocument"/>, remove the links on all in-document hyperlinks but keep the text inline.
/// </summary>
/// <param name="doc"></param>
public static void BulkRemoveHyperlinks(this WordprocessingDocument doc)
{
if (doc.MainDocumentPart?.Document.Body == null) return;
foreach (var link in doc.MainDocumentPart.Document.Body.Descendants<Hyperlink>()) {
if (!string.IsNullOrEmpty(link.Id)) {
var hr = doc.MainDocumentPart.HyperlinkRelationships.Single(hr => hr.Id == link.Id);
doc.MainDocumentPart.DeleteReferenceRelationship(hr.Id);
}
var linkText = link.InnerText;
var run = new Run(new Text(linkText));
link.Parent?.ReplaceChild(run, link);
}
if (!doc.AutoSave) {
doc.Save();
}
}
}
Context / Scenario
So I'm using the serverless implementation just for testing and I get this error on ingesting word documents that have links with the wrong backslash.
Method used:
IKernelMemory.ImportDocumentAsync()(any of the overloads)What happened?
So ingesting documents returns this error when the documents have links with the wrong slash:
DocumentFormat.OpenXml.Packaging.OpenXmlPackageException: A malformed URI was found in the document. Please provide a OpenSettings.RelationshipErrorRewriter to handle these errors while opening a package.So for instance: 'http://google.com' is the properly formatted URI but users have (and in lots of documents) entered it as 'http:\\google.com'. In my case, there are lots of DOCX files with many links formatted using the wrong slash.
I filed this as a bug because, obviously when a user uses Microsoft Word to enter these wrong-URIs, no error is thrown otherwise these bad-URI links wouldn't be in the documents in the first place. This is also very easy to replicate as well, just create a new Word document and add a 'https:\\' link to some text and try to run any of the
IKernelMemory.ImportDocumentAsync()method overloads.Importance
a fix would make my life easier
Platform, Language, Versions
Kernel memory: 0.32.240307.3+68ee7ef Being used in an app which is: .NET 8, Blazor server, C#, Visual Studio 17.9
Relevant log output