[asp.net] ñ é ç è Vreemde tekens is querystring

donderdag 9 juni 2011 22:45

Acties:

0 Henk 'm!

Hmm...

Topicstarter

Als ik een request.querystring opvraag met bijvoorbeeld 'Jalapeño' als querystring, dan krijg ik 'Jalape�o' als resultaat.

Ik heb al urlencode/decode geprobeerd, en <globalization requestEncoding="iso-8859-1" responseEncoding="iso-8859-1" /> in mijn web.config, maar dat gaf niet het gewenste resultaat.

Dat laatste werkte wel in combinatie met 'COLLATE SQL_Latin1_General_Cp850_CI_AI' in mijn SQL, de juiste data werd gevonden in de database, maar nog steeds krijg ik 'Jalape�o' als ik de string in bijvoorbeeld een label plaats, of textbox.

Ik wil dus dat mijn website 'Jalapeño' laat zien, en dat de database de juiste data kan vinden...

Met Google kom ik niet verder omdat ik niet de juiste zoektermen kan verzinnen in het engels...

edit:

Het gaat om de volgende website zodat je gelijk kan zien wat ik bedoel:

*snip*

[ Voor 14% gewijzigd door RobIII op 09-06-2011 23:18 ]

donderdag 9 juni 2011 22:54

Acties:

0 Henk 'm!

Voutloos

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Van elke string op elk punt (dus ook in de rest van je code, labels etc) moet jij weten wat de encoding is, anders ben je maar op de gok bytes aan het rondschuiven.

{signature}

donderdag 9 juni 2011 23:20

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

^ Wat hij zegt.
Kijk ook eens hier en hier.

Verder: als je linkjes plaatst, plaats dan links naar een testcase. Links naar volledige sites zijn ongewenst en, hoewel onbedoeld, kunnen als spam opgevat worden.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

donderdag 9 juni 2011 23:21

Acties:

0 Henk 'm!

Swerfer

Hmm...

Topicstarter

Voutloos schreef op donderdag 09 juni 2011 @ 22:54:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Van elke string op elk punt (dus ook in de rest van je code, labels etc) moet jij weten wat de encoding is, anders ben je maar op de gok bytes aan het rondschuiven.

Hiermee kom ik er nog niet uit.

Wat mij wel opvalt is het verschil in browsers. Firefox geeft het ook niet goed weer, maar Chrome wel...

Chrome herkend blijkbaar de juiste Character set, maar welke?

Ik heb utf-8, utf-16, ascii en iso-8859-1 geprobeerd, maar niks gaf het gewenste resultaat. Met andere woorden: Ik ben aan het gokken...

donderdag 9 juni 2011 23:24

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Swerfer schreef op donderdag 09 juni 2011 @ 23:21:
Met andere woorden: Ik ben aan het gokken...

Dan heb je 't artikel dat Voutloos aanhaalt of niet gelezen, of niet begrepen. Gokken door er maar een willekeurige charset tegenaan te smijten heeft geen nut; zeker niet als de data met encoding A in de DB gemikkerd is en daarna met encoding B weergegeven wordt.

Als je wil zien welke encoding een browser (uiteindelijk) besloten heeft te gebruiken klik je (voor chrome) op 't sleuteltje -> tools -> encoding -> encoding met het bolletje ervoor en voor Firefox: view -> character encoding -> encoding met 't bolletje ervoor.

Hint: je site geeft tegenstrijdige info:

HTTP headers:
Content-Type: text/html; charset=windows-1251
HTML:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Hou er rekening mee dat je dus in een "traject" te maken hebt met Voutloos' aangehaalde artikel op (maar niet uitsluitend) o.a. de volgende plaatsen:
gebruikte encoding bij posten van data (HTML + HTTP Headers)
gebruikte encoding van, en bij opslaan in/ophalen uit de DB
gebruikte encoding bij weergeven van data (HTML + HTTP Headers)

[ Voor 49% gewijzigd door RobIII op 09-06-2011 23:37 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

donderdag 9 juni 2011 23:43

Acties:

0 Henk 'm!

Swerfer

Hmm...

Topicstarter

Chrome en FireFox geven beide aan utf-8 te gebruiken, maar die geven beide andere resultaten.

Die tegenstrijdige charsets was waarschijnlijk een momentopname. Dat was een foutje tijdens het testen.

Heel basic:

http://chilibase.nl/test.aspx?test=Jalapeño

ASP.NET:

1
2
3

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
    Response.Write(Request.QueryString("test"))
End Sub

donderdag 9 juni 2011 23:55

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Swerfer schreef op donderdag 09 juni 2011 @ 23:43:
Heel basic:

Heel basic:

HTML:

Jalape&#65533;o

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><title>

</title></head>
<body>
    <form name="form1" method="post" action="test.aspx?test=Jalape%ufffdo" id="form1">
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKLTEzNDM3NzkxOWRkon3yP/8IJ2NaFI28nO0zejd8ghaY1v7rDWY9I6k6v7s=" />
</div>

    <div>
    
    </div>

    </form>
</body>
</html>

Waarom staat de output nog voor de doctype in-the-first-place

Swerfer schreef op donderdag 09 juni 2011 @ 23:43:
Die tegenstrijdige charsets was waarschijnlijk een momentopname. Dat was een foutje tijdens het testen.

Dat zal best, maar net werkte 't wél in Chrome en nu niet meer

*HINT*

[ Voor 14% gewijzigd door RobIII op 10-06-2011 00:37 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

vrijdag 10 juni 2011 00:53

Acties:

0 Henk 'm!

Avalaxy

Swerfer schreef op donderdag 09 juni 2011 @ 23:21:
[...]

Hiermee kom ik er nog niet uit.

Wat mij wel opvalt is het verschil in browsers. Firefox geeft het ook niet goed weer, maar Chrome wel...

Chrome herkend blijkbaar de juiste Character set, maar welke?

Ik heb utf-8, utf-16, ascii en iso-8859-1 geprobeerd, maar niks gaf het gewenste resultaat. Met andere woorden: Ik ben aan het gokken...

Zorg dat je alles in hebt gesteld op UTF-8. Je databasetabellen, je databaseverbinding, je webpagina's.

vrijdag 10 juni 2011 18:51

Acties:

0 Henk 'm!

Swerfer

Hmm...

Topicstarter

RobIII schreef op donderdag 09 juni 2011 @ 23:55:
Waarom staat de output nog voor de doctype in-the-first-place

Dat komt door de Response.Write

Heb ik veranderd door de Querystring direct in een label te plaatsen:

ASP.NET:

Partial Class test
    Inherits System.Web.UI.Page

    Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        label1.text = Request.QueryString("test")
    End Sub

End Class

Blijft het probleem dat de Querystring niet goed in het label word gezet. Ook niet door utf-8 als contenttype te kiezen...

De Database is overigens geen probleem...

vrijdag 10 juni 2011 19:27

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Hier al eens gekeken

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

vrijdag 10 juni 2011 20:03

Acties:

0 Henk 'm!

Swerfer

Hmm...

Topicstarter

RobIII schreef op vrijdag 10 juni 2011 @ 19:27:
Hier al eens gekeken

Ook dat heb ik al (eerder) geprobeerd.

Alleen Chrome lijkt de juiste encoding te gebruiken...

edit:

Dit zie ik in mijn IIS log bij GET van IE9:

2011-06-10 18:03:27 10.0.0.2 GET /test.aspx test=Jalapeño

En dit bij Chrome:

2011-06-10 18:03:30 10.0.0.2 GET /test.aspx test=Jalape%C3%B1o

Dus Chrome stuurt een url-encoded querystring, en IE9 niet... Daar ligt dus het verschil...

[ Voor 35% gewijzigd door Swerfer op 10-06-2011 20:08 ]

vrijdag 10 juni 2011 20:17

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Swerfer schreef op vrijdag 10 juni 2011 @ 20:03:
Dus Chrome stuurt een url-encoded querystring, en IE9 niet... Daar ligt dus het verschil...

Waar komt IE9 nou opeens vandaan? Tot deze post heb je die nergens genoemd

En wat doet Firefox nu dan?

[ Voor 4% gewijzigd door RobIII op 10-06-2011 20:17 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

vrijdag 10 juni 2011 20:20

Acties:

0 Henk 'm!

Swerfer

Hmm...

Topicstarter

Ik heb meerdere Browsers geprobeerd, IE9 is nu mijn standaard, maar ook IE8 en FireFox 4 geeft problemen.

zaterdag 11 juni 2011 11:28

Acties:

0 Henk 'm!

Swerfer

Hmm...

Topicstarter

Het probleem ligt bij de manier hoe de verschillende Browsers omgaan met vreemde tekens. Zie onderstaande thread:

Manually entering special (unicode/international/extended) characters in the URL bar (as QueryString parameter)

Ook hier hebben ze geen oplossing gevonden...

zaterdag 11 juni 2011 11:46

Acties:

0 Henk 'm!

sonix666

Hoi Swerfer,

die URL parameters. Moeten die vrij ingevuld kunnen worden of worden die bijvoorbeeld gegenereerd door je applicatie zelf. Het lijkt er inderdaad op dat iedere browser net iets anders omgaat met het encoden van rare tekens in de URL. En dat is denk ik ook niet raar, omdat die rare tekens volgens mij niet eens toegestaan zijn in de HTTP specificatie.

Als je applicatie de URL parameters zelf genereert, dan is het behoorlijk simpel om ze netjes te URL encoden door middel van onder andere HttpUtility.UrlEncode (per parameter waarde doen, niet de gehele string encoden).

zaterdag 11 juni 2011 12:17

Acties:

0 Henk 'm!

Voutloos

Je blijft gokken wat het probleem is, en zoekt bovendien niet uit of de bits uberhaupt overeenkomen met je verwacht. Tijdens het debuggen is het dan wel handig om bijvoorbeeld
http://www.fileformat.info/info/unicode/char/f1/index.htm erbij te pakken.

Dan had je kunnen weten dat ñ in UTF 8 hex notatie 0xC3 0xB1 (c3b1) is, en had je zelf de volgende url in elkaar kunnen zetten:
http://chilibase.nl/test.aspx?test=Jalape%C3%B1o

Met je huidige testcode geeft dit het karakter goed weer (let op: dit betekent niet per se dat je alles goed doet), dus nu heb je een resultaat om op door te bouwen. Klopt het nu hoe je de url interpreteert, hoe kwam je aan de %F1, wat zegt de RFC over querystrings, etc. etc.?

edit:
^ Komt mogelijk ietwat streng over, maar bevat imo wel heel wat leerzame hints.

[ Voor 10% gewijzigd door Voutloos op 11-06-2011 12:19 ]

{signature}

zaterdag 11 juni 2011 12:18

Acties:

0 Henk 'm!

Swerfer

Hmm...

Topicstarter

sonix666 schreef op zaterdag 11 juni 2011 @ 11:46:
Hoi Swerfer,

die URL parameters. Moeten die vrij ingevuld kunnen worden of worden die bijvoorbeeld gegenereerd door je applicatie zelf. Het lijkt er inderdaad op dat iedere browser net iets anders omgaat met het encoden van rare tekens in de URL. En dat is denk ik ook niet raar, omdat die rare tekens volgens mij niet eens toegestaan zijn in de HTTP specificatie.

Als je applicatie de URL parameters zelf genereert, dan is het behoorlijk simpel om ze netjes te URL encoden door middel van onder andere HttpUtility.UrlEncode (per parameter waarde doen, niet de gehele string encoden).

Als iemand rechtstreeks op mijn website via de adresbalk de querystring aanpast, door bijvoorbeeld vanuit Wikipedia het woord Jalapeño te kopieren en te plakken, dan gaat het dus fout.

Dit is namelijk één keer voorgekomen en ik zag aan mijn log dat er een fout was ontstaan. Ik genereer namelijk bij een onbekende naam in de querystring een 404 error en stuur dan de client door naar de homepage zodat zoekmachines evt verkeerde links niet gaat gebruiken. Nou is Jalapeño geen verkeerde naam, dus wil ik dat mijn website daar goed mee omgaat.

Het zal niet veel voorkomen dat iemand een 'vreemde' naam intikt of kopieërt/plakt (waarschijnlijk bijna nooit), maar ik houd graag van perfectie wat dat betreft.

Voutloos schreef op zaterdag 11 juni 2011 @ 12:17:
Je blijft gokken wat het probleem is, en zoekt bovendien niet uit of de bits uberhaupt overeenkomen met je verwacht. Tijdens het debuggen is het dan wel handig om bijvoorbeeld
http://www.fileformat.info/info/unicode/char/f1/index.htm erbij te pakken.

Dan had je kunnen weten dat ñ in UTF 8 hex notatie 0xC3 0xB1 (c3b1) is, en had je zelf de volgende url in elkaar kunnen zetten:
....

Met je huidige testcode geeft dit het karakter goed weer (let op: dit betekent niet per se dat je alles goed doet), dus nu heb je een resultaat om op door te bouwen. Klopt het nu hoe je de url interpreteert, hoe kwam je aan de %F1, wat zegt de RFC over querystrings, etc. etc.?

Het gaat dus niet om hoe ik de url genereer, maar als een gebruiker het rechtstreeks intikt in de adresbalk...

[ Voor 25% gewijzigd door Swerfer op 22-01-2012 09:29 ]

zaterdag 11 juni 2011 12:22

Acties:

0 Henk 'm!

Voutloos

OK, dus hoe weet je hoe je de querystring moet interpreteren? Ik wil gewoon dat je daar over nadenkt. Nu pak je het direct als parameter aan en stuurt het terug met een UTF-8 headertje, maar er gebeurt gewoon zoveel meer dan dat. Zoek het hoe en waarom uit en leer ervan.

{signature}

zaterdag 11 juni 2011 13:42

Acties:

0 Henk 'm!

sonix666

Swerfer schreef op zaterdag 11 juni 2011 @ 12:18:
[...]

Als iemand rechtstreeks op mijn website via de adresbalk de querystring aanpast, door bijvoorbeeld vanuit Wikipedia het woord Jalapeño te kopieren en te plakken, dan gaat het dus fout.

Dit is namelijk één keer voorgekomen en ik zag aan mijn log dat er een fout was ontstaan. Ik genereer namelijk bij een onbekende naam in de querystring een 404 error en stuur dan de client door naar de homepage zodat zoekmachines evt verkeerde links niet gaat gebruiken. Nou is Jalapeño geen verkeerde naam, dus wil ik dat mijn website daar goed mee omgaat.

Het zal niet veel voorkomen dat iemand een 'vreemde' naam intikt of kopieërt/plakt (waarschijnlijk bijna nooit), maar ik houd graag van perfectie wat dat betreft.

[...]

Het gaat dus niet om hoe ik de url genereer, maar als een gebruiker het rechtstreeks intikt in de adresbalk...

Wat ik al zei, dat kan gewoon niet. Kijk eens op de volgende URL:

Wikipedia: Percent-encoding

Daar staat heel duidelijk dat ALLE karakters buiten de unreserved character set percent encoded moeten worden. Dus mensen die dat rare karakter intypen in een URL zijn fout bezig. Dan mag je blij zijn dat sommige browsers dat blijkbaar percent encoden via de UTF-8 standaar, zoals daar ook aangegeven wordt.

In het kort, wat jij wilt, kan gewoon niet.

Onderwerpen