[bug] Probleem met characterset?

[AW_Bos]

Als ik hier kijk:
RFID-lezer kopen in benelux/eu

Ik hoop dat jullie mss ideÃ�«n hebben en mij verder op weg zouden willen/kunnen helpen met het aanschaffen van een RFID-lezer.

Dit lijkt me niet helemaal te kloppen? Foutje bij de character-set van GoT, of is dit weer het probleem dat iemand iets vanuit Word zit te copy-pasten, wat problemen zou opleveren?

Bug of NaB ? ?

[DexterDee]

Dat lijkt me gewoon een ordinaire copy/paste fout van de user zelf.

Even een testje:
Hier heb ik Chinees in het chinees geschreven: 中文
En Japans in het japans: 日本語
Bedankt voor die bloemen in het russisch: Спасибо за цветы
Ideeen met een umlaut: ideeën

Hmmm, alhoewel Tweakers slechts ISO-8859-15 encoding ondersteunt, worden alle niet-westerse karakters omgezet in Unicode HTML entities. Ik weet niet zeker of Firefox dat nu doet bij de formsubmit of dat het serverside gebeurt. Hoe dan ook, ik snap niet goed waarom Tweakers als techsite niet standaard voor UTF-8 kiest. Dan hoeft er nooit een conversie plaats te vinden omdat alle karakters ondersteund worden, bespaar je ten opzichte van htmlentities op je opslag en het leest lekkerder weg in je backend.

[crisp]

DexterDee schreef op maandag 12 juli 2010 @ 18:29:
[...]
ik snap niet goed waarom Tweakers als techsite niet standaard voor UTF-8 kiest.

Omdat PHP nog steeds niet volledig unicode-compliant is...

[Sebazzz]

Dit lijkt me niet helemaal te kloppen? Foutje bij de character-set van GoT, of is dit weer het probleem dat iemand iets vanuit Word zit te copy-pasten, wat problemen zou opleveren?

Dat laatste waarschijnlijk

crisp schreef op maandag 12 juli 2010 @ 19:32:
[...]

Omdat PHP nog steeds niet volledig unicode-compliant is...

Dan krijg je problemen met de RML parser ja.

Ik weet niet zeker of Firefox dat nu doet bij de formsubmit of dat het serverside gebeurt.

Serverside. Een browser zou dat gedrag niet mogen geven.

[ Voor 61% gewijzigd door Sebazzz op 12-07-2010 19:37 ]

[DexterDee]

crisp schreef op maandag 12 juli 2010 @ 19:32:
[...]

Omdat PHP nog steeds niet volledig unicode-compliant is...

Zeg maar volledig niet. Maar dat wil nog niet zeggen dat er geen makkelijke workarounds zijn. Sowieso voor alle strings die je niet hoeft te manipuleren kun je de inhoud rechtstreeks in en uit een database als MySQL trekken met de collation op UTF-8. Voor manipulatie kom je een heel eind met de mb_string extensie. Het is jammer dat dat nog niet out-of-the-box kan, maar laten we het beste hopen voor PHP 6. Als ervaringsdeskundige (ik werk hier met een platform dat in PHP 5.2 o.a. chinees, hindi en nog wat talen moet ondersteunen op zowel het web als in B2B transacties) kan ik iig melden dat het goed te doen is.

Sebazzz schreef op maandag 12 juli 2010 @ 19:33:
Serverside. Een browser zou dat gedrag niet mogen geven.

Dat zou je inderdaad zeggen, maar als je page encoding op ISO-8859-15 staat en je voert chinese tekens in, wat zou de browser volgens jou dan naar de server moeten sturen? De tekens in de POST kunnen namelijk niet gemapped worden op de geldende characterset. Ik heb even niet gekeken wat er precies binair over de lijn gaat, maar logisch is het in ieder geval niet.

[crisp]

DexterDee schreef op maandag 12 juli 2010 @ 19:57:
[...]

Zeg maar volledig niet. Maar dat wil nog niet zeggen dat er geen makkelijke workarounds zijn.

Op een codebase als de onze is dat toch een enorme klus...

[...]

Dat zou je inderdaad zeggen, maar als je page encoding op ISO-8859-15 staat en je voert chinese tekens in, wat zou de browser volgens jou dan naar de server moeten sturen? De tekens in de POST kunnen namelijk niet gemapped worden op de geldende characterset. Ik heb even niet gekeken wat er precies binair over de lijn gaat, maar logisch is het in ieder geval niet.

Je browser stuurt numerieke entities op in dat geval.

Ja echt, zie o.a. deze beschrijving in de HTML5 WD:

quote: http://www.w3.org/TR/html...tml#url-encoded-form-data

The application/x-www-form-urlencoded encoding algorithm is as follows:

[...]

For each character in the entry's name and value that cannot be expressed using the selected character encoding, replace the character by a string consisting of a U+0026 AMPERSAND character (&), a U+0023 NUMBER SIGN character (#), one or more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) representing the Unicode code point of the character in base ten, and finally a U+003B SEMICOLON character (;).

[ Voor 31% gewijzigd door crisp op 12-07-2010 20:37 ]

[DexterDee]

crisp schreef op maandag 12 juli 2010 @ 20:33:
Op een codebase als de onze is dat toch een enorme klus...

Het is relatief makkelijk als je met een nieuw project begint. Maar met de bestaande codebase van tweakers moet je daar inderdaad niet aan beginnen. Ik weet ook niet hoe het met React zit, maar zo'n product ga je ook niet zomaar refactoren.

Je browser stuurt numerieke entities op in dat geval.

Ja echt, zie o.a. deze beschrijving in de HTML5 WD:

Dat wist ik niet, weer wat geleerd vandaag! Kom je ook niet achter als je normaal uitsluitend UTF-8 encoded forms gebruikt

[moto-moi]

NaB imo, gewoon een brakke copy-paste actie