Кодирование проблем в направляющих на рубиновых 1.9.1
Для 32-разрядных систем 'фактический' стандарт является ILP32 — то есть, int, long и указатель все 32-разрядные количества.
Для 64-разрядных систем, основной Unix 'фактический' стандарт является LP64 — long, и указатель являются 64-разрядными (но int является 32-разрядным). Windows 64-разрядный стандарт является LLP64 — long long и указатель, является 64-разрядным (но long, и int являются оба 32-разрядными).
Когда-то, некоторые системы Unix использовали организацию ILP64.
Ни один из этих фактических стандартов не узаконен стандартом C (ISO/IEC 9899:1999), но всем разрешает он.
И, по определению, sizeof(char) 1, несмотря на тест в Perl настраивают сценарий.
Примечание, что были машины (Crays), где CHAR_BIT было намного больше, чем 8. Это означало, IIRC, это sizeof(int) равнялось также 1, потому что и char и int были 32-разрядными.
2 ответа
Я только что получил это, поэтому я думаю, что стоит иметь правильный ответ.
Гем MySql 2.8.1 не поддерживает utf-8, поэтому иногда он возвращает строки UTF и лжет Rails, говоря ему, что они являются ASCII, тогда как на самом деле это UTF-8. Это заставляет вещи взорваться.
Итак: вы можете либо заплатить обезьяну, либо получить совместимый гем MySql. См .: http://gnuu.org/2009/11/06/ruby19-rails-mysql-utf8/
Похоже, проблема с кодировкой ERB в Ruby 1.9. Более подробная информация в билете на маяк . Патч с обходным путем был включен , возможно, он вам подходит?
Проблема заключается в коде erb в дистрибутиве ruby 1.9. Когда он компилирует код шаблона, он принудительно использует кодировку «ASCII-8bit», проблема заключается в том, что когда код шаблона содержит многобайтовые символы, код шаблона возвращается в строке «ASCII-8bit» и когда эта строка объединяется с «UTF8». строка с многобайтовым символом возникает исключение, потому что строки между этими кодировками совместимы только тогда, когда оба содержат только семибитные символы.