Информация о сервере (DNS и IP удалены):
cat /proc/version && uname -a && java -version
Linux version 2.6.16.33-xenU (*************) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #2 SMP Wed Aug 15 17:27:36 SAST 2007
Linux ************* *************-xenU #2 SMP Wed Aug 15 17:27:36 SAST 2007 x86_64 x86_64 x86_64 GNU/Linux
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)
У меня есть PHP-код, который читает из файла Excel и сравнивает строки. Он не работает на сервере из-за того, что кажется проблемой локали. Однако на моем локальном компьютере (OSX 10.8.5 Mountain Lion) он работает!
На моем локальном компьютере локаль - en_US.UTF-8. На сервере языковой стандарт был POSIX, но я изменил его на en_US.utf8, так как когда я смотрел на en_US.UTF-8, не было en_US.UTF-8 locale -a (интересно, что список локалей на сервере все в нижнем регистре, но на моем Mac они все в верхнем регистре, отсюда и возникают эти вопросы).
Есть ли разница между ними, которая может повлиять на сравнение строк?
Также, согласно этот пост в SF Я побежал локаль -v -a. На сервере en-US.utf8 использует кодировку UTF-8 (я предполагаю, что это то же самое, что я обычно называю кодировкой?). Однако на моем локальном компьютере я не могу запустить локаль -v -a команда, хотя локаль и locale -a работают нормально.
Редактировать: Связанный вопрос, который я задал на StackOverflow.
en_US.utf8 является не официально признанный регион, так как IANA отсутствует utf8 набор символов название. Однако его видели в дикой природе.
Имя набора символов UTF-8.
Следовательно, все они действительны:
en_US.utf-8en_US.UTF-8en_US.uTf-8Также существует! Чувствительный к регистру! псевдоним для название UTF-8, а именно: csUTF8.
Следовательно, это также будет действительным:
en_US.csUTF8
Но я никогда не видел такого в дикой природе.
UTF-8 допустимый набор символов IANA название, в то время как utf8 не является. Это даже не действительный псевдоним.
POSIX.1-2017, раздел 8.2 Переменные интернационализации говорит:
Если значение локали имеет вид:
language[_territory][.codeset]он относится к языку, предоставленному реализацией, где настройки языка, территории и кодового набора определяются реализацией.
Здесь речь идет о [.codeset] часть, которую не определяет POSIX, но определяет IANA.
Для набора символов, определенного RFC2978: UTF-8, a transformation format of ISO 10646, то Наборы символов IANA перечисляет название так как:
UTF-8
а в примечании вверху говорится:
Это официальные названия наборов символов, которые могут использоваться в Интернете и на которые можно ссылаться в документации Интернета.
An псевдоним csUTF8 предоставляется, о чем RFC2978 Процедуры регистрации кодировки IANA, раздел 2.3 говорит:
Все остальные имена считаются псевдонимами для основного имени, и использование основного имени предпочтительнее использования любого из псевдонимов.
Наборы символов IANA также говорит:
«Cs» обозначает набор символов и предоставляется для приложений, которым требуется первая строчная буква, но после этого они хотят использовать смешанный регистр, который не может содержать никаких специальных символов, таких как подчеркивание («_») и тире («-»).
в cs псевдоним, регистр имеет значение (в то время как имя определено как нечувствительное к регистру, выше).
Учитывая псевдоним csUTF8, en_US.csUTF8 тоже будет действительным, но я никогда не видел такого формата в дикой природе.
Хотя дело имеет значение в псевдонимыотносительно имена, Наборы символов IANA говорит:
Имена наборов символов могут содержать до 40 символов, взятых из печатаемых символов US-ASCII. Однако не делается различий между использованием прописных и строчных букв.
Так что пока en_US.utf-8 действительна (строчная версия перечисленных UTF-8), en_US.utf8 недействителен, так как он отбрасывает -.
Нет разницы. Они одно и то же.