View Single Post
Old 07-23-2014, 09:28 AM   #9
DaltonST
Deviser
DaltonST ought to be getting tired of karma fortunes by now.DaltonST ought to be getting tired of karma fortunes by now.DaltonST ought to be getting tired of karma fortunes by now.DaltonST ought to be getting tired of karma fortunes by now.DaltonST ought to be getting tired of karma fortunes by now.DaltonST ought to be getting tired of karma fortunes by now.DaltonST ought to be getting tired of karma fortunes by now.DaltonST ought to be getting tired of karma fortunes by now.DaltonST ought to be getting tired of karma fortunes by now.DaltonST ought to be getting tired of karma fortunes by now.DaltonST ought to be getting tired of karma fortunes by now.
 
DaltonST's Avatar
 
Posts: 2,265
Karma: 2090983
Join Date: Aug 2013
Location: Texas
Device: none
u_genre is pure utf-8. That is why it is showing up as a utf-8 "string", u'N\xe3o-fic\xe7\xe3o'. It never was a byte string, ever.

I have reverted to using mi.set_user_metadata('#genre', custcol) , and the gui shows u'N\xe3o-fic\xe7\xe3o' again instead of a null. That was my motivation for starting this thread in the first place.

u_genre was never not a unicode string. It was never anything except utf-8. It was imported via a .csv file encoded as Unicode(utf-8). I use a drop-in replace for Python 2.x csv dictreader that totally supports utf-8.

The header of my .py files all say : # -*- coding: utf-8 -*-

All of the plugins I have seen use # -*- coding: utf-8 -*-.

Are you saying it should be # -*- coding: utf-16 -*- ?
DaltonST is offline   Reply With Quote