Экспорт в .csv Unicode

[MaTuAc]

Первоначальный я написал в блокноте, сохранил как .txt (UTF-8) и изменил расширение на .csv
Знаете, а это выход, потому что новый файл в блокноте отображается как надо. Открыл в блокноте, пересохранил из него, теперь всё работает.
Единственно, что манагер меня уест за столько манипуляций  Открыть старый файл, указав кодировку — изменить — сохранить его, указав кодировку — открыть в блокноте — сохранить, указав кодировку — только потом загрузить )))) Плешь он мне проест абсолютно точно ))

В любом случае, благодарю.

[Helen]

любопытно, что такого может дописывать/изменять блокнот в сравнении с файлом из OpenOffice.org, что так влияет на импорт?

MaTuAc, можете ли прикрепить оба файла - до блокнота и после - чтобы была возможность сравнить?

[VlhOwn]

У меня исходный prices.csv открывается вполне корректно и в LO 3.4 и в MS Excel 2007. Все "умляуты" отображаются корректно (на мой бестолковый взгляд).

[prof-alex]

Трудность в том, что у M$ есть своё видение мира. Поэтому приблуды имени этой компании приписывают в начале файла "лишние" символы, для того чтобы "угадывать" нужный вид UTF.
Такого больше нигде нет, поэтому другие приложения считают данные сигнатуры частью данных.
В самом Calc'е, а так же программах "понимающих" utf-8, но написанных не в M$ файл будет открываться корректно (за исключением мусора в начале первой ячейки), но необходимо указывать кодировку явно.

Надеюсь иллюстрации понятны?

Если использовать akelpad вместо notepad'а, то можно наблюдать запросы при сохранении на добавление подобных сигнатур.

Если важно добиться большей совместимости с поделками M$ заведите RFE, на предмет выявления и сохранения данных сигнатур.

[вложение удалено Администратором]

[smaharbA]

оно как бы так, конечно так оно, вот только

A: No, a BOM can be used as a signature no matter how the Unicode text is transformed: UTF-16, UTF-8, or UTF-32. The exact bytes comprising the BOM will be whatever the Unicode character U+FEFF is converted into by that transformation format. In that form, the BOM serves to indicate both that it is a Unicode file, and which of the formats it is in. Examples:

Bytes Encoding Form
00 00 FE FF UTF-32, big-endian
FF FE 00 00 UTF-32, little-endian
FE FF UTF-16, big-endian
FF FE UTF-16, little-endian
EF BB BF UTF-8

[Рыбка Рио]

Если смотреть в Geany, между preces.csv и preces_new1.csv есть разница такая:
preces.csv (UTF-8 с BOM, окончания строк CR/LF (Win)),
preces_new1.csv (UTF-8 без BOM, окончания строк LF (Unix))

[smaharbA]

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

[prof-alex]

оно как бы так, конечно так оно, вот только

И? Сказать-то что хотели?

preces_new1.csv (UTF-8 без BOM, окончания строк LF (Unix))

Helen работает в OpenSUSE, так что не вижу криминала в окончаниях строк.

еще советую открыть файл с бомом калком, указать что это утф

Но это не избавит от "мусора" в первой ячейке. Если нужны вычисления, то это будет мешать.

[bormant]

Трудность в том, что у M$ есть своё видение мира. Поэтому приблуды имени этой компании приписывают в начале файла "лишние" символы, для того чтобы "угадывать" нужный вид UTF.

Стандарт Unicode несколько иного мнения на этот счёт, читать про BOM -- byte order mark -- метку порядка байтов. Другое дело, что для UTF-8 он как собаке пятая нога, ибо это однобайтовый поток, а не словный (2 или 4 байтовый), экзотика.

ps. Кстати, по ответу #18 можно однозначно сказать, что не так -- перед UTF-8 BOM была добавлена кавычка 22₁₆.
Отсюда вывод -- использованный для экспорта LibreOffice 3.3.2 не распознаёт UTF-8 BOM и считает его данными.

[prof-alex]

Стандарт Unicode несколько иного мнения на этот счёт, читать про BOM

Но если читать внимательно, то чётко видно, что стандарт здесь не причём (выделение моё):

While Unicode standard allows BOM in UTF-8, it does not require or recommend it. Byte order has no meaning in UTF-8 so a BOM only serves to identify a text stream or file as UTF-8 or that it was converted from another format that has a BOM. Many Windows programs (including Windows Notepad) add BOMs to UTF-8 files by default.

В общем рекомендация одна -- сменить текстовый редактор.

[bormant]

Ну-ну... А как же логика? Давайте прочитаем ещё раз:

standard allows BOM in UTF-8, it does not require or recommend it.

То есть,
1) поскольку стандарт допускает наличие BOM в начале UTF-8 кодированного файла, читатель обязан обрабатывать эту ситуацию корректно, исключая его из потока данных;
2) поскольку стандарт не устанавливает наличие BOM в начале UTF-8 кодированного файла в качестве обязательного или рекомендованного условия, то писатель не обязан его туда помещать.

[prof-alex]

1) поскольку стандарт допускает наличие BOM в начале UTF-8 кодированного файла, читатель обязан обрабатывать эту ситуацию корректно, исключая его из потока данных;

RFC говорит иначе:

It is therefore RECOMMENDED to avoid stripping an initial
  U+FEFF interpreted as a signature without a good reason

Т.е., выбрасывать BOM из начала UTF-8 потока, без разрешения пользователя не рекомендуется.

2) поскольку стандарт не устанавливает наличие BOM в начале UTF-8 кодированного файла в качестве обязательного или рекомендованного условия, то писатель не обязан его туда помещать.

Т.е., M$ немного облажалась, и следует избегать её приложений при обработке данных в UTF-8.

Но, согласен, обработка такого случая, иногда, будет полезна. Однако, нужно помнить, что пользователя нужно будет "анноить" запросами на обработку BOM, так что и ЮИ придётся перекраивать, параметров и фильтров станет больше, и т.д.

[bormant]

RFC говорит иначе:

It is therefore RECOMMENDED to avoid stripping an initial U+FEFF interpreted as a signature without a good reason

Т.е., выбрасывать BOM из начала UTF-8 потока, без разрешения пользователя не рекомендуется.

Насмешили, спасибо.

It is important to understand that the character U+FEFF appearing at any position other than the beginning of a stream MUST be interpreted with the semantics for the zero-width non-breaking space, and MUST NOT be interpreted as a signature.
When interpreted as a signature, the Unicode standard suggests than an initial U+FEFF character may be stripped before processing the text.  Such stripping is necessary in some cases (e.g., when concatenating two strings, because otherwise the resulting string may contain an unintended "ZERO WIDTH NO-BREAK SPACE" at the connection point), but might affect an external process at a different layer (such as a digital signature or a count of the characters) that is relying on the presence of all characters in the stream.  It is therefore RECOMMENDED to avoid stripping an initial U+FEFF interpreted as a signature without a good reason, to ignore it instead of stripping it when appropriate (such as for display) and to strip it only when really necessary.

Важно понимать, что символ в любой, кроме начальной, позиции потока ДОЛЖЕН быть интерпретирован в значении неразрывного пробела нулевой ширины, и НЕ ДОЛЖЕН быть интерпретирован как сигнатура.
Когда интерпретируется как сигнатура, стандарт Юникода говорит о том, что начальный символ U+FEFF может быть отброшен до обработки текста. Такое отбрасывание в некоторых случаях необходимо (например, когда конкатенируются две строки, так как иначе результирующая строка может содержать непредусмотренный неразрывный пробел нулевой ширины в месте конкатенации), но может повлиять на внешние процессы на другом уровне (такие как цифровая подпись или количество символов), которые опираются на наличие всех символов в потоке. Поэтому РЕКОМЕНДУЕТСЯ избегать отбрасывания начального интерпретируемого как сигнатура U+FEFF без достаточных причин, вместо отбрасывания по возможности игнорировать его (например, при отображении) и отбрасывать его только когда это действительно необходимо.


А теперь посмотрим на наш случай. Налицо попадание сигнатуры/маркера в содержимое ячейки -- как раз тот случай, который упомянут как необходимый для отбрасывания. А вот при подсчёте контрольных сумм, цифровых подписей, да, их нужно считать с учётом BOM.

[prof-alex]

Поэтому РЕКОМЕНДУЕТСЯ избегать отбрасывания начального интерпретируемого как сигнатура U+FEFF без достаточных причин, вместо отбрасывания по возможности игнорировать его (например, при отображении) и отбрасывать его только когда это действительно необходимо.

Вот именно, но решить когда и что делать должен человек, а не машина.

Так как сам по себе BOM для UTF-8 не является необходимым (не нужен вообще), многие утилиты его не вставляют, и не отбрасывают, а считают частью данных. Данный символ может оказаться в начале потока по разным причинам, sed, split, tail или head, что угодно может быть использовано для подготовки файла. И вероятность того, что в начале данный символ окажется остаётся ненулевой, именно поэтому решение должен принимать человек, а не программа.

[bormant]

Нет, не поэтому. В английском варианте явно выделил, почему. На более высоком уровне, когда объектом является целый поток (например, подсчёт контрольной суммы), отбрасывание приведёт к ошибкам, поэтому читатель не должен выбрасывать существующий BOM. Но при рассмотрении данных потока, этот стартовый символ ВСЕГДА BOM, и ДОЛЖЕН БЫТЬ ПРОИГНОРИРОВАН, противное приводит к ошибкам (в файле примера BOM оказался внутри строки _"_ + _первое поле_.
Арументы про часть потока -- это про другую семантику, нужен BOM как символ в начале потока -- должен быть продублирован.