|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Столкнулся с одной проблемой. Пытаюсь её решить уже 6 месяцев, но она была не столь важна. Сейчас эта проблема является уже критичной. Суть проблемы в следующем. Есть торговый терминал QUIK. Он пишет сообщения о результатах поданных операций/сделок. Есть Каше, который считывает эти операции из файла. Я вижу текст нормально. Каше видит его ненормально. Точнее он вообще его не видит. Проблема даже не в кодировке, а глубже, т.к. не совпадает кол-во символов. См вложенный файл. Все настройки локали стоят по умолчанию = Русский язык. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:03 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Проблема в том, что когда Каше создаёт файл, и делает в него записи, то все нормально. Я вижу нормально и КАШЕ видит нормально. Но стоит только сделать одну запись о сделанной операции в QUIK в данный файл, то запись сделанная Каше - становится в изменённой кодировке (но не вопросительные знаки (разные квазебяки), а ко-во символов примерно равно содержанию текста)). И при попытке считать - новую строку с записью - получается как на рисунке - одни знаки вопроса, вместо русской кодировки. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:03 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
А вот так выглядит файл (первоначально), сгенирированный Cache Звонил разработчикам софта. У них настройки изменить нельзя. Кодировку они не знают, в которой пишется запись в файл, но даже если бы и сказали, я вообще не представляю как можно в каше поменять раскладку кодировки в считываемом файле. Вопрос. Кто нибуть сталкивался с таким чудом и если да, то как это можно обойти или решить. Посимвольное считывание - ничего не даёт. Да и вообще вариантов 20 перепробовал - результат один и тот же. Каше все русские буквы воспринимает как символ №63 в (знак ?) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:09 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
О-О-О , Приложите небольшой файл с "неверными" данными и код как его читаете/пишете. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:12 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
О-О-ОПроблема в том, что когда Каше создаёт файл, и делает в него записи, то все нормально. Я вижу нормально и КАШЕ видит нормально. Но стоит только сделать одну запись о сделанной операции в QUIK в данный файл, то запись сделанная Каше - становится в изменённой кодировке (но не вопросительные знаки (разные квазебяки), а ко-во символов примерно равно содержанию текста)). И при попытке считать - новую строку с записью - получается как на рисунке - одни знаки вопроса, вместо русской кодировки. Проблема в кодировке, каше пишет в UTF-8, а QUIK видимо в CP1251 решение, использовать одну кодировку, и судя по всему в вашем случае это CP1251 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:13 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Создаваемый файл, куда потом будут записываться данные из QUIK Код: plaintext 1. 2. 3. 4. 5. 6.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:16 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
пример кода с чтением в нужной кодировке Код: plaintext 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:16 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Код: plaintext 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:17 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
DAiMor, Вы мой спаситель. Про TranslateTable я читал в инструкции, пробовал, но ничего не получалось. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:25 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
О-О-ОDAiMor, Вы мой спаситель. Про TranslateTable я читал в инструкции, пробовал, но ничего не получалось. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:26 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Не буду открывать новый топик: хочу лишь немного обобщить. Сам столкнулся с подобным явлением, пытаясь добиться обмена двоичными данными между Cache-8-бит и Cache-Unicode через файлы. Сделал тщетную попытку передавать их, используя RAW-формат, создавая файлы стандартными средствами Cache (пробовал и команду Write, и даже высокоуровневый %Stream.FileBinary). Не получилось: если в Cache-Unicode файл открыт с таблицей RAW, любой записываемый символ с кодом >127 превращается в "?". По-видимому, причина этого явления - нестандартность внутренней кодировки Unicode в Cache; Cache как бы "сопротивляется" переносу её во внешние файлы. Файл должен быть в одной из стандартных кодировок, которую понимает Cache (перечень есть в определении локали). Что касается двоичных данных, которые нельзя подвергать кодовым преобразованиям (т.к. в Cache-8-бит и Cache-Unicode они будут закодированы/декодированы по-разному), то для них похоже нет другого варианта, кроме предварительного ("неразрушающего") кодирования в Base64, передачу в любой кодировке (разумное решение - в UTF8) и декодирования из Base64 на другом конце. Коллеги, поправьте плиз, если я что-то проглядел. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:32 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
О-О-О , Files and Character Encoding Также кодировку ( K\name\ ) можно указать непосредственно при открытии файла: 4251944 , 8130087 (примеры) Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 12:43 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
servit О-О-О , Files and Character Encoding Также кодировку ( K\name\ ) можно указать непосредственно при открытии файла: 4251944 , 8130087 (примеры) Код: plaintext 1.
Да, и он также работает. Но как я понял, каше стал больше переходить на работу с %Stream. и его производными. Ваш вариант (вариант 'Servit') оптимален при работе с версиями где в коде используется class(%File), а не ##class(%Stream. Именно при попытке совместить class(%File)+file.TranslateTable и была ошибка. Поэтому или работаете с форматом ##class(%Stream. и применяете Set file.TranslateTable или работаете с классом #class(%File) НО тогда используете код s sc=file.Open("RK\CP1251\"). Это скользкий момент, который приводил в моем случае к неработоспособности кода по преобразованию кодировок. Вариант, указанный 'Servit' подходит тем, у кого код написан еще через #class(%File) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 14:07 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Да, раз пошла такая тема. Эти два варианта открытия и обработки внешнего файла через класс class(%File) и класс class(%Stream.ххх) СУЩЕСТВЕННО ОТЛИЧАЮТСЯ ПО СКОРОСТИ Буквально неделю назад перешёл с class(%File) на class(%Stream.ххх) и проверил скорость обработки. Код был идентичен, только строчки из внешнего файла открывал по разному. Через class(%File) обработка длилась 10,7-10,8 сек а через class(%Stream.File...) тот же код уже обрабатывался за 8,2-8,3 сек. В общем, разница была около 30% и ТОЛЬКО ЗА СЧЕТ ИЗМЕНЕНИЯ 2-Х строчек в коде! ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 14:18 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
И ещё одно. через class(%File) нельзя открывать большие файлы (подвисают) а с помощью class(%Stream.ххх) запросто можно обрабатывать файлы с данными под 80 Мб (более крыпных файлов не было), тогда как class(%File) уже на 4 Мб начинает жутко капризничать. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 14:22 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
О-О-ОИ ещё одно. через class(%File) нельзя открывать большие файлы (подвисают)Можно. Жили же как-то до этого. И скорость будет не меньше, если писать код оптимально. Более того новые классы любезно используют класс %File, а все вместе - вполне себе ламповые open/use/close. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 14:39 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Alexey MaslovСам столкнулся с подобным явлением, пытаясь добиться обмена двоичными данными между Cache-8-бит и Cache-Unicode через файлы.Кое-что исправили в 2016.2: CDS2714 - Correct I/O translation of variable length records С этим патчем уже можно пробовать мой предыдущий пример ( 19116165 ) для сравнения обоих подходов. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 15:31 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
servitКое-что исправили в 2016.2: CDS2714 - Correct I/O translation of variable length records ... С этим патчем уже можно пробовать мой предыдущий пример ( 19116165 ) для сравнения обоих подходов.Этот патч, судя по всему, решает несколько иную проблему; на эти грабли тоже наступал (знаем, плавали :). Моя ситуация несколько иная: я работаю с файлами, открывая их как "UK\table\", т.е.: - не пользуюсь кашовскими записями (ни "S", ни "V"), организую всё это хозяйство сам; - перекодировку текстовых строк в/из UTF8 тоже делаю сам ($zcvt(...)); - а вот двоичные данные хотел бы передавать как есть (RAW). В таких условиях для передачи файлов между системами с разной "битностью" (8 бит vs Unicode) представляется естественным использовать table="RAW"; ан нет, не работает, хотя бы потому, что Cache-Unicode, как оказалось, пишет в этом случае "?" вместо любого символа с кодом > 127. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 16:01 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Alexey MaslovВ таких условиях для передачи файлов между системами с разной "битностью" (8 бит vs Unicode) представляется естественным использовать table="RAW"; ан нет, не работает, хотя бы потому, что Cache-Unicode, как оказалось, пишет в этом случае "?" вместо любого символа с кодом > 127.Скорее всего дело во внутреннем представлении строки. Если двухбайтную строку предварительно преобразовать в однобайтную, то RAW перестаёт заменять на "?" вместо любого символа с кодом > 127. Например: Код: plaintext 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.
Возможно для Unicode Вам вместо "RAW" подойдёт "SAME"? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2016, 16:56 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
servit , спасибо за BIN - не знал о её существовании - в чём её "физический смысл"? В вашем примере "RAW" применяется к строке, которая уже содержит искажённые данные (замены на "?"). Если тупо сравнивать исходную строку с результатом обратной перекодировки, результат будет иным: write !,$zv,! set s=$zcvt("Cach%E9%20%2B%20%u0437%u0430%u043F%u0440%u043E%u0441%20%2B%20%u0103%EE%u015F%u0163%E2","I","URL") f i="","RAW","BIN","SAME","Unicode","UTF8" s n=$zcvt(s,"O",i) w !,i," : ",s=$zcvt(n,"I",i) zzdump n Cache for Windows (x86-64) 2015.1.4 (Build 803_0_16388U) Fri May 13 2016 15:16:38 EDT : 0 0000: 43 61 63 68 E9 20 2B 20 3F 3F 3F 3F 3F 3F 20 2B Caché + ?????? + 0010: 20 3F EE 3F 3F E2 ?î??â RAW : 0 0000: 43 61 63 68 E9 20 2B 20 3F 3F 3F 3F 3F 3F 20 2B Caché + ?????? + 0010: 20 3F EE 3F 3F E2 ?î??â BIN : 0 0000: 43 61 63 68 E9 20 2B 20 3F 3F 3F 3F 3F 3F 20 2B Caché + ?????? + 0010: 20 3F EE 3F 3F E2 ?î??â SAME : 1 0000: 43 00 61 00 63 00 68 00 E9 00 20 00 2B 00 20 00 C.a.c.h.é. .+. . 0010: 37 04 30 04 3F 04 40 04 3E 04 41 04 20 00 2B 00 7.0.?.@.>.A. .+. 0020: 20 00 03 01 EE 00 5F 01 63 01 E2 00 ...î._.c.â. Unicode : 1 0000: 43 00 61 00 63 00 68 00 E9 00 20 00 2B 00 20 00 C.a.c.h.é. .+. . 0010: 37 04 30 04 3F 04 40 04 3E 04 41 04 20 00 2B 00 7.0.?.@.>.A. .+. 0020: 20 00 03 01 EE 00 5F 01 63 01 E2 00 ...î._.c.â. UTF8 : 1 0000: 43 61 63 68 C3 A9 20 2B 20 D0 B7 D0 B0 D0 BF D1 Caché + Ð·Ð°Ð¿Ñ 0010: 80 D0 BE D1 81 20 2B 20 C4 83 C3 AE C5 9F C5 A3 .оÑ. + Ä.îÅ.Å£ 0020: C3 A2 â ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2016, 11:23 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Alexey MaslovВ вашем примере "RAW" применяется к строке, которая уже содержит искажённые данные (замены на "?")Я знаю. Смысл был в том, чтобы показать, что RAW не портит именно однобайтные строки в какой бы кодировке они ни были . А изначальная строка именно что двухбайтная: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2016, 11:54 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Alexey Maslovспасибо за BIN - не знал о её существовании - в чём её "физический смысл"?Это историческое название для RAW. Оставлено для совместимости с legacy-кодом у некоторых заказчиков. Что касается RAW для Unicode, то мои предположения подтвердились: RAW для перевода двухбайтной строки в однобайтную не подходит . Для максимальной совместимости экспорта/импорта глобалов между 8-битной и Unicode версиями производителем рекомендуется использовать UTF8, который нечувствителен к порядку следования байт (04 37 или 37 04) и экономичнее Unicode. Документация относительно поведения RAW в 8-битной и Unicode версиях будет в скором времени уточнена. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2016, 12:53 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
servit, спасибо за продолжение обсуждения.servitRAW для перевода двухбайтной строки в однобайтную не подходитЭто было ясно изначально (e.g. $char(1040) => $char(63)). Насчёт UTF8 пришёл к тому же выводу: вполне подходит для передачи текстовых данных между 8-bit и Unicode "туда и обратно" (обратно, конечно, с очевидными ограничениями). Двоичные данные проще всего распаковать в текстовые перед передачей и снова запаковать в двоичные после неё. Без такого преобразования возможна лишь передача "чисто двоичных" однобайтных данных в формате RAW, но такая возможность представляет лишь академический интерес, т.к. в составе того или иного глобала почти всегда есть текстовые поля (которые при передаче без перекодировки портятся). На случай, если это обсуждение интересно кому-то ещё, кроме нас двоих: простейший пример смешанных данных - список, e.g. Код: plaintext
Код: plaintext 1. 2.
Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2016, 15:19 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
Alexey MaslovservitW для перевода двухбайтной строки в однобайтную не подходитЭто было ясно изначально (e.g. $char(1040) => $char(63)).Ясно что? Что не подходит согласно дизайну (так изначально задумано) или быть может это просто баг, который нужно исправить? В итоге оказалось что так и было задумано. Поэтому-то документацию обновят, чтобы в дальнейшем не возникало вопросов.Alexey MaslovЕсли передавать в UTF8, испортится заголовок списка (первые 4 байта). Если передавать в RAW, список сохранит корректность, но в неверной кодировке придут данные.У меня на версии Cache for Windows (x86-64) 2016.3 (Build 000U) обе кодировки ничего не портят: Код: Код: plaintext 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.
Результат: Код: plaintext 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2016, 17:06 |
|
Несовместимость кодировок.
|
|||
---|---|---|---|
#18+
servitУ меня на версии Cache for Windows (x86-64) 2016.3 (Build 000U) обе кодировки ничего не портятПравильно, потому что и пишет, и читает - Unicode-версия. Если записать $lb(мой, с длинной кириллической строкой) в Cache 8-бит, а читать в Cache Unicode, вариантов нет - что-нибудь да испортится: либо заголовок элемента списка, либо данные в элементе списка. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2016, 17:24 |
|
|
start [/forum/topic.php?fid=39&fpage=9&tid=1556445]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
78ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 169ms |
0 / 0 |