Cases (Posty o unicode)

Definiowanie kodowania w plikach źródłowych Pythona

Grzegorz Śliwiński — Sat, 31 Dec 2011 12:12:21 GMT

Dlaczego definiowanie kodowania w pliku źródłowym Pythona jest istotne?

Czytaj więcej… (zostało 1 minut czytania)

Unicode a python

Grzegorz Śliwiński — Sun, 06 Feb 2011 17:02:36 GMT

Od paru miesięcy programuję w Pythonie. Najpierw oczywiście trzeba się było Pythona nauczyć, zanim zacząłem w robocie dostawać pierwsze zadania, ale źle nie było. Jedna rzecz mnie w Pythonie zdziwiła, a mianowicie podejście do kodowania stringów. Zresztą, po dziś dzień rozwiązanie tej kwestii w Pythonie sprawia mi niemały kłopot.

Otóż w Pythonie, by ciąg znaków mógł zawierać wszelkie krzaczki i ogonki, musi być unicodowym ciągiem znaków. Zwykłe stringi akceptują tylko i wyłącznie znaki ASCII.

I tak deklarując zmienną w kodzie, na pewno będzie stringiem.

zmienna = 'łańcuch'

Raczej bez różnicy, jakich znaków użyjemy. Jeśli jednak wartość zmienna zostaje wczytana z zewnętrznego źródła danych, wtedy możemy napotkać problem.

Załóżmy teraz, że wczytujemy i przetwarzamy jakiś dokument XML, są one kodowane przeważnie w utf-8. Wartości które będziemy przeważnie przetwarzali zazwyczaj zmieszczą się w spektrum kodowania ASCII i ich konwersja będzie jakby automatyczna, jednak co jakiś czas natrafimy w pobieranych wartościach na polskie ogonki, czeskie ptaszki albo chińskie krzaczki. Wtedy albo program się wywali (na naszym kodzie, np. złączeniu łańcuchów) stwierdzając, że znak w łańcuchu jest spoza zakresu ASCII (lub podobny błąd), albo błąd zwróci wywoływana przez nas funkcja. jakkolwiek wydaje się to zabawne, spora część funkcji nie radzi sobie z Unicode.

Jak to obejść? Wyłapać się wszystkiego w czasie pisania nie da, można chyba tylko przed wywołaniem, które zwraca błąd zastosować poniższą konstrukcję:

if isinstance(zmienna, unicode):
    zmienna = zmienna.encode('utf-8')

Gdy po raz pierwszy spotkałem się z tym problemem, znalazłem informację o możliwości zdefiniowania kodowania plików źródłowych:

# -*- coding: utf-8 -*-

Ta konstrukcja służy jednak tylko i wyłącznie zdefiniowaniu kodowania kodu źródłowego, nie kodowania używanego przez Pythona. Stąd w swoich pierwszych programach napisanych w pythonie używałem sporo wywołań metody encode i decode na stringu.

Polskie znaki w MySQL, doctrine i symfony

Grzegorz Śliwiński — Sun, 09 May 2010 10:05:53 GMT

Niejednokrotnie tworząc bazę danych w MySQL, nie trudno nie zauważyć, iż w świeżej, nieskonfigurowanej instalacji tego systemu zarządzania bazą danych, domyślnym typem kodowania nie jest utf8 tylko cp1252/latin1_swedish.

Tworząc aplikację korzystającą z takiej bazy, a samej używającej unicode, powinniśmy dla świętego spokoju sprawdzić i pilnować z jakiego kodowania nasza baza danych korzysta. Choćby dlatego, że inna aplikacja podłączona do takiej bazy danych może mieć problemy z rozpoznaniem i połapaniem się w tej mieszance kodowań. Nie jest również zbyt intuicyjnym przechowywanie ciągu znaków zakodowanego w unicode, w strukturze używającej cp1252 lub innego systemu kodowania.

Również symfony, z całym przywiązaniem do unicode, nie robi nic, by wymusić stosowanie tego kodowanie w tworzonych poprzez doctrine tabelach, czy też samym połączeniu na lini baza danych - aplikacja. Konieczne jest ręczne ustawienie odpowiednich wartości w pliku database.yml:

all:
  doctrine:
    class: sfDoctrineDatabase
    param:
      #...
      attributes:
        default_table_charset: utf8
        default_table_collate: utf8_general_ci

W ten sposób można w spokoju tworzyć aplikacje używające kodowania unicode bez obawy wystąpienia błędu nieprawidłowego kodowania znaków w porównaniu MySQL, lub innych niespodzianek z tym związanych.

Z reguły znaki używane na zachodzie (znaki ASCII) są kodowane w ten sam sposób w unicode jak i w cp1252/latin1, czego nie można powiedzieć o polskich ogonkach, czy występujących w czeskim i innych zachodniosłowiańskich językach ptaszkach (Przykład: Čech).