Opened 11 years ago
Last modified 11 years ago
#10319 confirmed Bug
Link Properties Dialog should search both Encoded and UTF-8 values
Reported by: | Jakub Ś | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | General | Version: | 3.0 |
Keywords: | Oracle | Cc: |
Description
Background:
It looks that new browsers handle UTF-8 characters in URLs. They show utf-8 characters to user but in background use encoded values to gets right URL.
http://stackoverflow.com/questions/2742852/unicode-characters-in-urls
http://stackoverflow.com/questions/6625035/utf-8-characters-in-urls[[BR]]
http://en.wikipedia.org/wiki/Internationalized_domain_name
It also looks like that old or very old browsers handle encoded values only.
Real-life use case:
It is possible that application has to handle many types of browsers including old ones thus link created in CKEditor e.g. <a href="#első">line1</a>
may get transformed to <a href="#els%C5%91">line1</a>
. Href value may end up in URL thus it gets encoded on server-side
CKEditor issue: Beacuse of the above, code loaded into editor may look like:
<p><a href="#els%C5%91">line1</a></p> <p>many lines...</p> <p><a id="első" name="első">line101</a></p>
If you doble-click on link, link properties dialog will show but value első will not be shown as selected in dropdown.
I think editor should look for both UTF-8 and encoded value (encodeURIComponent perhaps).
The same thing should be done when pressing ok in link properties dialog. It should be checked if current value is első or els%C5%91, next new value should be compared with current one and if they match (probably only if they match) current one should be left. Such check should prevent changing els%C5%91 to első but if application does such transformation on request basis then perhaps this isn't necessary in editor.
Problem can be reproduced from CKEditor 3.0 in both CKE 3.x and CKE 4.x (v4)