16. Самогонщик - 09 Ноября, 2011 - 13:46:50 - перейти к сообщению
интересный факт: кодировка ебсдик используемая на майнфреймах не совпадает с ascii вообще никак, так что счастье, что коды английский символов совпадают во всех кодировках только кажущееся.
17. caballero - 09 Ноября, 2011 - 13:50:11 - перейти к сообщению
Цитата:
но для меня было новостью что в utf-8
кирилица занимает в 2 раза больше чем для латиницы
и почему тогда не так же в win-1251?!
кирилица занимает в 2 раза больше чем для латиницы
и почему тогда не так же в win-1251?!
если вы явно указываете кодировку файла то на символ идет 1 байт
смысл юникода хранить данные разных языков в одном файле или строке
но байта на всех не хватит, поэтому нелатинские символы хранятся в двух и более байтах
Цитата:
Не слышал такого, хотелось бы пруфов именно для php.
значит не программируeте на СИ и тип wchar_t вам не знаком. А PHP на писан именно на нем.
18. Самогонщик - 09 Ноября, 2011 - 13:55:20 - перейти к сообщению
caballero пишет:
Не, только на С++, но там всё зависело от деректив компилятора.значит не программируeте на СИ и тип wchar_t вам не знаком.
http://ru[dot]wikipedia[dot]org/wiki/Широкий_символ
Судя по этому результату быстрого гуления, не всё так просто. По крайней мере это точно не UTF-16.
19. caballero - 09 Ноября, 2011 - 14:07:56 - перейти к сообщению
Как интерпретируется тот или иной тип зависит от компилятора и платформы
в любом случае интернациональные строки хранятся по два байта на символ
как правило это UFT16
так же точно хранит данные Java
в любом случае интернациональные строки хранятся по два байта на символ
как правило это UFT16
так же точно хранит данные Java
20. Мелкий - 09 Ноября, 2011 - 14:25:59 - перейти к сообщению
caballero пишет:
в любом случае интернациональные строки хранятся по два байта на символ
А вот и не по два. UTF же.
http://en[dot]wikipedia[dot]org/wiki/Wide_character
Цитата:
The Microsoft Windows application programming interfaces Win32 and Win64, as well as the Java and .Net Framework platforms, require that wide character variables be defined as 16-bit values, and that characters be encoded using UTF-16 (due to former use of UCS-2), while modern Unix-like systems generally require 32-bit values encoded using UTF-32.
Цитата:
The ISO/IEC C programming language, which generally uses the datatype wchar_t for wide characters, originally defined that wide characters should be 16-bit values under C90 due to historical compatibility reasons. C and C++ compilers that comply with the 10646-1:2000 Unicode standard generally assume 32-bit values.
Ну и так далее. В общем,
Цитата:
The width of wchar_t is compiler-specific
21. caballero - 09 Ноября, 2011 - 14:37:46 - перейти к сообщению
Цитата:
А вот и не по два.
в некоторых компиляторах и платформах может быть 4
Цитата:
The width of wchar_t is compiler-specific
22. Самогонщик - 09 Ноября, 2011 - 16:09:47 - перейти к сообщению
Удовлетворительный ответ о представлении символов в пхп так и не получен.
Аргументы про явы и сишарпы вообще не аргументы
Аргументы про явы и сишарпы вообще не аргументы
23. caballero - 09 Ноября, 2011 - 16:16:51 - перейти к сообщению
представление символдов в PHP - забота разработчиков PHP
Остальным предлагаются функции работы со строками. В частности mb_ функции если речь идет о кодировках
Остальным предлагаются функции работы со строками. В частности mb_ функции если речь идет о кодировках
24. Самогонщик - 09 Ноября, 2011 - 16:29:16 - перейти к сообщению
caballero пишет:
представление символдов в PHP - забота разработчиков PHP
Да ну? А как вот эта цитатка?
caballero пишет:
PHP вообще хранит строчные данные в UTF16
Вообще думать на один уровень абстракции ниже используемой очень полезно.
CODE (C):
скопировать код в буфер обмена
скопировать код в буфер обмена
- BEGIN_EXTERN_C()
- PHPAPI size_t php_strlcpy(char *dst, const char *src, size_t siz);
- END_EXTERN_C()
- BEGIN_EXTERN_C()
- PHPAPI size_t php_strlcat(char *dst, const char *src, size_t siz);
- END_EXTERN_C()
Вот такие вещи я нашёл здесь https://svn.php.net/repository/p...5_3_8/main/php.h тут видно что используются обычные чары. Конечно нужно копать глубже....
Но я считаю что пхп хранит строки одно байтовыми символами, т.к. к строкам возможно обращение как к массиву. В простейшей реализации навигация по такому массиву была бы по символам, а не по байтам. Да, можно кастануть к чар*, но тогда бы появились дыры, т.к. только один байт из двух (четырёх) содержал бы значения, а оставшиеся были пустые. Третий вариант, что они делают умное итерирование по строке пропуская все пустые байты, я отбрасываю как бредовый.