Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Впервые столкнулся с таким вот глюком.
Допустим, имеем текстовый файл (866 или 1251 - не суть важно) myfile.txt, содержащий разделители TAB. "Бытовая техника" ул. Советская, 10 <TAB> 8-20 Вот такой текст Если выполнить следующие команды:
То получится неожиданный результат. FPD 2.6 почему-то кавычки, в которые взяты слова "Бытовая техника", воспринимает как отдельный реквизит, будто бы отделенный от ул. Советская символом TAB. В VFP не проверял, но, быть может, и там есть такой глюк. Хорошо, что реальный текстовый файл был небольшого размера - меньше мегабайта. Так загнал сначала содержимое файла в memo-поле, потом заменил двойные кавычки на одинарные апосторофы ' , потом опять сбросил в тестовый файл, и уже после этого запустил ранее написанную обработку. Вообще очень странный глюк. Исправлено 4 раз(а). Последнее : Simple777, 22.05.18 19:04 |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
akvvohinc Автор Сообщений: 4203 Откуда: Москва Дата регистрации: 11.11.2008 |
Это не глюк - кавычки как разделители символьных данных имеют приоритет над разделителями полей.
В Help'е это не уточняется, но практика давно показала. Насколько я помню отменить кавычки нельзя, но можно их заменить на другой символ, но тогда разделителями полей может быть только запятая. |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Если это так, то выходит, что нет способа выполнить корректно команду APPEND FROM из текстового файла с любыми разделителями, если какая-нибудь строка будет начинаться с закавыченного наименования, например. И тогда получается, что надо предварительно в текстовом файле заменить двойные кавычки на какие-нибудь другие символы, что само по себе есть нонсенс.
Сейчас не могу проверить, но думаю, что такой эффект с кавычками будет наблюдаться только тогда, когда строка будет начинаться с кавычек. Если кавычки будут встречаться после знаков табуляции (как в данном примере), то никакого приоритета такие двойные кавычки перед символами табуляции иметь не будут. Фактически для корректного считывания текста придется все двойные кавычки заменять на какие-нибудь символы, которых не будет в текстовом файле, а после выполнено команды APPEND FROM сделать обратную замену на двойные кавычки. В текстовом файле, вообще говоря, может быть переменное число разделителей в строке. Иногда приходится обрабатывать и такие "внешние" сторонние файлы. Это я к тому, что нет простого способа выяснить, есть ли строки, которые будут начинаться с закавыченных наименований, например. Исправлено 3 раз(а). Последнее : Simple777, 22.05.18 23:07 |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
akvvohinc Автор Сообщений: 4203 Откуда: Москва Дата регистрации: 11.11.2008 |
Как я уже наисал, заменить кавычки на другой символ можно, но тогда разделителем полей может быть только запятая:
Уверен, что ты ошибаешься - кавычки (если их не отменить) будут действовать в любом месте строки. (я не понял, почему ты написал, что в данном примере кавычки встречаются после табуляции - в твоем примере кавычки идут перед) --------- Ты спрашивал про эту проблему в VFP - там твой пример, видимо, решается такой командой:
В FPD опции WITH CHARACTER нет. Исправлено 1 раз(а). Последнее : akvvohinc, 23.05.18 07:02 |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Да нет же. Сами по себе парные кавычки обрабатываются корректно. Такой глюк возникает только в том случае, если строка начинается с кавычек. В середине реквизитов кавычки "просто кавычки". И я не понял насчет разделителя "запятая". Как обычная запятая может быть разделителем? Может быть речь идет о символе конвейера | ? И вообще не всегда есть возможность выбирать разделители. В моем случае текстовый файл получается посредством копирования данных из стороннего приложения в буфер обмена Windows с последующим считыванием в текстовый файл. Тут есть явный глюк - первые двойные кавычки, имеющие пару в реквизите, интерпретируются как символы разделения. И только в том случае, если эти кавычки будут после символов CHR(13)+CRH(10). |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Это совершенно корректное и документированное поведение. Строковые "поля" в DELIMITED файле заключаются в двойные кавычки. Это для "правильного" файла. Кстати, разделяются они таки запятыми (если не указано иное). Файл где строковые поля не заключены в кавычки - "неправильный", но фокс его тоже может прожевать - лишь бы внутри "полей" не встречались символы заданные для разделителей (запятая по умолчанию, или табулятор как у тебя). Скажем содержимое строки "ааа=ббб"="ввв=ггг=ддд"правильно и полностью загрузится в твою структуру (2 символьных поля) независимо от того какой разделитель (в примере я поставил на его место =) используется - хоть запятая, хоть табулятор хоть | (пайп) Соответственно никакого глюка нет Есть непонимание формата, и особенности работы с "неполноценным" форматом. При этом в принципе невозможно загрузить через DELIMITED "произвольные" данные. Помимо совершенно очевидных проблем с переводом строки внутри поля (нельзя погрузить в поле строку содержащую перевод строки - как ты её не экранируй - всё одно она будет принята фоксом как "конец записи"), есть и проблема с экранирующим текстовые поля символом (двойной кавычкой по умолчанию в VFP, и не настраиваемому вообще в FPD). Да, если само поле не экранировано (не начинается с кавычки, как по идее должно), то кавычка внутри "пройдёт" (но тогда уже не пройдёт символ-разделитель внутри поля), а если оно таки экранировано как положено (т.е. ПЕРВЫМ символом в начале строки или после очередного разделителя будет кавычка), то внутри данных нельзя применять эту самую кавычку - она автоматом будет принята как "конец поля" и всё что после неё уже будет пытаться разбираться как следующие поля. Выход очевиден - так обрабатывать данные при выгрузке, чтобы они были без подобных проблем - естественно что для этого надо иметь доступ к системе создающей эти файлы. Уже созданный "плохой" файл полноценно исправить не получится (по тем же самым причинам по которым и фокс не может его забрать так как ТЫ того хочешь, а забирает так как прописано в алгоритме для файлов DELIMITED формата). По терминологии тоже надо уточнить - кавычка это НЕ разделитель полей, это "ограничитель строковых значений". Хотя да, если пропустить настоящий разделитель, то он "подразумевается" после каждого закрывающего поле ограничителя. ------------------ WBR, Igor |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Если проблема в файле связана только вот с такого рода двойными кавычками, то вполне можно файл обработать так, как я и сделал - сначала загнать файл в memo-поле, потом заменить кавычки на другой символ (думаю, что вполне можно заменять на | или ~), потом выгрузить memo-файл назад в текстовый файл, далее обработать уже без заморочек по APEND FROM mymext deli with TAB. И на завершающем этапе надо будет вернуть на место кавычки по CHRT() или STRT(). Для файлов с небольшими размерами такой алгоритм вполне себе можно считать универсальным. Кстати, сейчас вот даже проверил, как сохраняет тестовый файл Excel, если выбрать формат "Текстовые файлы с разделителями табуляции". Никаких двойных кавычек в тексте не формируется при этом. Что же касаемо двойных парных кавычек, находящихся внутри реквизита, разделенного от других реквизитов TAB, то такие двойные кавычки обрабатываются корректно, если они стоят не сразу после TAB. |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
akvvohinc Автор Сообщений: 4203 Откуда: Москва Дата регистрации: 11.11.2008 |
Не только. Если после Tab будут идти пробелы, а потом что-то в кавычках, то пробелы как часть строки будут проигнорированы, а кавычки воспримутся как строковые ограничители и исчезнут. Ну, и "сдвиг по полям" при этом также обеспечен. PS. Вначале ты написал про начало строки, а не строкового реквизита, поэтому я тебя не понял, когда ответил, что положение закавыченного реквизита неважно. |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Я написал про начало строки, потому что в начале строки это и произошло. Насчет кавычек в других местах - не проверял. Но могу сказать вполне определенно, что взятые в кавычки наименования всегда обрабатывались корректно, где бы они не находились эти самые парные кавычки. И никакого сдвига по полям тоже не было. Это вот впервые за очень много-много лет с таким "феноменом" столкнулся.
|
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
akvvohinc Автор Сообщений: 4203 Откуда: Москва Дата регистрации: 11.11.2008 |
Непонятно. Ты хочешь сказать, что когда-то команда APPEND FROM ... DELIMITED работала иначе, чем сейчас? |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Нет, я хочу сказать, что мне ни разу не попадались двойные кавычки в начале строки в текстовом файле с разделителями TAB. А во всех остальных случаях двойные кавычки, сколько бы их не было, и где бы они не располагались, они обрабатывались корректно. |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Вообще-то оно ВСЕГДА так работало - просто тебе везло и не попадались кавычки в начале поля (не строки - т.е. записи, а каждого из полей в ней).
Пост-обработка не является корректной если в файле есть ИМЕННО закавыченные поля-строки. Кроме того разные системы несколько по разному трактуют формат. Раз уж зашла речь про эксель - ну вот тебе в прицепе простейшая книжка, которая при сохранении в формате "Текстовые файлы с разделителями табуляции" превратися в совершенно неудобоваримое для фокса месиво. Хотя "формально" они вполне себе укладываются в соответствующий "стандарт". Ну и попробуй какой угодно пост-обработкой верни эти данные (те что попадают в txt файл) в изначальный вид ------------------ WBR, Igor |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Да, сейчас провел эксперимент с разным расположением кавычек.
Если кавычки идут первыми в строке или располагаются сразу за знаком табуляции, и потом в реквизите вторые кавычки встречаются где-то в середине, то тогда реквизит "разрезается" на части, и происходит сдвиг по полям. Действительно, мне просто везло, что никогда кавычки не стояли таким вот образом. Это лишь укрепляет в мысли, что такие текстовые файлы надо предварительно обрабатывать на предмет временной замены кавычек на какой-либо другой символ перед выполнением команды APPEND FROM DELIMATED |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Пример посмотрел. Все же редко кто так извращается в Excele.
Обычно там вполне нормальная хорошо структурированная таблица с корректными разделителями. |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
MYTEXT1.TXT "Бытовая техника"ул.Советская 25 8-20 без выходных Бытовая техника"ул.Советская" 25 8-20 без выходных Бытовая техника"ул.Советская" 25 "8"-20 без выходных Бытовая техника"ул.Советская" 25 8-"20" "без" выходных Бытовая техника"ул.Советская" 25 "8-20" "без" выходных MYTABL.DBF Rek1 Rek2 Rek3 Rek4 =========================================================================== Бытовая техника ул.Советская 25 8-20 без выходных Бытовая техника"ул.Советская" 8-20 без выходных Бытовая техника"ул.Советская" 8 -20 без выходных Бытовая техника"ул.Советская" 8-"20" без выходных Бытовая техника"ул.Советская" 8-20 без выходных |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
В общем случае это приведёт к тому что: - в таблицу полезут совершенно ненужные экранирующие кавычки. - если внутри "закавыченного" текста был символ-разделитель, то поле "разрежется" и пойдёт сдвиг всех остальных полей. Если это данные из экселя то всё ещё хуже - помимо того что он экранирует "плохие" текстовые значения, он ещё и удваивает внутри них встреченные кавычки (стандарт рекомендует именно так поступать, но фокс, увы до того писался и этого "не понимает") - т.е. там где в "исходнике" было просто поле с одной кавычкой внутри, после такого рода "загрузки" будет поле с ЧЕТЫРЬМЯ кавычками, ну или если ты обратно не будешь заменять, то апострофами или ещё чем-то временно-подменным - по одной в начале и конце текста, и удвоенная на месте где была одна исходная кавычка. Побороть на самом деле можно это лишь одним способом - в ИСХОДНЫХ данных убрать из текстов переводы строки, а кавычки заменить на те же апострофы. Тогда даже при экранировании a-la эксель фокс всё заберёт нормально. ------------------ WBR, Igor |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
of63 Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
() кратко, Симпле, вот ты придумал предобработку строк, когда в ней двойные кавычки, вот так и продолжай придумывать )
|
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
[attachment 29437 smokie.gif]
|
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Я имел в виду, что предварительно обрабатывать "неправильные кавычки" в FoxPro через memo-поле. Тут единственная трабла - если будет слишком большой текстовый файл. |
Re: Странный глюк APPEND FROM в FPD (в VFP проверять надо) | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Я понял что ты имел в виду И ещё раз говорю - это не поможет от "надёжно испорченного" файла. Вот предварительная обработка ДО формирования такового файла - в том же экселе - это гораздо надёжнее вариант. Макрос намастырить который всё что надо позаменяет и сделает SaveAs не так уж и сложно...
------------------ WBR, Igor |
© 2000-2024 Fox Club  |