|
|
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
Заметил я одну странную вещь. UTL_ENCODE.base64_encode кодирует с переносами строк CRLF через каждые 65 символов, что соответствует RFC 2045. Но при этом парная ей функция UTL_ENCODE.base64_decode Не может правильно обработать Вывод своей же кодирующей сестры - близняшки. Ей нужно подавать на вход без пробелов. Собственно вопро: как так? Или я что-то не заметил в особенностях их использования? Ну ладно, я. Но ведь и многие другие вовсю колхозят и велосипедят на тему удаления переносов строк: Base64 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 08:52 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
ART-CODEUTL_ENCODE.base64_decode Не может правильно обработать Вывод своей же кодирующей сестры - близняшки Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 09:11 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
-2-, Спасибо, подогнать решение под ответ я могу. Выкусывать по одной строке, конечно можно. Но кодирующая функция умеет давать на выходе сразу несколько строк. Значит, и декодирующая должна уметь так же: не по одной строке. В статье, на которую я привел ссылку какраз критикуется такой построчный метод как медленный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 09:26 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
ART-CODEСпасибо, подогнать решение под ответ я могу.Тогда приведи пример, подтверждающий то, на что я отвечал:ART-CODEUTL_ENCODE.base64_decode Не может правильно обработать Вывод своей же кодирующей сестры - близняшки ART-CODEВ статье, на которую я привел ссылку какраз критикуется такой построчный метод как медленный.Это не проблема "алгоритма", а вопрос размерности raw. Если объем кодированных данных больше 32767, то приходится резать так или иначе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 10:20 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
В целом, я исхожу из того, что кодирует по RFC 2045, Но декодирует по RFC 4648 Вот мое "творение", с учетом этого утверждения. Сейчас тестирую. Код: 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. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 11:30 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
Ой, забыл: report the erroneous encoding to the user Надо проверять и ругаться, если есть переносы далее 76, но это что же получается? Нельзя ограничиться контрольной строкой, надо ве проверять? Накладно, однако. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 12:01 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
Короче, в основном цикле декодирования делаем проверку: Код: plsql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 13:55 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
Так пример-то ART-CODE"UTL_ENCODE.base64_decode Не может правильно обработать Вывод своей же кодирующей сестры - близняшки." будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 14:20 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
Ок, вечером. Впрочем, если нет желания ждать, то достаточно из моего декодера выкинуть цикл удаления переносов строк, чтобы получить на выходе битый файл, который ранее был щакодирован оракловой энкоде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 14:41 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
ART-CODEполучить на выходе битый файл, который ранее был щакодирован оракловой энкоде. Вам уже привели пример, демонстрирующий совместимость 21703864 Контрпримера пока нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 15:39 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
Ясно, похоже, что в парном режиме они работают, но только для небольших размеров. Когда начинается нарезка фрагментов больших файлов, то все становится плохо. Кажется, я оказался одновременно и не прав в теории, но все-же прав в реализации - для больших файлов. Потестирую еще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 15:55 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
ART-CODEКогда начинается нарезка фрагментов больших файлов Нарезать надо не абы как - и все получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 17:09 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
ART-CODEКогда начинается нарезка фрагментов больших файлов, то все становится плохо.При энкодировании резать кратно выходным строкам - 48 входных байт. При декодировании достаточно искать crlf от конца предыдущего буфера плюс 32767 минус запас на размер строки, например, =32000. Удалять crlf не нужно. Если crlf отсутствует, можно читать кратно 4 байтам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 17:31 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
-2-Если crlf отсутствует, можно читать кратно 4 байтам. Проще читать из лоба кратно 4 байтам. Если буфер не полон (вычитано меньше, чем запрошено) - декодировать. Если буфер полон "под крышку" - то пробовать обрезать хвост поиском crlf справа (с соответствующей корректировкой смещения lob), при отсутствии хвоста - просто декодировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 18:20 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
Да, огромное спасибо, все работает :) Я, видимо, очень спешил, и даже ту статью невнимательно прочитал. ("по верхам") Подправил свой код, и успешно раскодировал с переносами строк. Правда, там есть допущение о том, что размер буфера во входящем CLOB - не меняется, и переносы строк всегда на том же месте, как и в первой строке. И не уверен, что правильно поступил с проверкой на кратность 4. И еще я заменил определение размера буфера - в статье для этого применялся Instr ко всему CLOB, а я побоялся так делать для больших файлов, на всякий случай забираю первые 100 символов и уже там ищу перенос строки. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2018, 00:45 |
|
||
|
Oracle base64 FRC version?
|
|||
|---|---|---|---|
|
#18+
Вот же, елки-палки! Я понял, наконец, в чем была проблема. Oracle 11g и 12 По-разному делают энкоде. 11- пишет переносы строк внутри многострочного блока base64, но не пишет их в конце, и их нужно руками добавлять. А 12 оракл кодирует нормально, и переносы строк есть всегда. Поэтому мои опыты по раскодированию были настолько неудачны, что я не верил в возможность раскодировать. А закодированный файл - как оказалось, был поврежден. При этом, внешние программы, с которыми я сравнивал результат - о повреждении не сообщали, и успешно раскодировали. Да что там, внешние программы, даже моя первая процедура декодирования из этого топика проблем не замечала, и хорошо раскодировала. Какие кровавые грабли! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2018, 20:04 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39718626&tid=1883324]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
149ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 204ms |
| total: | 445ms |

| 0 / 0 |
