Представлен (http://php.net/archive/2013.php#id2013-09-19-1) корректирующий выпуск интерпретатора языка программирования PHP - 5.5.4, в котором исправлено 17 ошибок (http://www.php.net/ChangeLog-5.php#5.5.4).
Среди изменений:
- В функцию fputcsv() добавлена возможность определения символа экранирования.
- Устранены крахи при манипуляции объектами в cli/apache sap и при использовании zend_error() при сборке с опцией "--enable-dtrace".
- В фильтре кодирования в quoted-printable исправлена некорректное кодирование пробелов. Исправлена неверная установка переменной PHP_BINARY. Устранены проблемы со сборкой в gcc 4.4.
- Устранено переполнение буфера в модуле Datetime.
- Налажено корректная инициализация идентификатора сессии при включенной поддержке защищённых сессий (http://www.opennet.me/opennews/art.shtml?num=37684).URL: http://php.net/archive/2013.php#id2013-09-19-1
Новость: http://www.opennet.me/opennews/art.shtml?num=37954
Господи, когда уж они выпустят PHP 6 !!! :)
И что вам даст эта цифра?
Жду полноценную реализацию юникода
> Жду полноценную реализацию юникодаНеявную? В строках? И как тогда они, по-вашему, будут бинарно-безопасную обработку продолжать соблюдать? Да лесом!
Вон, через функции и так всё отлично и предсказуемо работает.
А я все жду скалярный тайп хинтинг.
Зойчем? Третий питон после перехода на юникод вон как затормозил. Каким бы быстрым алгоритм разбора юникода ни был, он будет заметно медленнее однобайтовых кодировок. Проэтому лучше оставить все как сейчас.
Чегой-та?
А perl обеспечил наилучшую поддержку юникода хрен знает сколько лет назад и никаких тормозов не добавилось. Может не в самом юникоде дело, а в конкретных реализациях? Хотя учитывая ЦА php реализация как в питоне более вероятна.
Поддержка unicode в perl - тот еще костыль.
Она кажется костылем только тем, кто не знает насколько сложной вещью является unicode. Путь объявления всего юникодом хорош для ЦА гвидобейсика, так как наличие нескольких вариантов взрывает им мозг, но не для ЦА perl, которая исповедует противоположные принципы.
что за тупизна?
> Путь объявления всего юникодомс какого перепугу вы решили, что в питоне всё юникод?
> наличие нескольких вариантов взрывает им мозгэто вам взрывает мозг уже само наличие питона.
> ЦА perl, которая исповедует противоположные принципыну и где она с этими принципами? Цитата: "С 2000 года идёт разработка новой (6-й) версии языка" (Википедия)
И вообще, откуда вы знаете, какие принципы исповедует ЦА? Это возможно только если вы === ЦА. В таком случае не завидую перлу.
С идеологией языка можно ознакомится даже не изучая сам язык. Сюрприз? Кстати с тем как развивается язык тоже. Например узнать, что perl6 считается не следующей версией perl, а отдельным языком, причем пропасть между perl и perl6 больше, чем между С и C++ или C++ и D.
> не завидую перлу.Отлично, не хватало ещё чтобы фонаты гвидобейсика ему завидовали и вообще пачкали своими мыслями
> Она кажется костылем только тем, кто не знает насколько сложной вещью является
> unicode.unicode - сложная вещь? или реализация его в перле сложная вещь?
> Путь объявления всего юникодом хорош для ЦА гвидобейсика
не путай питон и джанго.
если для тебя даже юникод сложная вещь, то понятно, почему ты не осилил "гвидобейсик". Работа с юникодом и строками/байтами вообще в питоне самая тривиальная, простая и очевидная из всех ЯП, перечисленных в Википедии http://ru.wikipedia.org/wiki/Язык_программирования в списке "Основные языки программирования".
Если вы не знаете про сложности юникода, то это не значит, что их нет. Другое дело, что подавляющее большинство программистов на эти сложности не натыкается, вот и верят, что юникод это просто. Ответьте себе честно сколько из этого вы знали:Code that assumes roundtrip equality on casefolding, like lc(uc($s)) eq $s or uc(lc($s)) eq $s, is completely broken and wrong. Consider that the uc("σ") and uc("ς") are both "Σ", but lc("Σ") cannot possibly return both of those.
Code that assumes every lowercase code point has a distinct uppercase one, or vice versa, is broken. For example, "ª" is a lowercase letter with no uppercase; whereas both "ᵃ" and "ᴬ" are letters, but they are not lowercase letters; however, they are both lowercase code points without corresponding uppercase versions. Got that? They are not \p{Lowercase_Letter}, despite being both \p{Letter} and \p{Lowercase}.
Code that assumes changing the case doesn’t change the length of the string is broken.
Code that assumes there are only two cases is broken. There’s also titlecase.
Code that assumes that ü has an umlaut is wrong.
А ведь это только малая часть из типичных заблуждений на тему использования unicode.
> Ответьте себе честно сколько из этого вы знали:подозреваю, что дальше он не понял ни слова.
> если для тебя даже юникод сложная вещь, то понятно, почему ты не
> осилил «гвидобейсик».если для тебя юникод — это просто, то понятно, почему тебе так нравится гвидобейсик. я ж говорю: ЦА у гвидобейсика — это недоучки-похаписты, которые стесняются признаться, что пишут на похапэ. вот ты — один из них, например.
> понятно, почему ты не осилил "гвидобейсик"Зачем, если есть руби? там хоть не требуются специальные автоформатирующие редакторы
> Путь объявления всего юникодом хорош для ЦА гвидобейсикаэто в какой версии гвидобейсика?
в версии гвидобейсика 2 - нет
в версии гвидобейсика 3 - нет
об чём речь?
Во второй версии как раз было различие между юникод и байтовыми строками. В третьем все строки стали юникодными. С жалобы на результаты этого и началась эта ветвь дискуссии.
Это не так. И в гб2, и в гб3 есть и unicode, и байтовые строки.Python 2.7.5+ (default, Sep 17 2013, 15:31:50)
[GCC 4.8.1] on linux2>>> a = u'маша'
>>> b = 'маша'
>>> au'\u043c\u0430\u0448\u0430'
>>> b'\xd0\xbc\xd0\xb0\xd1\x88\xd0\xb0'
>>> type (a)<type 'unicode'>
>>> type (b)<type 'str'>
>>> len(a)4
>>> len(b)8
Python 3.3.2+ (default, Sep 18 2013, 11:58:01)
[GCC 4.8.1] on linux>>> a = 'маша'
>>> b = a.encode('utf-8')
>>> bb'\xd0\xbc\xd0\xb0\xd1\x88\xd0\xb0'
>>> a'маша'
>>> len(b)8
>>> len(a)4
>>> type (b)<class 'bytes'>
>>> type (a)<class 'str'>
А вообще
Бейсик не порок, Гвидо не пророк.
>Каким бы быстрым алгоритм разбора юникода ни был, он будет заметно медленнее однобайтовых кодировок.человеки не заметят микросекундные различия. более того, эти микросекундные различия будут слабо заметны даже в профайлере на фоне общей медлительности интерпретатора
Проблема в том, что Python компилируется в байт-код. А PHP парсится каждый раз на лету. И должен работать быстро даже без включения кэша, потому что кэш в PHP - сугубо опциональная функция.
Ты наркоман чтоли? В пхп точно такой же байткод )
Да не, пхп способен работать без байткода, а вы ничего не понимаете!
> слабо заметны даже в профайлере на фоне общей медлительности интерпретатораНу вы все интерпретаторы не равняйте по гвидобейсиковскому.
Кроме того если бы вы были правы, не существовали бы "нативные" либы
Очевидное-невероятное: UTF-8 полностью совместим с ASCII. То есть, текст, закодированный однобайтовым ASCII, до последнего бита идентичен оному в UTF-8.
> Господи, когда уж они выпустят PHP 6им не хватает прямолинейности поттеринга.
mbstring еще не встроен в ядро?substr, strpos, etc ... выглядит ужасно с UTF
>mbstring еще не встроен в ядро?apc, memcache, radis, sphynx, bcmath, ssl, preg, gd и куча всего не встроено в ведро, и чё с этого?
Что мешает собрать из pear/pecl или в вашем случае просто подключить уже имеющийся модуль?
Причём, насколько помню, под M$ mbstring и zip встроены.
>substr, strpos, etc ... выглядит ужасно с UTF
iconv.input_encoding = UTF-8
iconv.internal_encoding = UTF-8
iconv.output_encoding = UTF-8
mbstring.internal_encoding = UTF-8
mbstring.func_overload = 1
default_charset = UTF-8
mbstring.http_output = UTF-8
mbstring.encoding_translation = On
Они выглядят отлично.
Вы по ним хелп читали? Это функции для бинарных строк. Не трогайте их, чем вас не устраивают mb_*?
ждем когда будет нормальный парсер всего этого в LLVM
Комментят типичные php программисты.
> Комментят типичные php программисты.Ну и атипичные вроде тебя и пневмонии