|
DataSet to JSon и обратно (mormot)
|
|||
---|---|---|---|
#18+
Созданию текстовое представление Поля типа binary и longvarbinary. Код: sql 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. 43. 44.
Так получается для значения 0x123456 строка вида "EjRW" (первый символ квадратик, он тут не получился). Как мне обратно получить из этой строки обратно binary? Получается какой-то мусор. ВОт пример тоже: Код: sql 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. 43. 44. 45. 46. 47. 48.
Заранее большое спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
05.10.2021, 13:44 |
|
DataSet to JSon и обратно (mormot)
|
|||
---|---|---|---|
#18+
bzums Получается какой-то мусор. я так думаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.10.2021, 13:49 |
|
DataSet to JSon и обратно (mormot)
|
|||
---|---|---|---|
#18+
Я тоже так думаю :-) Немного перефразирую вопрос Простенький пример: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Этот код работает - из базы нормально тянет 0x123456 в текст "EjRW" и обратно. Но я использую Mormot / Synopse, приблизительно так (код немного другой): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
В целом работает, но, что интересно, между ТУДА и ОБРАТНО строка "EjRW" в самом начале содержит $FFF0. То есть этот метод WrBase64 в начало вставляет это. В результате при обратном преобразовании я имею не $18 $52 и $86, а через один - $18 $00 $52 $00 $86 $00, но длина та же. Как это победить? Очень похоже на то, что то как поле базы данных binary посредством ODBC видится как ftBytes, а nlongvarbinary - ftBlob реализовано некорректно. Надо чтоли явно указать как их рассматривать.... Или что-то еще придумать. Не пробовал, но если убрать из текмта этк добавку, то все будет нормально скорее всего. Всем заранее спасибо за советы. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.10.2021, 20:25 |
|
DataSet to JSon и обратно (mormot)
|
|||
---|---|---|---|
#18+
bzums Код: sql 1. 2.
bzums Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.10.2021, 20:36 |
|
DataSet to JSon и обратно (mormot)
|
|||
---|---|---|---|
#18+
Не уверен, что понимаю, но это кусок кода из библиотеки. :-) За сюрреализм не отвечаю тоже. То есть кодирование так было уже сделано давным давно. Моя задача - принять это все обратною Хотя можно и поменять наверное, раз уж это является причиной всего этого чудачества... Наверное формально можно сделать и вовсе без всякого кодирования - StrToBytes и BytesToStr. Да, если убрать из начала FFF0 и оставить чисто строку 'EjRWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=' то все нормально, получаю обратно то, что и было закодировано. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.10.2021, 20:52 |
|
DataSet to JSon и обратно (mormot)
|
|||
---|---|---|---|
#18+
bzums, не уверен, что там в LString, но разве не так - W.WrBase64(pointer(LString), length(LString) * 2 , true) ? ну и base64 для кодирования байт уже, так что зачем из байт делать WideString и потом из него base64 - загадка... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.10.2021, 21:48 |
|
DataSet to JSon и обратно (mormot)
|
|||
---|---|---|---|
#18+
Спасибо за инфу к размышлению. Буду смотреть. По правде говоря, кроме как об экономии места у меня никаких мыслей нет. Есть ли какая разница, blob поле или простое binary? Ну кроме размера конечно. То есть модно ли из абсолютно одинаково рассматривать? ( То есть и импортировать и экспортировать ?) И самое главное - если вовсе не производить кодирование? На что это влияет кроме размера? Большое спасибо всем. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.10.2021, 22:23 |
|
|
start [/forum/topic.php?fid=58&msg=40102184&tid=2036972]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 273ms |
total: | 410ms |
0 / 0 |