Научная запись при импорте из Excel в .Net

Я обнаружил, что самый простой способ - выбрать формат Zip, а не текстовый формат для столбцов с большими «числами».

Вы пробовали преобразовать значение поля в (int) или, возможно, (Int64), когда вы его читаете?

Библиотека OleDb будут чаще всего портит ваши данные в электронной таблице Excel. Это в значительной степени потому, что он заставляет все в макете столбца фиксированного типа, угадывать в типе каждого столбца из значений в первых 8 ячейках в каждом столбце. Если он угадает неправильно, вы получите цепочку цифр, преобразованную в научную нотацию. Блеч!

Чтобы избежать этого, вам лучше пропустить OleDb и прочитать лист самостоятельно. Вы можете сделать это с помощью COM-интерфейса Excel (тоже бесполезно!) Или стороннего .NET Excel-совместимого ридера. Таблица - одна из таких библиотек, которая работает достаточно хорошо и имеет интерфейс, очень похожий на COM-интерфейс Excel.

Найдите параметр строки подключения IMEX = 1 и параметр реестра TypeGuessRows в Google. По правде говоря, нет простого способа обойти это, потому что читатель определяет типы данных столбца, просматривая первые несколько строк (по умолчанию 8). Если строки содержат все числа, вам не повезло.

Неудачный обходной путь, который я использовал в прошлом, - использовать параметр строки подключения HDR = NO и установить для параметра реестра TypeGuessRows значение 1, что заставляет его читать первую строку как допустимые данные для определения своего типа данных, а не заголовок. Это взлом, но он работает. Код считывает первую строку (содержащую заголовок) как текст, а затем соответственно устанавливает тип данных.

Изменение реестра - это боль (и не всегда возможно), но я бы порекомендовал впоследствии восстановить исходное значение.

Если в ваших данных импорта нет строки заголовка, то альтернативным вариантом является предварительная обработка файла и вставка символа 'перед каждым из чисел в неправильном столбце. Это приводит к тому, что данные столбца обрабатываются как текст.

В общем, есть множество уловок, чтобы обойти это, но ничего действительно надежного.

У меня была такая же проблема, но я смог обойти ее, не прибегая к COM-интерфейсу Excel или стороннему программному обеспечению. Это связано с небольшими накладными расходами на обработку, но, похоже, работает для меня.

1. Сначала прочтите данные, чтобы получить имена столбцов
2. Затем создайте новый DataSet с каждым из этих столбцов, установив для каждого из их DataTypes значение string.
3. Прочтите данные еще раз в этот новый набор данных. Вуаля - научный обозначение теперь исчезло, и все читается как строка.

Вот код, который это иллюстрирует, и в качестве дополнительного бонуса это даже StyleCopped!

public void ImportSpreadsheet(string path)
{
    string extendedProperties = "Excel 12.0;HDR=YES;IMEX=1";
    string connectionString = string.Format(
        CultureInfo.CurrentCulture,
        "Provider=Microsoft.ACE.OLEDB.12.0;Data Source = {0};Extended Properties=\"{1}\"",
        path,
        extendedProperties);

    using (OleDbConnection connection = new OleDbConnection(connectionString))
    {
        using (OleDbCommand command = connection.CreateCommand())
        {
            command.CommandText = "SELECT * FROM [Worksheet1$]";
            connection.Open();

            using (OleDbDataAdapter adapter = new OleDbDataAdapter(command))
            using (DataSet columnDataSet = new DataSet())
            using (DataSet dataSet = new DataSet())
            {
                columnDataSet.Locale = CultureInfo.CurrentCulture;
                adapter.Fill(columnDataSet);

                if (columnDataSet.Tables.Count == 1)
                {
                    var worksheet = columnDataSet.Tables[0];

                    // Now that we have a valid worksheet read in, with column names, we can create a
                    // new DataSet with a table that has preset columns that are all of type string.
                    // This fixes a problem where the OLEDB provider is trying to guess the data types
                    // of the cells and strange data appears, such as scientific notation on some cells.
                    dataSet.Tables.Add("WorksheetData");
                    DataTable tempTable = dataSet.Tables[0];

                    foreach (DataColumn column in worksheet.Columns)
                    {
                        tempTable.Columns.Add(column.ColumnName, typeof(string));
                    }

                    adapter.Fill(dataSet, "WorksheetData");

                    if (dataSet.Tables.Count == 1)
                    {
                        worksheet = dataSet.Tables[0];

                        foreach (var row in worksheet.Rows)
                        {
                            // TODO: Consume some data.
                        }
                    }
                }
            }
        }
    }
}

Я погуглил об этом состоянии .. Вот мои шаги решения

• Для файла Excel шаблона

Столбец Excel в формате 1 как текст 2- написать макрос для отключения предупреждений об ошибках для числа -> преобразование текста

  Private Sub Workbook_BeforeClose(Cancel As Boolean)
Application.ErrorCheckingOptions.BackgroundChecking = Ture
End Sub
Private Sub Workbook_Open()
Application.ErrorCheckingOptions.BackgroundChecking = False
End Sub

• О выделенном коде

3- при чтении данных для импорта попробуйте разобрать входящие данные в Int64 или Int32 ....

Одним из способов решения этой проблемы является изменение оператора select вместо SELECT *, сделайте следующее:

"SELECT Format([F1], 'General Number')  From [Sheet1$]"
 -or-
"SELECT Format([F1], \"#####\")  From [Sheet1$]"

Однако это приведет к взрыву, если ваши ячейки содержат более 255 символов, со следующей ошибкой: «Многошаговая операция OLE DB вызвала ошибки. Проверьте каждое значение статуса OLE DB, если доступно. Никакой работы не выполнялось».

К счастью, мой клиент не заботился об ошибке в этом сценарии.

На этой странице также есть много хороших вещей, которые можно попробовать: http://www.dicks-blog.com/archives/2004/06/03/external-data-mixed-data-types/

Если вы посмотрите на фактический файл .XSLX с помощью инструмента повышения производительности Open XML SDK 2.0 (или просто распакуйте файл и просмотрите XML в блокноте), вы увидите, что Excel 2007 фактически хранит необработанные данные в научном формате.

Например, 0,00001 сохраняется как 1.0000000000000001E-5.

<x:c r = "C18" s = "11" xmlns:x = "http://schemas.openxmlformats.org/spreadsheetml/2006/main">
  <x:v>1.0000000000000001E-5</x:v>
</x:c>

Глядя на ячейку в Excel, она отображается как 0,00001 как в ячейке, так и в строке формул. Так что не всегда верно, что OleDB вызывает проблему.

Используя эту строку подключения:

Provider=Microsoft.ACE.OLEDB.12.0; data source = {0}; Extended Properties=\"Excel 12.0;HDR=NO;IMEX=1\"

с Excel 2010 я заметил следующее. Если файл Excel открыт при запуске OLEDB SELECT, вы получите текущую версию ячеек, а не сохраненные значения файла. Кроме того, строковые значения, возвращаемые для длинного числа, десятичного значения и даты, выглядят следующим образом:

5.0130370071e+012
4.08
36808

Если файл не открыт, возвращаются следующие значения:

5013037007084
£4.08
Monday, October 09, 2000

Я получил одно решение откуда-то еще, но оно отлично сработало для меня. Нет необходимости вносить какие-либо изменения в код, просто отформатируйте ячейки столбцов Excel как «Общие» вместо любого другого форматирования, такого как «число» или «текст», тогда даже «Выбрать * из [$ Sheet1]» или «Выбрать имя_столбца из [$ Sheet1] будет читать отлично даже с большими числовыми значениями более 9 цифр