Bug 100899 - CSV column type defaults to "Standard"
Summary: CSV column type defaults to "Standard"
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-13 18:39 UTC by Александр Бодров
Modified: 2016-11-03 15:05 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Libreoffice langolier zero (1.97 MB, video/mp4)
2016-07-13 18:39 UTC, Александр Бодров
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Александр Бодров 2016-07-13 18:39:04 UTC
Created attachment 126198 [details]
Libreoffice langolier zero

Сделайте уже ради бога корректное открытие файлов CSV. Им сейчас пользуются в основном только для импорта данных из баз данных (в моем случае интернет-магазина), где есть артикулы, штрих-коды и прочие цифры, которые начинаются с НУЛЯ. LibreOffice по-умолчанию их убирает, это делает тип данных "СТАНДАРТ".
Разве может быть нормальным то, что ваша программа искажает данные, которые открывает? 
Может сделаете фикс, хак, настройку, да что угодно чтобы данные открывались как тип "ТЕКСТ"?
Comment 1 David Tardon 2016-07-14 08:02:18 UTC
(In reply to Александр Бодров from comment #0)
> Сделайте уже ради бога корректное открытие файлов CSV.

Obviously here you don't mean "correct", but "as I want it". Because "correct" implies that there is a standard, defined way to import a CSV file--well, there isn't.

> Им сейчас пользуются
> в основном только для импорта данных из баз данных (в моем случае
> интернет-магазина),

That's where you're wrong. CSV is used for transfer of all sorts of data, e.g., numerical.

> где есть артикулы, штрих-коды и прочие цифры, которые
> начинаются с НУЛЯ. LibreOffice по-умолчанию их убирает, это делает тип
> данных "СТАНДАРТ".

It is the other way around: the default type of all imported columns of a CSV file is "Standard", which enables Calc's type detection, so, consequently, numbers are treated as numbers.

> Разве может быть нормальным то, что ваша программа искажает данные, которые
> открывает? 

CSV doesn't contain any information about the actual type of a column. So if you don't tell it explicitly, this is the best we can do to cover the majority of use cases.

> Может сделаете фикс, хак, настройку, да что угодно чтобы данные открывались
> как тип "ТЕКСТ"?

No. Because that would break other use cases.
Comment 2 Александр Бодров 2016-07-14 13:53:17 UTC
Не хочу разводить демагогию. Я вижу что вас обучили не реагировать до последнего, и это понятно - софт бесплатный, программистов наверно единицы. Подскажите где мне могут помочь решить данную проблему за деньги?
Нужно просто сделать так чтобы все поля открывались с типом "ТЕКСТ".

P.S. Я не знаю никого, кто бы использовал формат CSV кроме как для работы с базой данных. Это в основном базы данных программ и сайтов, и все они чаще содержат штрих-коды и артикулы, чем нет. Поэтому с большинством файлов происходит при каждом открытии одна и та же операция только для того, чтобы файл открыл данные нормально. Странно тогда что настройки кодировки и полей сохраняются. Откатите все назад, и без этого файл откроют. Я думаю что проблема в том, что первоначально программу писали те, кто сами ей пользовались. А теперь это не так.
Comment 3 Roman Kuznetsov 2016-11-02 19:28:37 UTC
(In reply to Александр Бодров from comment #2)
> Не хочу разводить демагогию. Я вижу что вас обучили не реагировать до
> последнего, и это понятно - софт бесплатный, программистов наверно единицы.
> Подскажите где мне могут помочь решить данную проблему за деньги?
> Нужно просто сделать так чтобы все поля открывались с типом "ТЕКСТ".
> 
> P.S. Я не знаю никого, кто бы использовал формат CSV кроме как для работы с
> базой данных. Это в основном базы данных программ и сайтов, и все они чаще
> содержат штрих-коды и артикулы, чем нет. Поэтому с большинством файлов
> происходит при каждом открытии одна и та же операция только для того, чтобы
> файл открыл данные нормально. Странно тогда что настройки кодировки и полей
> сохраняются. Откатите все назад, и без этого файл откроют. Я думаю что
> проблема в том, что первоначально программу писали те, кто сами ей
> пользовались. А теперь это не так.

Александр, добрый вечер. Убедительная просьба писать в багзилле проекта на английском и при этом не фонтанировать эмоциями. Вы таким образом никому ничего не докажете, а только отвратите от себя людей, которые возможно хотели бы Вам помочь. А теперь по существу:

1. Программистов действительно мало
2. За деньги Вам может быть решат эту проблему, я попробую выяснить захочет ли кто-то это делать и сколько это будет стоить
3. Тема про импорт CSV с сохранением нулей поднималась на нашем форуме http://forumooo.ru надо ее поискать
Comment 4 Buovjaga 2016-11-02 20:24:56 UTC
Let's set status to unconfirmed until money and a proper solution arrives. Changes must not break the current CSV experience or there will be riots in the streets.
Comment 5 tagezi 2016-11-03 00:37:12 UTC
(In reply to Александр Бодров from comment #0)
> Created attachment 126198 [details]
> Libreoffice langolier zero
> 
> Сделайте уже ради бога корректное открытие файлов CSV. Им сейчас пользуются
> в основном только для импорта данных из баз данных (в моем случае
> интернет-магазина), где есть артикулы, штрих-коды и прочие цифры, которые
> начинаются с НУЛЯ. LibreOffice по-умолчанию их убирает, это делает тип
> данных "СТАНДАРТ".
> Разве может быть нормальным то, что ваша программа искажает данные, которые
> открывает? 
> Может сделаете фикс, хак, настройку, да что угодно чтобы данные открывались
> как тип "ТЕКСТ"?

This problem can not be resolved trivial.
Firstly, there are engineering programs and methods of number storage in databases of when leading zeros are preferred, but a field in the CSV can not recognize they as a text.
On the other hand, there are phone numbers and bar codes in which the symbol of zero as the first symbol may be used.
The standard (in fact there is no standard, there are recommendations) does not give clear guidance how to recognize a text field in a CSV file.
But there is a rule for the use of a separator in the text field that can be extended to any a text field without any complications to read the file.
If a separator is found inside a text field, this field must be enclosed in quotes.
Thus the problem of recognition of the text fields can be solved.
There are four ways to solve this problem.
1. The first way you shown in the attachment.
2. The second way, all fields to enclose in quotes when you export from the database.
3. The third way, suggest the improvement for the enhancement of special numbers for the import the field with a leading zero as text.
4. The fourth way to create a import macro that will automatically result in all the fields in the text format.

Automatic detection into all cases of fields with leading zeros as text is harmful, and we will get the bug reports that will ask us to correct it.

But there is another problem. Calc can display leading zeroes in numbers and export these leading zeros in the CSV file. But when importation occurs back, he did not recreates format with leading zeros. But this again is an enhancement, but not a bug.

I put the "for all operating systems" because it does not depend on the system, "enhancement" because it is improvement, and NEEDINFO because it requires clarification that a developer will improve.
Comment 6 Mike Kaganski 2016-11-03 15:05:22 UTC
As to documentation, specifically about using CSV on the WEB (where Internet stores use case apply), you may refer to https://www.w3.org/standards/techs/csv.

There you may see that *if* there's a requirement specific to some task to keep leading zeros, it's up to (web) application *that knows that specifics* to take appropriate measures for that: https://www.w3.org/TR/2016/NOTE-tabular-data-primer-20160225/#number-precision

So it's OK for a general-purpose application like LibreOffice to use duck test and treat things that look like numbers as numbers by default.

It wasn't too difficult for you to use existing features to import the data as you prefer. Otherwise, the result of importing that data as numbers is not "corruption", because the numbers are imported properly and may be displayed and saved with required precision (thus restoring leading zeros). For specific needs you may use specially tailored macros.

Closing as WONTFIX again.