Rails N'Ruby1.9

Używaj tłumaczeń. Nawet jak masz aplikację tylko po polsku to składowanie wszystkich stringów poza widokami rozwiąże Twój problem, poza tym oczyści widoki.

To prawda, sprawa tłumaczeń rozwiązuje się sama przez się :), kolega dobrze radzi.

Jednakże dalej to co z formularza np. nie przejdzie walidacje i ponownie potrzeba wyświetlić to niestety nie jest w utf-8, oczywiście mam na myśli wszystko spoza ASCII. Co innego to co jest wyświetlane z bazy, bez problemowo wyświetlane bo przekodowane na utf-8. Sporo tekstów w necie prostuje inne tematy z utf-8, jednak dalej wisi ten sam problem, binary ascii string prosto z Racka. Trzeba będzie kombinować i czekać.

A i z tego co wyczytałem to problem z concatenate to sprawa z Ruby 1.9 a nie Railsów. No niestety. Ale są na to łatki.

Ja używam Rubiego 1.9 i Railsów 2.3.5 od ładnch paru miesięcy i nie mam żadnych problemów z kodowaniem.

W tamtym wątku w zasadzie jest większość rozwiązań, które zostały już portowane do mainstreamowych dystrybucji. Jedyne co trzeba jeszcze zrobić (o czym też pisałem wyżej) to “sforsować” odpowiedni encoding na łańcuchach w “params”. Reszta powinna działać bez problemu (choć przyznam, że nie używam ERb, tylko Haml-a, więc nie wiem, czy w tym pierwszym wypadku faktycznie nie ma jakiś dodatkowych problemów).

W Rails 3 i Ruby 1.9, niestety są dalej problemy, korzystam z bebechów 3ki i nie mam jak już wrócić do 2.3. A kolega @apohllo też dobrze prawi i jasno opisał fakt, że da się pięknie ożenić Ruby 1.9 i Railsy 2.3. Polecam :slight_smile:

No niestety moich problemów nie rozwiązuje, bo nadal mam incompatible character encodings :wink:

No i, że tak pomarudzę, beta4 miała niby rozwiązywać problemy z kodowaniem, ale albo tego nie robi, albo robi tak, że nie potrafię się tym posługiwać. Czy ktokolwiek w ogóle osiągnął jakieś sukcesy przy zmuszaniu ruby1.9 do współpracy z rails3 z polskimi znakami w widokach?

Czy przed walidacją lub zapisaniem do bazy force_encoding(‘utf-8’) nie rozwiązuje Twojego problemu?

Problem jest jak rozumiem w widokach… własnie sprawdziłem ERB (erubis) i HAML pod Rails 3.0 beta4, nie mam takiego problemu.

Sprawdź czy na pewno Twój edytor zapisuje pliki w formacie UTF-8 i czy pierwsza linikja wszystkich plików źródłowych (kontrolery, modele) wygląda tak:

# encoding: UTF-8

[quote=hubertlepicki]Sprawdź (…) czy pierwsza linikja wszystkich plików źródłowych (kontrolery, modele) wygląda tak:

[code ruby]

encoding: UTF-8

[/code][/quote]
Co za dużo to nie zdrowo. :wink: Ta linijka służy jedynie do wymuszenia kodowania pliku podczas jego parsowania, dzięki czemu można mieć nazwy zmiennych w UTF-8 (λ = 0.4; puts λ) oraz znaki UTF-8 w stringach, wyrażeniach regularnych oraz symbolach. Jednym słowem jest potrzebna tylko jeśli są w nim znaki, których nie da się zakodować w ASCII 7-bit. Użycie jej powoduje, że wszystkie stringi będą miały kodowanie UTF-8, co trochę zmniejsza wydajność podczas operacji na nich. Również parsowanie kodu będzie trochę wolniejsze. Ruby samo powie, kiedy ta magiczna linijka jest potrzebna:

test.rb:6: invalid multibyte char (US-ASCII) test.rb:6: syntax error, unexpected $end, expecting keyword_end result << "ąabc" ^
Więcej szczegółów jest w ostatnim Pickaxe s. 266.

No, ja wczoraj sprawdzając, czy w HAML-u błąd występuje, ogarnąłem, że to nie widoki (przynajmniej nie do końca one), ale właśnie baza jest winna, bo akurat w projekcie, na którym to testowałem, zapomniałem zrobić magicznego hacka z utfem. Teraz już działa, natomiast nadal jest dla mnie interesujące, że:

  • dane z bazy w US-ASCII, widok w UTF-8 (z polskimi znakami) - działa [to mnie zmyliło]
  • dane z bazy w US-ASCII, widok w UTF-8 (z polskimi znakami w obrębie bloku form_for) - nie działa
  • dane i widok w UTF-8 - działa oczywiście.

Dlaczego punkt pierwszy? :wink:

Punkt pierwsY działa bo ascii jest podzbiorem utf8. Ale już nie w drógą stronę!

Problem jest już rozwiązany w Rails beta4 i rack 1.2.1. (ruby-1.9.2-preview3)

:slight_smile:

dla Ruby 1.9.2 i Railsów 2.3.9 dostaje właśnie incompatible character encodings: ASCII-8BIT and UTF-8 dla tłumaczenia z locali.
dodanie tam # encoding: UTF-8 nic nie dało

z gemem mysql czy mysql2? Bo jeśli z tym pierwszym to musisz użyć workarounda.

mysql (2.8.1)

Artur79: przy testach, czy w aplikacji?

W aplikacji, chyba chodzi o plik pl.yml. Rozumiem ze takie połączenie jak wyżej wersji Ruby’ego i Railsów jest ok i do tłumaczeń już nie powinno sie nic doinstalowywać ?

Aplikacja jest na railsach 3.0.3, ruby 1.9.2. Jakie jest obecnie najlepsze rozwiązanie na problem

na serwerze chodzi ok, natomiat na lokalu pojawia się powyższy błąd.
baza na lokalu to
Version: 5.1.49-1ubuntu8
Version: 5.1.49-1ubuntu8.1
a na serwerze
ersion: 5.0.51a-24+lenny2~bpo40+1
Version: 5.0.32-7etch12

Pomaga powrót do ruby 1.8.7, ale może są jakieś rozwiązania żeby móc używać 1.9.2

Zdecydowanie mysql2