Комментарии 37
мне кажется уже давно в БД хорошим тоном стало не называть поля по русски.
и не держать там русский текст?
НЛО прилетело и опубликовало эту надпись здесь
1С, не входи, 1С, уходи.
НЛО прилетело и опубликовало эту надпись здесь
Нет, не лучше.
НЛО прилетело и опубликовало эту надпись здесь
Населённый пункт можно City. Менее общее слово, но смысл отражает, если не нужно отличать деревни от посёлков городского типа.
ОКПО — RussianCompanyUberID. А если серьёзно, такие укоренившиеся аббревиатуры можно бы и транслитом оставить, на мой взгляд.
ОКПО — RussianCompanyUberID. А если серьёзно, такие укоренившиеся аббревиатуры можно бы и транслитом оставить, на мой взгляд.
НЛО прилетело и опубликовало эту надпись здесь
Признайтесь, Вам нравится несколько раз переключать раскладку при написании одной строки кода? Ну, я сейчас говорю не про 1С, разумеется.
Понимаю вашу неприязнь. Но почему он тогда так востребован?
Известная проблема SQLite состоит в том, что он не любит никаких символов, кроме латинских, поэтому выполняется такое [1]:Дело в LIKE, а не в SQLite вообще :-)
SELECT «ы» LIKE «Ы»;
0
SELECT «s» LIKE «S»;
1
FTS3 вас спас бы, если дело только в этих LIKE'ах.
P.S. Русский текст оно ищет, но ен понимает буквы в разном регистре. Т.е «Ы» != «ы», но «Ы» == «Ы».
UPPER, LOWER не реагируют на любые символы, кроме латиницы.
Решение выше позволяет исправить этот недостаток в андроиде, и еще и дописывать собственные функции для бд
Решение выше позволяет исправить этот недостаток в андроиде, и еще и дописывать собственные функции для бд
дописывать собственные функции для бдВот это уже аргумент, ибо проблема с регистром обходится и без NDK.
Нужно редактирование комментариев, хотя бы в пределах пяти минут :-)
P.S. Блог Разработка под Андроид подходит лучше для этой заметки.
P.S. Блог Разработка под Андроид подходит лучше для этой заметки.
«SELECT * FROM tablename WHERE rus_text_field LIKE ура%»
простите, а это работает?! без кавычек вокруг «ура%» ?!!!
простите, а это работает?! без кавычек вокруг «ура%» ?!!!
Странно, откуда такая проблема. Под WinCE 4.2+ sqlite отлично работает с русским текстом, в том числе и с like 'Перемещение%'. Версия 3.7.4. Правда под WinCE используется только Unicode двухбайтовый. Мне удается даже на сервере генерировать sqlite-базу в UTF-8 и в UTF-16 отлично её открывать и работать с ней и русским текстом в ней (даже не имея на девайсе русской локали), передав её по сети.
Возможно работа с sqlite только в UTF-16 решает проблему?
Возможно работа с sqlite только в UTF-16 решает проблему?
Ничего не понял зачем JNI для работы c SQLite русским языком. Мое приложение прекрасно работает с русскими данными и без костылей :)
Есть только одна загвоздка оно не умеет работать Lowercase/Uppercase надо поставить что-то дополнительное, но я просто перевел все строки в lowercase и забил на эту проблему, так как было не важно :)
Есть только одна загвоздка оно не умеет работать Lowercase/Uppercase надо поставить что-то дополнительное, но я просто перевел все строки в lowercase и забил на эту проблему, так как было не важно :)
Да, с русскими данными работает прекрасно, но не тогда, когда критичны эти самые верхне/нижние регистры :)
Допустим, я не могу просто перевести в ловеркейс строку «ОФИГИТЕЛЬНАЯ штука Баян!», а искать по таким полям нужно
Допустим, я не могу просто перевести в ловеркейс строку «ОФИГИТЕЛЬНАЯ штука Баян!», а искать по таким полям нужно
Просто из самого топика было не сразу понятно, в чем собственно состоит проблема. Неплохо бы было изучить альтернативные решения или хотя бы их упомянуть. Такие как хранить 2 колонки одна с оригинальным описанием, вторая с индексом или lowercase.
Проблема любого использования NDK, что это решение не универсально для всех Android, вполне возможно придется перекомпилировать для некоторых нестандартных ARM, именно по этой причине пришлось отказаться от этого.
P.S.: постановка проблема, существующие решения и их преимущества/недостатки, ваше решение и преимущество/недостатки, все по-взрослому, шучу :)
Проблема любого использования NDK, что это решение не универсально для всех Android, вполне возможно придется перекомпилировать для некоторых нестандартных ARM, именно по этой причине пришлось отказаться от этого.
P.S.: постановка проблема, существующие решения и их преимущества/недостатки, ваше решение и преимущество/недостатки, все по-взрослому, шучу :)
Проблема проявляется, например, в том, что для поиска, например, города для того же виджета погоды, надо начитать вводить его с большой буквы, что вроде как глупое требования в наше время заботы о пользователе. Аналогично с вводом имени-фамилии при вводе адресата в смс для автоподстановки, если это не реализовано специально смс-менеджером.
Странно, но я сталкивался только с проблемой MATCH (учет регистра), остальное все отлично работает с кирилицой в sqlite на android.
вопрос не по теме: а как научить стандартную медиа-библиотеку читать тэги из музыкальных файлов в кодировке 1251, а не utf-8? а то из-за этого невозможно пользоваться большинством плееров. только пара плееров идут в обход библиотеки и читают тэги напрямую и при этом позволяют указать кодировку.
Никак, IDv*, начиная с какой-то версии, по стандарту(!) требует UTF-8, хранение в cp1251 – это проблемы плееров, которые так делают. А кто, кстати, так делает-то?
Проблема не решилась. Пришлось через SQLiteDatabase.CustomFunction пробрасывать
Ну и добавить функцию
private final SQLiteDatabase.CustomFunction mLowerFnc =
new SQLiteDatabase.CustomFunction() {
@Override
public String callback(String[] args) {
String text = args[0];
text = text.toLowerCase();
Log.d(LOG, "LOWER_FNC : " + text);
return text;
}
};
Ну и добавить функцию
database.addCustomFunction("LOWER_FNC", 1, mLowerFnc);
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как подружить SQLite андроида с языком, отличным от английского