I think the issue here is whether a generic utf8 chars inserted in a form is rendered properly in a web2py table or update form. Web2py consistently encodes everything in utf8 but it is possible that the page encoding is in latin-1 or other. In this case the submitted form would contain a non-utf8 encoding for the character.
On Tuesday, 22 January 2013 20:53:50 UTC-6, Joe Barnhart wrote: > > I'm not sure what needs solving. Were you expecting the greek mu > character to be one byte in UTF-8? It is two bytes. See the link: > > http://www.fileformat.info/info/unicode/char/3bc/index.htm > > UTF-8 is actually a variable-byte encoding scheme that can encode any > character. It is interoperable with the 7-bit ASCII char set but > encompasses all of the encodings of the universe... but with more than 8 > bits, of course. > > -- Joe > > On Thursday, January 17, 2013 10:27:17 AM UTC-8, Bill Thayer wrote: >> >> Been searching a while now for the magic decoder ring that solves the >> UTF-8 encoding issue. >> >> If I enter a mu (µ) by typing alt+0181 into my form field it looks fine. >> Then looking at the data in SQLDeveloper (Oracle) the data is 2 little >> boxes. NP I think the client encoding is wrong so I set my preferences to >> UTF-8 but µ is still 2 boxes. Still not worried yet but then I refresh or >> re-edit the field with the µ in it then it is returned from the database as >> two question marks. Same behavior occurs with the squared (²) sign...two >> boxes in db, two question marks in returned value on page. >> >> Anyone solve this yet? >> >> Thank you, >> Bill >> > --
