seems like the cut-function provides the url urlencoded and ed2k-programmes like 
emule don't accept these urls.

(No comment was entered for this change.)

I also have this problem.
It seems that chrome can't decode the ed2k protocol url correctly.

sometimes chrome decode the ed2k url correctly just like blow:
http://bbs.verycd.com/topics/10631/
all the ed2k links works perfect, it lunched my emule in my hdd.

sometimes it can't decode the character ‘|’ correctly, it becomes  %7c, this is 
not a valid ed2k url, even copy it to the clipboard, emule software can't accept it.

when the ed2k url contains other language words such as chinese , japanese， it 
failed to lunch emule surely.
for another example
http://www.verycd.com/topics/192390/

same here, not working links from verycd.com

All exported ED2k link for the emule softwear missed "ed2k:" the whole URL.This will 
lead the link unidentified to the software.

On the other hand the exported link notice comes out very slow.Since the ED2k link 
normally gathered dozens it affect user badly.

me too,not working links from verycd.com

I can confirm this bug, I copied an ed2k link from a website I won't mention here.. 
It should have looked like this:

ed2k://|file|Some.File.With.Some.Extension|1234567890|9D7AABEFG730BBC|
h=6DEFXX43392XXEE|/

but instead, Chrome gave me this:

ed2k://%7Cfile%7CSome.File.With.Some.Extension%7C1234567890%7C9d7aabefg730bbc%7Ch
%3D6defxx43392xxee%7C/

Note: this ed2k link will likely be invalid, this is on purpose, it's merely here to 
show the unwanted encoding that Chrome does.

Is there some eta on when this will be fixed, or otherwise adressed?

i like chrome but adding ed2k links or copying isnt able yet.

I also confirm this problem!
This is the correct link:
ed2k://|file|file.extension|11111|ABCD678|h=ABCD678|/
This is the Chrome version of the link:
ed2k://%7Cfile%7Cfile.extension%7C11111%7CABCD678%7Ch%3DABCD678%7C/
The problem happens with the '|' and '='.

Hmm.. should we special-case ed2k protocol? I think Emule is extremely popular in 
East Asia.

Update: I managed to get Chrome working with aMule (http://www.amule.org/). Turned 
out the ed2k protocol handler was still pointing to eMule Plus 
(http://emuleplus.info/) which I had installed before. The handler now points to the 
program ed2k.exe provided by aMule.

This is what happens now when I click an ed2k link in Chrome:

- Click the ed2k link.
- A message appears asking permission to start the program ed2k.exe with the clicked 
link.
- I give permission.
- The link is succesfully added to my aMule download list.

Maybe this helps fixing problems that are still there with the ed2k protocol.

Perhaps refrain from urlencoding URIs with unknown schemes?  Making an exception for 
eMule seems more like a hack than a solution, as other protocols might have this.

However, based on wikipedia:URI_scheme (a list of around 140), ed2k seems to be the 
only common one. 

Brett:

1. I'm not familiar with the URL grammar: is | a valid character?
2. Is this something we'd need to fix in Chromium or upstream to Google URL?

1. I'm not familiar with the URL grammar: is | a valid character?

| is not valid in a host name, which is how it's used here. I need to figure out why 
other browsers allow this.

2. Is this something we'd need to fix in Chromium or upstream to Google URL?

If we fix it, it would be in googleurl.

(No comment was entered for this change.)

About a year ago I "fixed" GoogleURL to treat URLs containing "://" as standard:
  http://b/772411
I now think this change was incorrect. We should be treating this as a path URL and 
just passing all the data through with non-ASCII characters escaped.

I believe this will cause a regression for some AIM links generated by forms. See 
issue 7837 for this.

 Issue 8160  has been merged into this issue.

still no work-arounds for this problem?

(No comment was entered for this change.)

no owner for this issue? Oh my god, I am waiting for some one to fix this bug so long 
time. Is there any hope?

I think Chrome's behavior is supported by the spec, and it only seems to affect this 
one program, so it has not been a priority for me. I agree this should be fixed, 
however.

 Issue 11163  has been merged into this issue.

 Issue 12139  has been merged into this issue.

This is really a problem, isn't it?

 Issue 13898  has been merged into this issue.

So this is going to be left this way? It's not a great user experience to open other 
browser just to clic a link. Perhaps it's not stardand and your behave is the correct 
one but a link that works in whatever browser except chrome looks to a problem in your 
browser, and in some countries emule is as popular or more that bittorrent so think 
about a big problem in the number of users it's affecting.

This problem also occurs for other applications like Growl for Windows. In this case 
it even removes all ":"-characters after the xx://. This should really be fixed!

just wanted to reiterate the point made by FrozenCow - even if the url-escaping is
not fixed, stripping out subsequent colons completely is definitely incorrect.

original url: growl://display*http://mageuzi.com/trowl/twitterdisplay.xml
chrome-ified: growl://display%2Ahttp//mageuzi.com/trowl/twitterdisplay.xml

stripping out the second : without even escaping it changes the meaning of the data
entirely.

Same with chrome 3.0.195.21:

<a name="ed2klink" href="ed2k://|file|How.I.Met.Your.Mother.4x01.Do.I.Know.You.ENG.-
.sub.FR.HDTV-
Antoine.4011.[tvu.org.ru].avi|193348462|2782B514E54EF2DD74A92FE5794FD3A9|/">ed2k://|f
ile|How.I.Met.Your.Mother.4x01.Do.I.Know.You.ENG.-.sub.FR.HDTV-
Antoine.4011.[tvu.org.ru].avi|193348462|2782B514E54EF2DD74A92FE5794FD3A9|/</a>

donc work.

I don't understand this... I mean, it's obvious for you that this is a problem with 
standards/RFCs/whatever but now on the user side, it doesn't matter if chrome is being 
the right browser treating this URLs, for the user chrome is the broken one as all 
other work but yours/our browser. So please, give a look at this, make some workaround 
or whatever you think is necessary and fix this please.

The fix in comment 17 still makes me nervous. I'm leaning toward special-casing ed2k.

special-casing ed2k only fixes the problem for ed2k though. wouldnt it be better to
fix the problem for all third-party url handlers?

if it is a security issue that requires special characters in urls to be escaped,
that is fine and can probably be worked with by the handling app. however, as pointed
out in comments 28 and 29, some characters are stripped out completely which gives
the handling app no way to know what the original values were.

Background:

There are a number of types of URLs in the system. The relevant two types are what we call "standard" and 
"path". Standard URLs have a possible user info section (username:password), followed by a valid hostname, 
followed by an optional colon and port. We generally follow the spec closely with a few exceptions for 
compat. We'll feel free to do transformations on these, escaping some characters and unescaping others to 
generate something canonical. We'll completely fail for certain invalid characters like '|'. It is not 
reasonable to allow arbitrary characters here.

On the other hand, path URLs have a scheme followed by a colon, followed by unstructured data that we make 
no assumptions about. Examples of this include "about:" and "data:".

We used to have a list of schemes we'll treat as "standard" which basically included "http", "https", and 
"ftp". There were some problems with this. Certain apps like AIM or QuickTime have special schemes "aim:" 
for example. Many of these apps expect us to do "regular" canonicalization on the URL like we would for an 
http URL, including escaping, unescaping, and handling International Domain Names (IDN, for example, for 
Chinese host names). Just passing the original data with no transformations could confuse these since they 
were expecting ASCII host names (or a bunch of other transformations).

As a result, I changed it (as explained in comment 17) to treat any URL with a "://" as "standard" which 
my research at the time suggested was correct. This made AIM and these other cases happy. Although I think 
this change makes sense, it is incorrect since clearly some programs expect otherwise.

We can't just allow these characters or change escaping rules for standard URLs since security on the web 
depends on these rules. My recollection of the original bug (which I can't seem to find) could be 
completely mistaken, and possibly that case we tested is broken in all browsers (like external programs 
expecting us to handle IDN transformations).

It could also been I'm misremembering and the entire issue we had resulting in the ":// means standard" 
change was resolving relative URLs relative to "path" URLs which is issue 7837. This kind of sucks, 
because I think doing IDN transformations for URLs like ed2k is correct, and we can't have it both ways: 
either the URL is standard and we do the correct transformations on it, or it's not and we can't.

Not doing these means that if you have a page with a link to "myscheme://你好.com.tw/foobar" we would give 
UTF-8 to the program: "myscheme://\e4\bd\a0\e5\a5\bd/foobar" rather than some punycoded ASCII it can 
actually lookup in DNS (which it's probably expecting): "myscheme://xn--6qqa088eba/foobar". I think this 
is what most other browsers *don't* do, so these links are just broken for people that don't punycode 
their IDN.

We could work around this and add an exception for the few known schemes like ed2k that depend on this 
behavior to treat them as "path" URLs, which will mean that we perform no transformation on the URLs. 
There is some chance that some things will still be broken if any relative URLs are resolved against ed2k 
URLs, which won't work (example: "ed2k://foo/bar" + "/la" should be "ed2k://foo/la" and making this work 
is issue 7837).

I hope this explains why this bug hasn't been fixed yet.

so y does internet explorer and firefox not have the same problem?

I have developed a workaround for windows using batch files and a little replace 
utility. Hopefully, better gifted scripters will simplify it, generalise it, and 
develope linux versions.

For me, It's meant to launch amulecmd to send the ed2k link from my windows laptop to 
my linux server.

I suppose that you have amule installed to listen to external connections on the 
linux machine, and the client on windows to connect to the linux one (look for amule 
howtos).

It also should not interfere with ed2k links launched from Firefox or Explorer.

1) So first, register the ed2k to launch the file:
C:\Program Files\aMule\ed2k_remote.bat
(For instructions, see http://wiki.amule.org/index.php/Ed2k_links_handling )

2) Download ReplaceStr:
* http://www.cylog.org/files/cmdline/rstr112.zip 
* Instructions: http://www.cylog.org/tools/cmdline.jsp
And place replacestr.exe in C:\Program Files\aMule\

3) Third, create ed2k_remote.bat in 
C:\Program Files\aMule\
with the following text:

rem -- START OF SCRIPT
@echo off
cd "c:\Program Files\aMule\"
set link=%1
for /f "useback tokens=*" %%a in ('%link%') do set link=%%~a
echo "amulecmd.exe" /h ubuntuhost /P mypassword /c "add 
%link%" >temp.bat
replacestr "%7C" "|" <temp.bat >temp2.bat
call temp2.bat
REM pause used to see error messages, remove if unneeded
@pause
REM --END OF SCRIPT--

4) For launching other programs, change the line with 
echo "amulecmd.exe"...
as needed.

Final sidenote: My honest opinion is that the program launched to treat ed2k links 
(Emule, Amule, etc) should do this work represented here, since "|" is not a valid 
URL character, and the correct behaviour is to encode it. It's not so difficult, and  
%7C should have no other meaning for them.

Also, to avoid Chrome warning message before opening ed2k lins, visit:
http://sites.google.com/a/bytesiege.com/emulelinksubmitter/chrome-external-protocol-
problem

#39...

The problem is not just that emule (I don't know if amule fails) don't get links with 
this charecters, is that chrome doesn't even treat them as links, so if chrome do 
nothing when you clic on them how's your worarround supposed to work?

Chrome treats them as links, but it send "%7C" whenever it finds the character "|" 
(you can tell in the warning it shows). Then neither emule or amule knows how to 
treat the link in that case.

Anyway, it allways shows at least the warning, unless you deactivate it (comment 40). 

I have encountered many cases where the web page has made the ed2k links avalaible in 
javascript (which also works), but their database is wrong somehow, so the links are 
blank, and you can tell only by looking to the page source code. But that is the 
page's fault.

I think the problem is that this issue has merged not so similar problems. The one I 
speak (the only problem I've found so far with ed2k links) is explained in this issue 
http://code.google.com/p/chromium/issues/detail?id=13898 now merged in this one. As 
you can see with my attached file there, chrome treats this links as no links, you 
cannot even copy them to wallpaper (with emule this could be a messy workaround but 
at least something working as emule looks at wallpaper for links if you say it to). 

So I don't know the problem your script fix (perhaps it's only related to amule) but 
the one I suffer has nothing to do with emule but with chrome.

I think you mean "clipboard" instead "wallpaper". I had the same problem with emule, 
fixed with this.

But i could "copy" and "paste" ed2k links, they where not empty. The problem, as many 
previous posts here has commented, is that where there should appear a "|" symbol, 
Chrome makes it a "%7C" in the link.

If you copy the link, paste in notepad, replace all "%7C" with "|", and copy and 
paste again in emule or amule, the links work again. So that is the function the 
script is replicating.

I think that the matter here is that, as you have mentioned, there are several 
strange behaviours merged in this bugs, and mine has been a different one from yours.

Hope you can find a solution also! ;-)

I'm all against special-casing in general, but at least until a better solution is 
found or agreed upon - please, just do it...

here is what i did... hope it connects and helps anyone...

1. I've installed java
2. I've opened emule, went to Tools > paste ed2k links
3. pasted a previously copied address, pressed download, it gave me an error...
4. went to the site I took the copied address from and clicked on the ed2k link again, 
and it worked..
weird though.. but it worked.