Link wordt niet of niet correct geparsed

[Coffeemonster]

In Coffeemonster in "Raad de locatie a.d.h.v. de foto! Deel 2" probeer ik een link naar de Spaanse Wikipedia te posten met de url-tag, maar dat levert een niet-werkende link op, ook als je verschillende manieren gebruikt:

Linkje

Linkje

Wikipedia: Wikipedia, la enciclopedia libre/Iglesia_de_San_José_(San_Cristóbal)
(was: https://es.wikipedia.org/wiki/Iglesia_de_San_José_(San_Cristóbal)

https://es.wikipedia.org/..._San_José_(San_Cristóbal)

Alle vier mogelijkheden leveren incorrecte resultaten op. Ik kwam een vergelijkbaar probleem een tijdje terug al eerder tegen, dus het is niet uniek voor deze url.

Struikelt de parser over bepaalde links? En zit dat in de haakjes in de link of zo? Is bit.ly of zo de enige oplossing (niet getest)?

[BlazeMuis]

https://es.wikipedia.org/..._San_José_(San_Cristóbal)

Nope dat werkt dus ook niet, was te proberen..

[Voor 24% gewijzigd door BlazeMuis op 16-11-2018 17:04]

[Hero of Time]

Haakjes is het probleem niet, maar de accenten op de e en o denk ik wel. Die zouden met netjes HTML encoded wel moeten werken.

Zo dus:
Wikipedia: Iglesia de San José (San Cristóbal)

code:

https://es.wikipedia.org/wiki/Iglesia_de_San_Jos%E9_(San_Crist%F3bal)

[Voor 47% gewijzigd door Hero of Time op 16-11-2018 17:22]

[ACM]

Hero of Time schreef op vrijdag 16 november 2018 @ 17:18:
Haakjes is het probleem niet, maar de accenten op de e en o denk ik wel. Die zouden met netjes HTML encoded wel moeten werken.

Inderdaad, dat zijn geen valide karakters voor in urls. Browsers vertalen dat helaas af en toe naar de gerepresenteerde karakters bij het copy&pasten uit de adresbalk, waardoor e.e.a. in principe niet meer de url is die je hebt geopend (maar wel wat je in de adresbalk ziet).

[crisp]

Hero of Time schreef op vrijdag 16 november 2018 @ 17:18:
Haakjes is het probleem niet, maar de accenten op de e en o denk ik wel. Die zouden met netjes HTML encoded wel moeten werken.

Zo dus:
Wikipedia: Iglesia de San José (San Cristóbal)

code:

https://es.wikipedia.org/wiki/Iglesia_de_San_Jos%E9_(San_Crist%F3bal)

Nee, zo:

Wikipedia: Iglesia de San José (San Cristóbal)

code:

https://es.wikipedia.org/wiki/Iglesia_de_San_Jos%C3%A9_(San_Crist%C3%B3bal)

(utf-8 url-encoded - overigens copy/paste vanuit de adresbalk in Firefox)

[Hero of Time]

@crisp, ik kon de URL niet zo uit m'n browser halen, dus heb ik de w3schools pagina er bij gepakt om de HTML entiteit te vinden en dat leek te werken.

[crisp]

quote: https://tools.ietf.org/html/rfc3986

Non-ASCII
characters must first be encoded according to UTF-8 [STD63], and then
each octet of the corresponding UTF-8 sequence must be percent-
encoded to be represented as URI characters.

Note dat in de voorganger (RFC 2396) dit nog ongespecificeerd was:

Internet protocols that
transmit octet sequences intended to represent character sequences
are expected to provide some way of identifying the charset used, if
there might be more than one [RFC2277]. However, there is currently
no provision within the generic URI syntax to accomplish this
identification. An individual URI scheme may require a single
charset, define a default charset, or provide a way to indicate the
charset used.

Browsers, webservers en applicaties doen gelukkig een heleboel wat betreft het fixen van foute URL's en het gokken van de gebruikte karakterset om dat weer te decoden