Поскольку программисты одержимы индексами на основе 0. Хорошо, это немного более сложно, чем это: это имеет больше смысла, когда Вы работаете с логикой низшего уровня для использования индексации на основе 0. Но в общем и целом, я буду все еще придерживаться своего первого предложения.
С файлом все в порядке. «ANSI as UTF-8» означает, что спецификации нет, но Notepad ++ определенно определил кодировку как UTF-8, анализируя байтовые шаблоны. Я проверил это, создав файл с русским, греческим и польским текстом и сохранив его как UTF-8 без спецификации. Вот оно:
# Russian
Следующая
# Greek
Επόμενη
# Polish
Więcej
Я сделал это в другом редакторе (EditPad Pro) и использовал шестнадцатеричный режим, чтобы убедиться, что спецификации нет. Когда я открыл его в NPP, он показал кодировку как «ANSI as UTF-8», и все символы отображались правильно. Затем, все еще в шестнадцатеричном режиме, я удалил первый байт первого русского символа. Когда я снова открыл его в NPP, он показал кодировку как «ANSI», а части текста, отличные от ASCII, были показаны как mojibake :
; Russian
¡Ð»ÐµÐ´ÑƒÑŽÑ‰Ð°Ñ
; Greek
Επόμενη
; Polish
Więcej
Назад в EditPad, и на этот раз я добавил спецификацию, но не исправил кириллицу. На этот раз NPP сообщила кодировку как «UTF-8», и все отображалось правильно, кроме первого русского символа, как показано ниже. «A1» - это шестнадцатеричное представление того, что должно было быть вторым байтом этого символа в UTF-8. Он был отображен в инвертированной цветовой схеме, чтобы указать на ошибку.
# Russian
A1ледующая
# Greek
Επόμενη
# Polish
Więcej
Подводя итог: при отсутствии спецификации Notepad ++ ищет байты, которые не могут представлять символы ASCII, поскольку их значения больше 127 (или 7F
шестнадцатеричный). Если он обнаруживает какие-либо, но все они соответствуют шаблонам, требуемым UTF-8 , он декодирует файл как UTF-8 и сообщает кодировку в строке состояния как «ANSI как UTF-8».
Но если он найдет хотя бы один байт, который не соответствует строке UTF-8, он декодирует файл как «ANSI», что означает однобайтовую кодировку по умолчанию для базовой платформы. Если бы ваш файл был поврежден, вы бы это увидели.
РЕДАКТИРОВАТЬ: Хотя ваш файл действителен без него, вы можете добавить спецификацию, вручную записав три байта "EF BB BF "
в самом начале файла - но должен быть способ получше. Как вы сейчас создаете контент? Потому что это UTF-8, где где-то есть хотя бы один не-ASCII символ; в противном случае NPP сообщит об этом как «ANSI».
Еще одна возможность, которую следует рассмотреть: если вы имеете какое-либо влияние на процесс, который потребляет ваш CSV-файл, возможно, вы можете настроить его на ожидание UTF-8 без спецификации. Технически, любое программное обеспечение, которое может декодировать UTF-8 с спецификацией, но не без , не работает. Консорциум Unicode фактически не одобряет использование спецификации UTF-8, хотя никто не слушает.
Согласно темам, связанным с Notepad ++ здесь и здесь , «ANSI как UTF-8» обозначает UTF-8 без спецификации, тогда как простой «UTF-8» означает UTF-8 с спецификацией. Так что, возможно, процессу чтения CSV необходима метка порядка байтов , чтобы правильно читать CSV как UTF-8.
Но перед тем, как углубиться в это, убедитесь, что ваш скрипт действительно записывает UTF-8! Когда вы открываете новые CSV-файлы в Notepad ++ (и там написано «ANSI как UTF-8»), все ли «специальные» символы отображаются правильно? Если нет, вам необходимо адаптировать свой сценарий для записи UTF-8, если да, проверьте разницу в спецификации.
Попробуйте также изменить свой PHP-скрипт на UTF-8. Иногда необходимо (несмотря на то, что это можно обойти), чтобы скрипт использовал ту же кодировку данных, что и данные.
Аналогичная проблема: PHP: Взрыв с использованием специальных символов