Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Django generally has very good Unicode support (see the <a href="http://docs.djangoproject.com/en/1.1/ref/unicode/" rel="noreferrer" title="Django 1.1 &#39;Unicode data&#39; documentation">Django 1.1 "Unicode data" documentation</a> for details). In my code I find that, if I'm having a problem with simple Unicode features, the problem usually is that I'm not understanding Django's details well, not that Django has a bug in its Unicode support.</p> <p>The "Unicode Data" page tells us that "All of Django’s database backends ... automatically convert strings retrieved from the database into Python Unicode strings. You don’t even need to tell Django what encoding your database uses: that is handled transparently." So your simple <code>return self.nombre</code> should return a Python Unicode string.</p> <p>However, the <a href="http://docs.djangoproject.com/en/1.1/ref/databases/" rel="noreferrer">Django 1.1 "Databases" page</a> has an important note about how the MySQL backend handles the <code>utf8_bin</code> collation: </p> <blockquote> <p>...if you really want case-sensitive comparisons on a particular column or table, you would change the column or table to use the utf8_bin collation. The main thing to be aware of in this case is that if you are using MySQLdb 1.2.2, the database backend in Django will then return bytestrings (instead of unicode strings) for any character fields it returns receive from the database. This is a strong variation from Django's normal practice of always returning unicode strings. It is up to you, the developer, to handle the fact that you will receive bytestrings if you configure your table(s) to use utf8_bin collation. Django itself should work smoothly with such columns, but if your code must be prepared to call django.utils.encoding.smart_unicode() at times if it really wants to work with consistent data ...</p> </blockquote> <p>So, in your original example, the column "nombre" used utf8_bin collation. This meant that <code>self.nombre</code> was returning a Python byte string. When you put it in an expression that required a Python Unicode string, Python performed its default conversion. This is the equivalent of <code>self.nombre.decode('ascii')</code>. And of course, <code>.decode('ascii')</code> fails when it encounters any byte above 0x7F, such as the UTF-8 bytes which encode "á". </p> <p>You discovered the two ways to solve this problem. The first is to convert the Python byte string returned by <code>self.nombre</code> into a Python Unicode string explicitly. I'll bet the following simpler code would have worked:</p> <pre><code>return self.nombre.decode('utf8') </code></pre> <p>The second approach is to change the MySQL collation for column "nombre", which causes Django's MySQL backend to return Python Unicode strings instead of the unusual byte strings. Then your original expression gives a Python Unicode string:</p> <pre><code>return self.nombre </code></pre> <p>Hope this helps.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload