| 6 | |
| 7 | == Character encoding issues == |
| 8 | |
| 9 | Several tickets are mentioned in this mailing list thread: |
| 10 | [http://groups.google.com/group/django-developers/browse_thread/thread/4b71be8257d42faf/ unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users] |
| 11 | |
| 12 | Tickets: |
| 13 | * #3370, #1356, #952, #3370 |
| 14 | |
| 15 | === Comments made by Michael in the above mailing list thread === |
| 16 | |
| 17 | The problem that started the original thread in django-users was that |
| 18 | the MySQLdb backend thought it was using latin-1 encoding for the |
| 19 | connection and therefore could not encode '€', which is in iso-8859-15 |
| 20 | but not in iso-8859-1 aka iso-latin-1. Ticket #2896 seems to explain how |
| 21 | this can happen. |
| 22 | |
| 23 | In my opinion, each of the three tickets in the subject should solve |
| 24 | this issue, and none tries to cope with templates written in a different |
| 25 | encoding than settings.DEFAULT_ENCODING. |
| 26 | |
| 27 | #952 allows to use a different encoding on the connection than |
| 28 | settings.DEFAULT_CHARSET. It does it for all backends. |
| 29 | |
| 30 | #1365 sets connection.charset in the mysql backend to utf8. This makes |
| 31 | the MySQLdb use utf8 encoding, but it's hackish and has been reported |
| 32 | not to work in all environments. |
| 33 | |
| 34 | #3370 opens the mysql backend connection with charset='utf8', which |
| 35 | seems a cleaner way to do the same as #1365. It also fixes the __repr__ |
| 36 | of models (not sure if this is the best way, but this can be added to |
| 37 | any of the other patches) |
| 38 | |
| 39 | My bottom line is that #952 has a different scope than the other two |
| 40 | tickets, and that #1365 should be closed as duplicate of #3370. #3370 |
| 41 | and #952 can co-exist. |