[php] Ampersand word vertaald terwijl dit niet moet.

[hobbeldebobbel]

Het gaat om dit soort urls:
example.com/Stad/Bagels%26Beans

Die worden in een .htaccess omgeschreven:

code:

RewriteRule ^(.*)$ index.php?u=$1 [NC,L]

Als ik nu echter kijk naar wat de waarde van $_GET is krijg ik dit:

code:

    Array
(
    [u] => Stad/Bagels
    [Beans] => 
)

Hoe kan dit? Want ik heb hem niet geencodeerd....

het lijkt erop dat er bij het herschrijven wat fout gaat. Want als ik naar:
example.com/index.php?u=stad/bagels%26beans ga, dan krijg ik:

code:

    Array
(
    [u] => Stad/Bagels&Beans
)

[ Voor 22% gewijzigd door hobbeldebobbel op 08-01-2010 14:11 ]

[MueR]

Zo werken URLs nou eenmaal. Die hebben die rare eigenschap om een querystring te splitten op de ampersand.

[Ventieldopje]

Wat is het nut van je mooie korte URL's als je rare tekens gaat gebruiken als ampersands, alsof mensen die URL dan nog kunnen onthouden. Beter kun je gewoon alle rare tekens vervangen door een _

[hobbeldebobbel]

@Phas0r Het doel is inderdaad mooie, korte en goed te onthouden urls. De bedrijfsnaam kan dan bijvoorbeeld een & bevatten, zoals bij "Bagels&Beans" een koffie bar in Eindhoven.

@MueR.... hmmm dat was neit het antwoord dat ik wilde horen...... mede ook vanwege bovenstaand commentaar op Phas0r

[NMe]

Je kan een & natuurlijk ook net zo makkelijk vervangen in je url door een uitgeschreven variant daarop.

[Cartman!]

En wat als je het gewoon puur doormapt naar PHP en in PHP pas de querystring uit elkaar trekt?

code:

<IfModule mod_rewrite.c>
    
    # Enable mod_rewrite
    RewriteEngine On

    # if not a file or dir; rewrite to index
    RewriteCond     %{REQUEST_FILENAME}     !-f             
    RewriteCond     %{REQUEST_FILENAME}     !-d
    RewriteRule     ^(.*)$                  index.php       [L]

</IfModule>

Dat moet gewoon goed werken:

code:

echo $_GET['toko'];

get.php?toko=Bagels%26Beans geeft dan netjes Bagels&Beans terug.

[hobbeldebobbel]

Ik heb het nu als volgt opgelost.

code:

RewriteRule ^(.*)$ index.php [NC,L]

en dan in mijn php:

code:

$arg2 = explode('/',$_SERVER['REDIRECT_URL']) ;
    $arg = array();
    foreach($arg2 AS $a){
        if($a != ''){
            $arg[] = $a;
        }
    }

[KabouterSuper]

url's mogen geen ampersand bevatten....alleen de query append! Dat is de reden dat je nat gaat. Een fix kan zijn om met [NE] te spelen, maar je aan de standaard houden is handiger.

[Shagura]

Als je ze gewoon encode zoals hier met %26 mag het dus wel. Maar ik meen me te herinneren dat het een security feature van mod_rewrite is dat hij eerst de url decode en dan rewrite. Anders kunnen er nogal rare dingen doorheen komen met slashes e.d. waar mensen vaak geen rekening mee houden. Misschien is het uit te zetten.

Zie ook deze flag uit de mod_rewrite documentatie:

'B' (escape backreferences)
Apache has to unescape URLs before mapping them, so backreferences will be unescaped at the time they are applied. Using the B flag, non-alphanumeric characters in backreferences will be escaped. For example, consider the rule:

RewriteRule ^(.*)$ index.php?show=$1

This will map /C++ to index.php?show=/C++. But it will also map /C%2b%2b to index.php?show=/C++, because the %2b has been unescaped. With the B flag, it will instead map to index.php?show=/C%2b%2b.

This escaping is particularly necessary in a proxy situation, when the backend may break if presented with an unescaped URL.

[Leftblank]

Shagura schreef op vrijdag 08 januari 2010 @ 14:48:
Als je ze gewoon encode zoals hier met %26 mag het dus wel.

Maar wanneer je 'm encode is 't weer onleesbaar voor den mensch en is 't een stuk logischer toch voor de uitgeschreven 'en' of 'and' te gaan

[Shagura]

Mee eensch, Ik probeerde alleen aan te geven waarom het herschrijven fout gaat

[MueR]

hobbeldebobbel schreef op vrijdag 08 januari 2010 @ 14:25:
@MueR.... hmmm dat was neit het antwoord dat ik wilde horen...... mede ook vanwege bovenstaand commentaar op Phas0r

Tja, de RFC voor URLs ligt toch al even vast zeg maar. Je zal dus gewoon ofwel moeten encoden, ofwel replacen zoals NMe aangaf. Helaas geld ook voor jou dat je jezelf zal moeten conformeren aan de regels op het web

[.oisyn]

MueR schreef op vrijdag 08 januari 2010 @ 14:16:
Zo werken URLs nou eenmaal. Die hebben die rare eigenschap om een querystring te splitten op de ampersand.

Onzin, op een %26 hoort niet gesplitst te worden. Net als bij example.com/index.php?u=stad/bagels%26beans. Het gaat fout door de rewrite, zoals Shagura ook al aantoont.

[boe2]

.oisyn schreef op vrijdag 08 januari 2010 @ 15:36:
[...]

Onzin, op een %26 hoort niet gesplitst te worden. Net als bij example.com/index.php?u=stad/bagels%26beans. Het gaat fout door de rewrite, zoals Shagura ook al aantoont.

Op een %26 niet nee, op een & wel. Een string sluit je ook niet af met \"

[.oisyn]

Ja, duh, op & wel ja, maar die staat niet in de URL (misschien moet je de startpost en de eerste reactie daarop nog eens doorlezen, want dát is de context waarop ik reageer)

[ Voor 122% gewijzigd door .oisyn op 08-01-2010 16:43 ]

[wackmaniac]

Met Phas0r; waarom wil je dit soort tekens in je url hebben staan. Vervang alle niet alfanumerieke symbolen door een willekeurig symbol. Dan blijven het mooie url's, maar ontloop je dit probleem.

[pedorus]

quote: http://www.dracos.co.uk/code/apache-rewrite-problem/

False solutions

Banning odd characters

None of that sort of talk round here! ;-)

[Verwijderd]

wackmaniac schreef op vrijdag 08 januari 2010 @ 16:49:
Met Phas0r; waarom wil je dit soort tekens in je url hebben staan. Vervang alle niet alfanumerieke symbolen door een willekeurig symbol. Dan blijven het mooie url's, maar ontloop je dit probleem.

Mee eens. Mocht je nou toch nog die ampersand willen gebruiken, zorg er dan voor dat je de query string ook in de htaccess zelf weer encode. Want zoals je zelf al aangaf; de htaccess decodeert 'm als security feature!

[NMe]

pedorus schreef op vrijdag 08 januari 2010 @ 17:15:
[...]

Dus omdat <random website> zegt dat het slecht is is het slecht? Zo zonder onderbouwing is dat natuurlijk wel heel erg zwak van degene die dat geschreven heeft. Je wil dit soort urls rewriten om mooie urls over te houden. Als je dan vervolgens alsnog allerlei rare karakters erin gaat zetten die encoded moeten worden ga je gewoon aan je doel voorbij.

[Soultaker]

NMe schreef op vrijdag 08 januari 2010 @ 17:59:
Je wil dit soort urls rewriten om mooie urls over te houden.

Er zijn legio toepassingen van mod_rewrite die niets met mooie URLs te maken hebben, dus dit vind ik ook een onnauwkeurige generalisatie. Zelfs als je zo ver wil gaan om allerlei karakters in de ban te doen, is het stom dat als de URL Bagels%26Beans bevat, die stilzwijgend gemapt wordt naar een pagina over Bagels alleen.

Ik denk dat Shagura de juiste oplossing voor het probleem gegeven heeft. Omdat PHP de URL nog wil unescapen, moet Apache de backreferences gewoon weer escapen. Dat je in de praktijk waarschijnlijk geen geëscapete karakters in je korte URLs wil hebben doet daar niet aan af.

[pedorus]

Ik zou eigenlijk alleen even snel het linkje neerzetten, maar ik vond de quote grappiger. Ik had zelf eigenlijk nog geen mening over dit probleem. Ik denk nu dat de oplossing van Wikipedia wel mooi is. Daar hebben ze bijvoorbeeld:
Wikipedia: Vroom & Dreesmann
En ze negeren gewoon dat "&" vaak anders gebruikt wordt, en doen ook niet moeilijk met encoden. Of dat overal goed gaat werken, hangt natuurlijk van de website af. In ieder geval blijft de URL voor de gebruiker duidelijk, en daar gaat het om. Als je bijvoorbeeld "&" in "_" verandert krijg je iets als Vroom___Dreesmann, en dat is gewoon een stuk onduidelijker, die winkel ken ik namelijk niet...

[Saeverix]

Zoals iemand in een eerdere post zei: Vertaal je & teken naar gewone tekst.
Bagels&Beans > BagelsandBeans of BagelsenBeans.

Helemaal weglaten of vervangen door een underscore is natuurlijk ook een hele goede oplossing.

Je moet kijken naar het doel van je url's. Namelijk makkelijk te onthouden. Het beste is dan om totaal geen rare teken te gebruiken en voor alfanumerieke tekens te kiezen. Dat de bedrijfsnaam er dan niet in staat zoals het moet maakt niets uit. Die staat namelijk op de uiteindelijke website wel goed geschreven...

[HuHu]

Saeverix schreef op vrijdag 08 januari 2010 @ 18:26:
Zoals iemand in een eerdere post zei: Vertaal je & teken naar gewone tekst.
Bagels&Beans > BagelsandBeans of BagelsenBeans.

Helemaal weglaten of vervangen door een underscore is natuurlijk ook een hele goede oplossing.

Je moet kijken naar het doel van je url's. Namelijk makkelijk te onthouden. Het beste is dan om totaal geen rare teken te gebruiken en voor alfanumerieke tekens te kiezen. Dat de bedrijfsnaam er dan niet in staat zoals het moet maakt niets uit. Die staat namelijk op de uiteindelijke website wel goed geschreven...

Volgens mij gaat het in die URL om bedrijfsnamen. En die heb je niet voor het kiezen, die bestaan nu eenmaal gewoon. Dus een URL als http://example.com/info/Heineken moet hetzelfde werken als http://example.com/info/C&A, of de V&D, of de H&M, of weet ik veel wat. Alleen mag een & niet in de URL, maar moet je die schrijven als %26. En dan moet je gewoon kunnen verwachten dat PHP (of de rewrite) dat goed oppakt.

Ik neem aan dat die URLs ook gewoon automatisch gegenereerd worden en dan kun je er ook weinig aan doen dat van de vele duizenden bedrijven in Nederland er een paar met een & zijn in de naam.

[Saeverix]

HuHu schreef op vrijdag 08 januari 2010 @ 19:16:
[...]

Volgens mij gaat het in die URL om bedrijfsnamen. En die heb je niet voor het kiezen, die bestaan nu eenmaal gewoon. Dus een URL als http://example.com/info/Heineken moet hetzelfde werken als http://example.com/info/C&A, of de V&D, of de H&M, of weet ik veel wat. Alleen mag een & niet in de URL, maar moet je die schrijven als %26. En dan moet je gewoon kunnen verwachten dat PHP (of de rewrite) dat goed oppakt.

Ik neem aan dat die URLs ook gewoon automatisch gegenereerd worden en dan kun je er ook weinig aan doen dat van de vele duizenden bedrijven in Nederland er een paar met een & zijn in de naam.

Het staat gewoon vast dat je geen rare tekens in domeinnamen en dus alle achtervoegsels daarachter mag gebruiken.
Vraagtekens en "en" tekens worden gebruikt in de get functie van een servertaal. Bijvoorbeeld: index.php?id=1&color=2. Die zul je dus zelfs met een rewrite niet opnieuw moeten willen gebruiken.

Als je het op die manier toch doorzet en voor elkaar probeer te krijgen ontstaat er denk ik alleen maar meer verwarring in de toekomst.

Daarom is mijn mening: Hou het bij de 2 opties die hier een aantal keren uitgelegd zijn.

[Shagura]

Even voor de duidelijkheid. Dat Apache de url's decode is dus geen security feature wat ik me meende te herinneren. Zonder decoding zou Apache simpelweg de backreferences in de regexes niet kunnen onderscheiden van de url-entities.

Anyways, ampersands mogen voor zover ik weet wel gewoon in het path-gedeelte (alles voor de ?) van een url staan. Ik kan het niet echt vinden in de specificaties, maar er kan in theorie niks fout gaan of verkeerd geinterpreteerd worden dus waarom zou het fout zijn? Ik vind het sowieso een mooiere oplossing dan alles maar te replacen met 'and' oid.

[.oisyn]

HuHu schreef op vrijdag 08 januari 2010 @ 19:16:
Alleen mag een & niet in de URL

Wat natuurlijk onzin is, als een & niet in de URL mocht staan dan mag hij ook niet in de query string, want die is gewoon onderdeel van een URL. Een URL is niet alleen het gedeelte vóór de ?. Verder is het ook niet zo dat een & niet mag voorkomen in het path-gedeelte van de URL (dus het stuk na de http://domain.com/ en voor de ?)

[--MeAngry--]

Tjah, om dit soort redenen hebben vrijwel alle web frameworks wel een sluggify functie waarmee alle speciale tekens die je niet als tekst in je URL mag gebruiken om worden gezet naar bijvoorbeeld een underscore. Zie ook: Wikipedia: Slug (typesetting)

More recently this term is also used in web publishing to refer to short article labels that can be used as a part of an URL. Slugs are usually derived from article's title and are limited in length and the set of characters (to prevent percent-encoding, often only letters, numbers and hyphens are allowed).

Het is jammer, maar het niet veel anders. En persoonlijk vind ik een vast karakter in de plaats nog steeds duidelijk.

Wel typisch trouwens, ik kopieer de URL van Wikipedia waar gewoon (typesetting) in staat, en Firefox maakt er zelf %28typesetting%29 van als ik weer in een tekstveld plak.

[ Voor 21% gewijzigd door --MeAngry-- op 09-01-2010 17:32 ]

[wackmaniac]

Is niet zo typisch, Firefox is gewoon wat slimmer dan zeg IE. Bekijk in FF eens een willekeurige pagina van de Russische wikipedia en bekijk dezelfde pagina eens in IE en let dan vooral op de adres balk

[Verwijderd]

Wanneer stoppen we gewoon helemaal met die mod_rewrite onzin t.b.v. "mooie" url's?
Er zijn namelijk dagen dat ik niet in mijn browser balk ".../list_message/1388316/1" type om deze pagina te bezoeken. Niks mis met een "../list_message.html?id=1388316&page=1".

[wackmaniac]

Het gaat niet alleen om mooie url's, maar ook om SEO; je wordt beter geïndexeerd, ofzo

Daar komt bij; als je het eenmaal goed aanpakt is het geen issue meer

[ Voor 29% gewijzigd door wackmaniac op 10-01-2010 13:29 ]

[NMe]

Verwijderd schreef op zondag 10 januari 2010 @ 13:07:
Wanneer stoppen we gewoon helemaal met die mod_rewrite onzin t.b.v. "mooie" url's?
Er zijn namelijk dagen dat ik niet in mijn browser balk ".../list_message/1388316/1" type om deze pagina te bezoeken. Niks mis met een "../list_message.html?id=1388316&page=1".

offtopic:
Daar is wel wat mis mee. Als jij van de supportafdeling via de telefoon aan je klant duidelijk wil maken naar welke pagina op je website hij moet gaan of zelfs in een handleiding, dan is het wel zo praktisch als er geen gekke tekens in de url zitten. Dat zal met dit forum inderdaad niet snel gebeuren maar met iemands winkel of productpagina natuurlijk wel. En dan heb ik het nog niet eens over het aantal zoekmachines dat extra waarde hecht aan "mooie" urls en de woorden die daarin voorkomen...

[curry684]

Verwijderd schreef op zondag 10 januari 2010 @ 13:07:
Wanneer stoppen we gewoon helemaal met die mod_rewrite onzin t.b.v. "mooie" url's?
Er zijn namelijk dagen dat ik niet in mijn browser balk ".../list_message/1388316/1" type om deze pagina te bezoeken. Niks mis met een "../list_message.html?id=1388316&page=1".

Niemand die je tegenhoudt om op je eigen site lelijke URL's te blijven gebruiken terwijl de rest van ons wel met de tijd en de evoluerende wensen van z'n gebruikers mee gaat.

[Verwijderd]

wackmaniac schreef op zondag 10 januari 2010 @ 13:29:
Het gaat niet alleen om mooie url's, maar ook om SEO; je wordt beter geïndexeerd, ofzo

Er zit nauwelijks/geen verschil tussen ".../12345/mijn-titel-voor-seo" en ".../?id=12345&title=mijn-titel-voor-seo". En er zijn uiteraard situaties waarin het herschrijven van url's wel wenselijk is. Echter is het argument "mooi" puur subjectief en zodoende niets toevoegend.

NMe haalt daarbij een juist argument aan, waarbij ook hij er vanuit gaat dat je deze url wel gaat typen. Een ander argument wat voor het herschrijven preekt is bijvoorbeeld het fatsoenlijk kunnen opslaan van het document ("/onderwerp/123/mijn-titel.html" vs "/onderwerp.html?id=123&titel=mijn-titel"). Hier op tweakers heeft het niet zoveel toegevoegde waarde.

Strekking: zorg dat het herschrijven daadwerkelijk iets toevoegt i.p.v. centjes verbranden voor je klanten en en introductie van nieuwe logica waar simpelweg weer bugs in kunnen optreden.

[MueR]

Verwijderd schreef op zondag 10 januari 2010 @ 14:18:
Strekking: zorg dat het herschrijven daadwerkelijk iets toevoegt i.p.v. centjes verbranden voor je klanten en en introductie van nieuwe logica waar simpelweg weer bugs in kunnen optreden.

Dat doe je dus door niet-valide characters netjes te vervangen. Zie de frontpage: nieuws: 'Volgende project Infinity Ward niet Modern Warfare 3'. De quotes zijn geen valide karakters in een URL. Dan kan je gaan kloten met encoding, of je haalt ze er gewoon uit. Mag jij gokken welke van de twee het meeste tijd en geld kost.

[wackmaniac]

Heeft wel degelijk met SEO van doen:

A URL like http://www.example.com/4/basic.html can be indexed much easier, whereas its dynamic form, http://www.example.com/cgi-bin/gen.pl?id=4&view=basic, can actually confuse the search engines and cause them to miss possibly important information contained in the URL, and thus preventing you from getting the expected ranking.

bron: http://www.avangate.com/articles/url-rewriting_70.htm

Is ook wel logisch dat zoekmachines hier wat terughoudend mee omgaan; als je elke pagina, dus met elke combinatie van querystrings, gaat indexeren, dan krijg je voor sorteringen dat de pagina x keer wordt geïndexeerd. Dan moet je dat weer af gaan vangen met canonical url's etc.

Toevoeging aan de post van MueR; als je nu een keer een slug-functie maakt (is nog geen uurtje werk), dan kan je dat voor elk project hergebruiken

[ Voor 9% gewijzigd door wackmaniac op 10-01-2010 14:31 . Reden: toevoeging ]

[Verwijderd]

MueR schreef op zondag 10 januari 2010 @ 14:24:
Dat doe je dus door niet-valide characters netjes te vervangen.

Ja, dat zou ik ook doen.

wackmaniac schreef op zondag 10 januari 2010 @ 14:28:
Heeft wel degelijk met SEO van doen:
bron: http://www.avangate.com/articles/url-rewriting_70.htm

Ik denk dat in dit geval een document uit 2007 anno 2010 niet zo gek veel waarde meer heeft
Onze vrienden van google veranderen toch wel met enige regelmaat de ranking logica. De trend op dit moment is toch dat voornamelijk de inhoud de meest waarde heeft (en natuurlijk nog wat andere factoren). Alle beetjes helpen natuurlijk wel.

[ Voor 58% gewijzigd door Verwijderd op 10-01-2010 14:36 ]

[MueR]

Verwijderd schreef op zondag 10 januari 2010 @ 14:29:
Ja, dat zou ik ook doen.

Je zegt net dat je het hele mod_rewrite gebeuren maar onzin vind, maar je gebruikt het wel? Wat is nu dan eigenlijk je punt?

[Verwijderd]

MueR schreef op zondag 10 januari 2010 @ 16:14:
Je zegt net dat je het hele mod_rewrite gebeuren maar onzin vind, maar je gebruikt het wel? Wat is nu dan eigenlijk je punt?

Let op de nuance: Ik zeg dat het ik onzin vind om puur "mooie" url's als doel te stellen. Het ontbreekt nog wel eens de juiste argumenten hier op GoT om technieken toe te passen. In sommige gevallen heeft het anders opschrijven van de url voordelen, ik zou heel naïef zijn als ik dat niet inzie. Echter soms voegt herschrijven niets toe, dit forum is daar een levendig voorbeeld van.

Ik denk dat het goed is om ook vaker stil te staan bij de kosten en baten van het toepassen van techniek of methodiek. Het voordeel van herschreven urls op dit forum is marginaal, terwijl er toch een ontwikkelaar aan de slag is geweest om het te implementeren. Dat betekent tevens code waar ook fouten in op kan treden.

[curry684]

Verwijderd schreef op zondag 10 januari 2010 @ 14:29:
Ik denk dat in dit geval een document uit 2007 anno 2010 niet zo gek veel waarde meer heeft
Onze vrienden van google veranderen toch wel met enige regelmaat de ranking logica. De trend op dit moment is toch dat voornamelijk de inhoud de meest waarde heeft (en natuurlijk nog wat andere factoren). Alle beetjes helpen natuurlijk wel.

Bullshit, het hele web is erop ingericht om relatief weinig waarde te hechten aan GET-parameters, juist omdat ze bedoeld zijn voor repeatable en quotables actions zoals searches, denk aan /search.php?q=pizza, waar Google zelf ook stijf van staat als zoekmachine. Dat is waar GET-parameters voor bedoeld zijn en hoe ze geindexeerd woorden, als parameters voor een pagina. Op basis van die logica is het in principe terecht om te stellen dat een site die enkel werkt met 1 pagina en parametrized URL's (voorbeeldje) maar 1 pagina heeft en daarop veel input-afhankelijke variaties.

Wat jij even niet wil snappen is dat URL's wel degelijk bedoeld zijn om human-readable te zijn. De gemiddelde gebruiker stelt het extreem op prijs dat ie in z'n mail/IRC/MSN/whatever URL's aantreft als http://tweakers.net/nieuws/64839/bioshock-ontwikkelaar-2k-boston-wordt-weer-irrational-games.html en niet zoiets als http://tweakers.net/index.php?type=nieuws&id=64839. Niet alleen is de 2e veel minder verbose, hij draagt ook niet duidelijk uit dat het een unieke pagina is, en hij is niet 'hackable', want van de eerste mag je stukjes afhakken tot bijv. http://tweakers.net/nieuws, om een logisch overzicht te krijgen van al het nieuws. Hackability is ook een belangrijke reden voor URL-rewriting.

Ik weet ook wel dat je koppig bent en graag je eigen mening als wet verkondigd, maar kom op, in deze heb je opponenten als Jakob Nielsen tegenover je:

quote: http://www.useit.com/alertbox/990321.html

Edward Cutrell and Zhiwei Guan from Microsoft Research have conducted an eyetracking study of search engine use (warning: PDF) that found that people spend 24% of their gaze time looking at the URLs in the search results.

MSR used Microsoft's own search engine (fair enough), but their results match what we found in our eyetracking research which included the current market leader as well as the #2 search engine in addition to MSN.

Users have evolved a firm model of search behavior which they apply across search engines, which is why it's probably a lost cause to make a non-standard search user interface.

We found that searchers are particularly interested in the URL when they are assessing the credibility of a destination. If the URL looks like garbage, people are less likely to click on that search hit. On the other hand, if the URL looks like the page will address the user's question, they are more likely to click.

Maar dit is helaas ook een addendum uit 2007 op een tekst die reeds sinds 1999 als 'bijbel' beschouwd wordt, dus vast verouderd...

[Verwijderd]

curry684 schreef op zondag 10 januari 2010 @ 18:26:
Wat jij even niet wil snappen is dat URL's wel degelijk bedoeld zijn om human-readable te zijn. De gemiddelde gebruiker stelt het extreem op prijs dat ie in z'n mail/IRC/MSN/whatever URL's aantreft als http://tweakers.net/nieuws/64839/bioshock-ontwikkelaar-2k-boston-wordt-weer-irrational-games.html en niet zoiets als http://tweakers.net/index.php?type=nieuws&id=64839.

Zo gaan we langs elkaar heen praten. Zeker in jouw voorbeeld heeft uiteraard de url waarin de titel zit verwerkt mijn/de voorkeur. Echter is dat niet de vergelijking die ik gemaakt heb, want dat is namelijk:
../list_messages/123456/1
versus
../list_messages?id=123456&page=1
Verhelderd dat de zaak?

[NMe]

Verwijderd schreef op zondag 10 januari 2010 @ 19:06:
[...]
Zo gaan we langs elkaar heen praten. Zeker in jouw voorbeeld heeft uiteraard de url waarin de titel zit verwerkt mijn/de voorkeur. Echter is dat niet de vergelijking die ik gemaakt heb, want dat is namelijk:
../list_messages/123456/1
versus
../list_messages?id=123456&page=1
Verhelderd dat de zaak?

En jij ging er in je eerste reply hier maar meteen vanuit dat de topicstarter het in een context wil doen die slecht is. Vind je het gek dat mensen je daarop afrekenen?

[curry684]

Verwijderd schreef op zondag 10 januari 2010 @ 19:06:
[...]
Zo gaan we langs elkaar heen praten. Zeker in jouw voorbeeld heeft uiteraard de url waarin de titel zit verwerkt mijn/de voorkeur. Echter is dat niet de vergelijking die ik gemaakt heb, want dat is namelijk:
../list_messages/123456/1
versus
../list_messages?id=123456&page=1
Verhelderd dat de zaak?

1. Is het opvragen van een forumtopic een repeatable form entry of een permalink binnen een dynamische site?
2. Is het voor een forum belangrijk dat mensen de URL aantrekkelijk en leesbaar achten indien de topics binnen een zoekmachine gevonden worden?

[The Van]

Ampersands horen NIET in url's thuis. Bron:
RFC 1738: Uniform Resource Locators (URL) specification The specification for URLs (RFC 1738, Dec. '94) poses a problem, in that it limits the use of allowed characters in URLs to only a limited subset of the US-ASCII character set:
"...Only alphanumerics [0-9a-zA-Z], the special characters "$-_.+!*'()," [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL."
Let op: er is een groot verschil tussen url's en html coding! HTML staat veel meer toe.

Daarnaast is er voor HTTP verkeer een uitzondering:"The characters ";", "/", "?", ":", "@", "=" and "&" are the characters which may be reserved for special meaning within a scheme." (Emphasis on my side). En als je nu goed verder leest, vind je in het HTTP scheme: "Within the <path> and <searchpart> components, "/", ";", "?" are reserved." Geen woord over de ampersand...

[ Voor 23% gewijzigd door The Van op 11-01-2010 13:33 ]

[Janoz]

Daar staat alleen dat ze gereserveerd zijn voor speciale betekenis. Niet dat ze verboden zijn in een url.

mbt de andere discussie kan ik wel redelijk met mark meegaan. Voor een forum topic zou ik trouwens wel de thread id in de url zelf opnemen en het pagina nummer wel als get parameter.

Dat is eigenlijk meer ingegeven door de URL's die ik in google analytics terug vindt. Naar mijn site wordt vaak vanuit fora gelinkt, maar de topics kan ik nooit handig terug vinden. Wanneer er niks gerewrite wordt zie ik alleen de forum url met gettopic.php achtig iets aan het einde. In het geval van tweakers krijg ik wel een URL, maar komt hetzelfde topic meerdere keren voor omdat verschillende mensen verschillende posts per pagina hebben waardoor de url waar het bericht op staat telkens anders is (ander pagina nummer in de url).

[curry684]

Feitelijk kun je daar stellen dat Fok dat beter doet omdat die wel de ppp in de URL meenemen waardoor het een echte permalink wordt

Ik ben het inderdaad met je eens dat de topicId onderdeel is van de 'permalink' en de pagenr een get-parameter zou moeten zijn zoals alle repeatable but transient input.

[The Van]

Janoz schreef op maandag 11 januari 2010 @ 13:52:
Daar staat alleen dat ze gereserveerd zijn voor speciale betekenis. Niet dat ze verboden zijn in een url.

In het algemeen zijn ze dus niet toegestaan in een url. De rfc zegt uitdrukkelijk:

Thus, only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL.

Voor het http-scheme is er de volgende uitzondering:

The HTTP protocol is specified elsewhere. This specification only describes the syntax of HTTP URLs. An HTTP URL takes the form: http://<host>:<port>/<path>?<searchpart> where <host> and <port> are as described in Section 3.1. If :<port> is omitted, the port defaults to 80. No user name or password is allowed. <path> is an HTTP selector, and <searchpart> is a query string. The <path> is optional, as is the <searchpart> and its preceding "?". If neither <path> nor <searchpart> is present, the "/" may also be omitted. Within the <path> and <searchpart> components, "/", ";", "?" are reserved. The "/" character may be used within HTTP to designate a hierarchical structure.

Aangezien de ampersand hier niet bij staat, dient de ampersand te worden uitgecodeerd in een http-url.

NB: Een url is wel even iets breder dan een hyperlink... Kent iemand gopher nog?

[Janoz]

Sorry, maar http://domein.ext/hoi?aap=noot&mies=ook is een keurige valide url, ondanks dat er een vraagteken en twee een ampersand tekens in voorkomen.

[ Voor 5% gewijzigd door Janoz op 11-01-2010 15:49 ]

[Herko_ter_Horst]

Janoz schreef op maandag 11 januari 2010 @ 15:24:
Sorry, maar http://domein.ext/hoi?aap=noot&mies=ook is een keurige valide url, ondanks dat er een vraagteken en twee ampersand tekens in voorkomen.

Dan gebruik je de ampersand blijkbaar als delimiter tussen query parameters. Dat mag inderdaad. Maar dat is niet wat de TS wil, dus moet hij de ampersand encoden. Dat je & uberhaupt unencoded als delimiter mag gebruiken is overigens niet triviaal afleidbaar uit de diversie specs...

Volgens de meest recente spec (RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax) is & een reserved character dat geencode moet worden, TENZIJ de schema-specific URI definitie hem expliciet als delimiter vermeldt. De HTTP 1.1 spec doet dit echter NIET. Dit zou betekenen dat & altijd geencode moet worden. Echter, de HTML 4.01 spec zegt dat & en = delimiters zijn als de www-form-encoding gebruikt wordt (dit is ook de default). Dit betekent dat & niet geencode hoeft te worden MITS deze als delimiter wordt gebruikt, anders dus wel.

PS ik zie geen tweede ampersand

[ Voor 95% gewijzigd door Herko_ter_Horst op 11-01-2010 16:30 ]

[.oisyn]

The Van schreef op maandag 11 januari 2010 @ 13:25:
En als je nu goed verder leest, vind je in het HTTP scheme: "Within the <path> and <searchpart> components, "/", ";", "?" are reserved." Geen woord over de ampersand...

De / is ook reserved, ga je nu glashard beweren dat je die óók niet mag gebruien in een URL?

Herko_ter_Horst schreef op maandag 11 januari 2010 @ 15:32:
[...]

Dan gebruik je de ampersand blijkbaar als delimiter tussen query parameters. Dat mag inderdaad.

Volgens wie mag dat? En omgekeerd:

Maar dat is niet wat de TS wil, dus moet hij de ampersand encoden.

Waaruit blijkt dat dat moet? Die "dus" in je zin klopt niet. Je vorige statement gaat over wanneer het mag, niet over wanneer het niet mag.

Echter, de HTML 4.01 spec zegt dat & en = delimiters zijn als de www-form-encoding gebruikt wordt (dit is ook de default). Dit betekent dat & niet geencode hoeft te worden MITS deze als delimiter wordt gebruikt, anders dus wel.

Dat gaat echter over form data, wat in de query string terecht komt, dus ná de ?. Voor de ? heeft de & geen betekenis.

Het is imho prima verantwoord om een scheme op te zetten zoals wikipedia dat doet. / en & zijn gewoon geldige tekens in een URL, zeker in het path gedeelte van een URL, en daar kunnen ze dus ook voor gebruikt worden.

[ Voor 13% gewijzigd door .oisyn op 12-01-2010 11:02 ]

[Janoz]

Alleen de ? en de / hebben ook voor de browser een belangrijkere betekenis. De ? geeft aan waar het pad eindigt en de / geeft aan hoe dit pad opgedeeld is. Voor de browser is dat van belang om te bepalen hoe relatieve url's omgezet moeten worden naar absolute url's. De ; heeft eenzelfde soort functie als de ?. Vandaar dat die 3 juist wel expliciet genoemd worden.

[hobbeldebobbel]

Ik heb het nu dubbel werkend zeg maar.

Als de link vanuit mijn database komt dan gebruik ik gewoon de urlencoded versie: %26. Daarnaast kan iemand ook www.url.nl/v&d in typen. Wat ook zal mappen naar de goede pagina. klik hij daarna bijvoorbeeld op meer info, dan zal de url de v%26d bevatten.

Heb dus nu de redirect gewoon zonder argumenten gedaan in de .htaccess; om vervolgens in de php te kijken naar de request uri. Werkt perfect! Al dan niet "legaal"....

[The Van]

Het hele verhaal gaat dus over het gebruik van een functie, die zich keurig aan de standaard houdt, en de ampersand vertaalt. Dat dit door de ontwikkelaar als ongewenst gezien wordt: pech.
De generieke oplossing is om dit soort functies twee keer aan te roepen: een keer de decode, en een keer de encode.

www -> database: decode. ("&" wordt %26)
database -> www: encode. (%26 wordt weer "&")

Overigens is een URI niet hetzelfde als een URL, en heeft de HTML standaard hier helemaal niks mee te maken, want het is geen HTML.

[.oisyn]

The Van schreef op dinsdag 19 januari 2010 @ 14:09:
Het hele verhaal gaat dus over het gebruik van een functie, die zich keurig aan de standaard houdt, en de ampersand vertaalt. Dat dit door de ontwikkelaar als ongewenst gezien wordt: pech.

Onzin, daar is niets "pech" aan, daar kun je gewoon omheen werken. Bovendien is er geen standaard die zegt dat de & voor de ? vertaald moet worden.

[Shagura]

The Van schreef op dinsdag 19 januari 2010 @ 14:09:
Het hele verhaal gaat dus over het gebruik van een functie, die zich keurig aan de standaard houdt, en de ampersand vertaalt. Dat dit door de ontwikkelaar als ongewenst gezien wordt: pech.
De generieke oplossing is om dit soort functies twee keer aan te roepen: een keer de decode, en een keer de encode.

www -> database: decode. ("&" wordt %26)
database -> www: encode. (%26 wordt weer "&")

Ik weet niet precies welke functie je bedoelt, maar ik neem aan dat het over mod_rewrite gaat. Ik vraag me eerlijk gezegd af of deze zich wel zo goed aan de standaard houdt. Uit de RFC:

http://www.ietf.org/rfc/rfc3986.txt
When a URI is dereferenced, the components and subcomponents
significant to the scheme-specific dereferencing process (if any)
must be parsed and separated before the percent-encoded octets within
those components can be safely decoded, as otherwise the data may be
mistaken for component delimiters.

En het is maar de vraag of dat wel gebeurt. Uiteindelijk kan de werking van je script op een bepaalde url afhangen van het wel of niet gebruiken van een mod_rewrite (moet je nou encoded of unencoded url's verwachten van apache?). Dat vind ik eerlijk gezegd nogal vaag, of het nou in lijn met een of andere standaard is of niet. Maar zoveel maakt het nou ook weer niet uit. Het is duidelijk gedocumenteerd, goed mee te werken en ik snap waarom het nodig is (al hadden ze ook misschien juist % niet voor backreferences hoeven te gebruiken).

Het enige wat uiteindelijk eigenlijk echt boeiend is, is dat mensen gewoon in de gaten moeten houden wat speciale karakters zijn in welke context en deze zo nodig encoden/herschrijven zodat deze altijd eenduidig geïnterpreteerd kunnen worden. Een & in een path gedeelte zou gewoon niet als delimiter geïnterpreteerd kunnen worden, dus strict genomen hoef je deze dan ook niet te encoden (Ik heb geen zin om dit op te zoeken in de spec, maar ik neem aan dat dit klopt).

Overigens is een URI niet hetzelfde als een URL, en heeft de HTML standaard hier helemaal niks mee te maken, want het is geen HTML.

Een URL is gewoon een URI. Ze zijn vaak uitwisselbaar in het gebruik en meestal is het wel duidelijk wat er bedoeld wordt (en/of is het verschil niet boeiend, voor zover er verschil is).

Wikipedia: Uniform Resource Identifier
Technical publications, especially standards produced by the IETF and by the W3C, normally no longer use the term URL, as the need to distinguish between URLs and URIs rarely arises.

[ Voor 9% gewijzigd door Shagura op 19-01-2010 15:26 ]