Tested the issue on chrome reported version 65.0.3325.181 using windows-10 with steps mentioned below:
1) Launched chrome reported version, dragged and dropped the index.html file provided in comment#0
2) Clicked on the link, again clicked on "Open Microsoft office 2013"
3) System throws error message as: "This action couldn't be performed because Office doesn't recognize the comment it was given"

@Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in reproducing the issue in better way.

Thanks!

Deleted: 832093.mp4 1.1 MB

	832093.mp4 1.1 MB View Download

The steps in the video are correct. 
However, I have never received the error message seen in the video. So I did some research and these things could probably help to solve it:
a) Have you created a dummy file in 'c:/Documents/Documentä.docx'?
b) Windows user must have access rights to the file 'c:/Documents/Documentä.docx'. The link in attachment "index.html" I provided opens the file in edit mode. So user should probably not have read-only access to the file. Set appropriate access rights or use "index_read_only.html" attached in this comment, which has "ofv" instead of "ofe" so it should open file in read-only mode.
c) MS Office installation may be corrupted. Try to repair the installation.

Unfortunately I do not have Office 2013, I tested it on Office 2016. But I learned that both versions support these links. I'll try to investigate further - maybe find Office 2013 installation and let you know if I've found something.

Deleted: index_read_only.html 154 bytes

index_read_only.html 154 bytes View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

My findings:
Office 2016 is required to reproduce the issue based on the original description!

Office 2013 apparently supports only using 'http://' path instead of 'file://'. If 'file://' is used, it would result in the error "This action couldn't be performed because Office doesn't recognize the command it was given". I succeeded in opening files over http in read-only mode even with special characters in the URI for both Office 2013 and Office 2016.

Can we get confirmation of #5? Thanks!

As this requires Office 2016 to test and confirm, which is not available with ET team as of now. The latest version available as of now is 2013(where the issue is not reproducible), raised a request with local Network folks to install 2016 on the system, till then, if possible could anyone from Inhouse team please check this in Non-Corp on office 2016 and help in triaging it, hence adding TE-NeedsTriageFromHYD label to it.

Thanks

Tested the issue using #66.0.3359.181 and #67.0.3396.56 on Win 10 non-corp laptop as per the steps mentioned below.

Steps:
1. Launched Browser
2. Opened attached html
3. Clicked on Documentä and nothing is happening (Find the screencast)

@peto.amrich: Request you to update Chrome to latest version and check if you still face the issue?

Requesting Internals>PlatformIntegration team for further triaging of the issue as Office 2016 isn't available at TE end.

Thanks!!

Deleted: ilri.mp4 1.2 MB

	ilri.mp4 1.2 MB View Download

As per comment# 8 & 9, unable to test and confirm the issue from TE end as Office 2016 isn't available, hence removing Needs-TestConfirmation label, feel free to add it back if required.

Hence requesting someone from the Internals > PlatformIntegration team have a look at this issue and help in further triaging it.

Thanks!

Hi Ben. Do I recall correctly that you did some protocol registration work a while back? Do you know anything about how we handoff a link like href="ms-word:ofe|u|file://c:/Documents/Documentä.docx"? Thanks.

Matt is the expert on this kind of thing.

I don't have a Windows PC with Office to test this out. So I'm just going by the text of the original bug report.

This seems like a bug in MS Word. This isn't a file URL that Chrome is opening; it's a ms-word URL, so Chrome simply normalizes the URL (by parsing [1] then serializing [2]), then invokes Microsoft Word with the normalized URL as command-line argument. The correct serialization of "ms-word:ofe|u|file://c:/Documents/Documentä.docx" (running [1] then [2]) is "ms-word:ofe|u|file://c:/Documents/Document%C3%A4.docx".

If Microsoft Word is unable to interpret "%C3%A4" as "ä", that is a bug in Word. These two should always be treated exactly equivalently. While it is still valid to pass "ä" in a URL, the canonical representation is "%C3%A4", so that is what Chrome does ([2] requires that the canonical encoding is used when transmitting a URL). Ensuring that all non-ASCII characters are encoded avoids the need to worry about different character encodings when passing command-line arguments to external applications.

Note that I'm referencing the new "URL Standard" which unfortunately discards the previously correct terms "IRI" and "URI". But since the Microsoft documentation references RFC 3987, I'll briefly explain in the old terminology: "ms-word:ofe|u|file://c:/Documents/Documentä.docx" is a IRI, whose URI form [3] is "ms-word:ofe|u|file://c:/Documents/Document%C3%A4.docx". We transmit the URI, not the IRI, when invoking the external protocol handler. If Word was actually following RFC 3987, it would correctly decode "%C3%A4" as "ä" when processing the file URL inside the ms-word URL.

I don't know what Firefox and Edge are doing to make this work, but it sounds like they are not correctly normalizing the URL. This is working as intended.

[1] https://url.spec.whatwg.org/#concept-url-parser
[2] https://url.spec.whatwg.org/#url-serializing
[3] https://www.ietf.org/rfc/rfc3987.txt

@mgiuca "Document%C3%A4.docx" and "Documentä.docx" are completely different files. How could Word distinguish between them?

#14 Yes, they're completely different *filenames*, but in a URL those both mean the same thing.

Let's say you had two files in a folder in Windows with those two names. Here's how various file URLs map onto file system paths:

URL "Documentä.docx" -> file path "Documentä.docx"
URL "Document%C3%A4.docx" -> file path "Documentä.docx"
URL "Document%25C3%25A4.docx" -> file path "Document%C3%A4.docx"

In other words, the file "Documentä.docx" is addressable with *either* URL "Documentä.docx" or "Document%C3%A4.docx", though the former is not canonical. The file "Document%C3%A4.docx" (an unusual file name!) is addressible with the double-escaped URL 
"Document%25C3%25A4.docx".

If Word is given "Document%C3%A4.docx", it should not be looking for a file called "Document%C3%A4.docx". It should be decoding those percent-encoded octets *before* it ever goes to look it up in the file system. All web browsers do this if you paste a file:/// URL directly into the address bar (try it with the same example but named ".html").