|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
Обращаюсь к коллективному разуму. Дано : база в Unicode UTF8, клиент тоже, DB_LOCALE и CLIENT_LOCALE выставлены в en_us.utf8. Таблица с lname char(50), fname char(50), и mid_init char(1). Требуецца : ограничить вводимые данные латинскими символами, выдавать ошибку при попытке ввода других. Текущее решение: создаем процедуру create procedure "informix".check_unicode ( p_str lvarchar(32000)); if p_str matches "*[^ -ÿ]*" then raise exception -746, 0, "Illegal Unicode character in one of character fields"; return ; end if return ; end procedure; вешаем триггер: create trigger tr_owner_person_ins insert on owner_person referencing new as new_tab for each row ( execute procedure check_unicode( ' ' || TRIM ( BOTH ' ' FROM NVL (new_tab.fname ,'' )) || TRIM ( BOTH ' ' FROM NVL (new_tab.lname ,'' )) || TRIM ( BOTH ' ' FROM NVL (new_tab.mid_init ,'' )) ) ) Тестируем: update owner_person set lname = 'आ' where owner_number = 123 -- работает, выдает ошибку 746 update owner_person set mid_init = 'आ' where owner_number = 123 -- НЕ РАБОТАЕТ!!! Ошибку не выдает. Причина, очевидно, в том что прежде чем вызывать процедуру, триггер собирает строку из _преобразованных до соответствующих длин_ новых значений. То есть 'आ' которое есть 0xE0A486 в UTF8 кодировке, превращается в 0x20 (пробел) и уже становится законным латинским символом. Понятно, что накрайняк можно переделать char(1) в char(4) (кстати, похоже, Informix глючит на 4-битовых UTF8 кодах). Any other ideas? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2012, 23:24 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
Выбегалло, решение вроде на поверхности: в триггере 3 раза вызывать ХП, а не склеивать строку... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2012, 01:30 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
И почему пробелы только ведущие и замыкающие удаляются? Не проще ли их разрешить в позволяющей ХП? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2012, 01:32 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
АнатоЛойВыбегалло, решение вроде на поверхности: в триггере 3 раза вызывать ХП, а не склеивать строку... Да хоть десять раз, пардон май френч. Информикс _сначала_ преобразует new value к типу поля (в нашем случае char(1)), потом будет вызывать что там в триггере прописано. При преобразовании он магически превращает трехбайтный Unicode символ в банальный пробел, кагбы намекая "ну не шмогла я, не шмогла" ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2012, 02:04 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
АнатоЛойИ почему пробелы только ведущие и замыкающие удаляются? Не проще ли их разрешить в позволяющей ХП? lvarchar(32000) конечно немало, но и не так уж много. Экономить приходится. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2012, 02:06 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
ВыбегаллоПонятно, что накрайняк можно переделать char(1) в char(4) (кстати, похоже, Informix глючит на 4-битовых UTF8 кодах). Any other ideas? Конфигурационный параметр SQL_LOGICAL_CHAR установлен? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2012, 12:08 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
victor16ВыбегаллоПонятно, что накрайняк можно переделать char(1) в char(4) (кстати, похоже, Informix глючит на 4-битовых UTF8 кодах). Any other ideas? Конфигурационный параметр SQL_LOGICAL_CHAR установлен? Во-первых, этот параметр влияет только на DDL, определяя коэффициент умножения. Если в оригинале было create table t1 (col1 char(1)), то в зависимости от параметра и codeset мы можем получить col1 типа от char(1) до char(4). Это, конечно, зашибись - пока нас не интересуют размеры таблицы и максимальные длины строк. На поведение триггера и очередность преобразований параметр никак не влияет. Во-вторых, че-то он у меня так и не заработал. Ни c SQL_LOGICAL_CHAR=ON, ни c SQL_LOGICAL_CHAR=4 - как было char(1) так и осталось. create database test; create table t2 (col1 varchar(1), col2 char(1), col3 char(5)); insert into t2 (col1) values ('आ'); insert into t2 (col2) values ('आ'); insert into t2 (col3) values ('आ'); select ascii(col1), ascii(col2), ascii(col3) from t2 (expression) (expression) (expression) 32 32 8824032 ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2012, 02:20 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
Выбегалло ... select ascii(col1), ascii(col2), ascii(col3) from t2 ... А что, если вызвать функции LENGTH (also known as LEN), OCTET_LENGTH, CHAR_LENGTH (also known as CHARACTER_LENGTH) Интересно, что они возвращают при установленном SQL_LOGICAL_CHAR ? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2012, 20:36 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
ВыбегаллоКонфигурационный параметр SQL_LOGICAL_CHAR ... че-то он у меня так и не заработал. У меня работает, только если он был установлен при создании базы. Если установить SQL_LOGICAL_CHAR после создания базы, не оказывает никакого влияния, как будто его нет. Ниже Ваш SQL-скрипт, немного подправленный: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Из результатов видно, что длины значений UTF8 и ASCII при установленном SQL_LOGICAL_CHAR=4 различаются. Для читабельности оформил в виде таблицы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2012, 23:14 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
чего-то меня форматирование подвело :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2012, 23:19 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
victor16Выбегалло ... select ascii(col1), ascii(col2), ascii(col3) from t2 ... А что, если вызвать функции LENGTH (also known as LEN), OCTET_LENGTH, CHAR_LENGTH (also known as CHARACTER_LENGTH) Интересно, что они возвращают при установленном SQL_LOGICAL_CHAR ? Nope. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42.
Все так же преобразовывает в пробел, пала... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.12.2012, 02:23 |
|
Как ограничить вводимые данные латинскими символами ?
|
|||
---|---|---|---|
#18+
victor16ВыбегаллоКонфигурационный параметр SQL_LOGICAL_CHAR ... че-то он у меня так и не заработал. У меня работает, только если он был установлен при создании базы. Если установить SQL_LOGICAL_CHAR после создания базы, не оказывает никакого влияния, как будто его нет. Ниже Ваш SQL-скрипт, немного подправленный: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Из результатов видно, что длины значений UTF8 и ASCII при установленном SQL_LOGICAL_CHAR=4 различаются. Для читабельности оформил в виде таблицы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
И как выглядит вывод dbschema -d .... -t t2 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.12.2012, 02:30 |
|
|
start [/forum/topic.php?fid=44&msg=38060713&tid=1607099]: |
0ms |
get settings: |
22ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
139ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
315ms |
get tp. blocked users: |
2ms |
others: | 288ms |
total: | 799ms |
0 / 0 |