- 1
- 2
- 3
- 4
foreach ($account->lists as $list) {
print "LIST Name: " . $list->name; echo ' '; echo ' '; echo ' '; print "LIST Id: " . $list->id;
echo "<br>";
}-
PHP / Говнокод #17085
+157
Не говоря о том, что особой разницы между print и echo в ПХП нет, стоит отметить, что после «nbsp» пропущены точки с запятыми и всё тело этого фора можно было бы вывести одной строчкой.
Запостил:
KEKC,
08 Ноября 2014
Follow us!
Вот же ваши точки с запятыми. Видимо, вам всё мало, да мало...
> echo (в отличии от других языковых конструкций) не ведет себя как функция, поэтому не всегда может быть использована в контексте функции
> В отличии от print, конечно же. Хотя оное, также считается конструкцией
А вам завидно? :)
Кого-то не нравятся кортежи в питоне?
| НЕТ | anonimb84a2f6fd141, 26 июля 2013
|аватара|
Там ещё комментарии были весёлые: https://archive.today/2z51Q
Но перевёрстывать это, да ещё и с текстовыми представлениями аватаров мне лень.
Во втором случае скобки "забрали" 1+2 как аргумент print.
Неправда! Один перевод строки после ?> парсер срезает. Хотя... может быть это только в новых пыхах так.
BOM мешал гораздо сильнее.
На самом деле пых это плохой шаблонизатор. Писать логику на плохом шаблонизаторе это всегда глупо.
Ну про BOM: у Вас пыхскрипты в уникоде были?
Если я и пишу скрипты на пыхе - само-собой они всегда в utf-8. Поэтому и залетел на BOM в своё время, из-за какого-то из виндовых редакторов.
Но педивикия говорит что бывает и для утф:
В моих UTF его нет
А не понимать его, и показывать как мусор - согласен, мудачьё.
Что я делаю не так?
http://postimg.org/image/6v2w7wrqn/
Первые 3 байта -- утфовый бом.
Вроде как все работает
Ну, вообще говоря, он для всех представлений юникода допустим. И как раз таки позволяет их отличить друг от друга.
Имено по-этому я и думал что UTF-8 не бывает с BOM.
Я знал только 4 вида бома:
Unicode 16: BE
Unicode 16: LE
Unicode 32: BE
Unicode 32: LE
Такой вот я ламер
А ещё некоторый софт путает UCS-2 с UTF-16.
В RFC было две вореции спецификации UTF-8: полный диапазон (максимум шесть байтов в UTF-8) и урезанный (максимум четыре байта в UTF-8).
Мистер Мускул внёс ещё одну неожиданность: utf8 в декодированном виде у него занимает 24 бита, а то, что декодируется в 32 бита (в полноценный UCS-4) в нём зовётся utf8mb4, чтобы не было скучно.
Это одна фича. А там еще вторая есть - это фактически utf-8 over ucs-2 (юникодный символ может занимать более одного 16-битного жабьего чара, но каждый чар кодирутся в utf-8 отдельно).
А разве это (когда для некоторых символов используются суррогаты из нескольких 16-битных чаров) не UTF-16?
В таком случае жабья кодировка modified utf-8 — это и есть CESU-8, но только с дополнительным костылём для замены нулевого символа на ненулевой.
https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8
In normal usage, the Java programming language supports standard UTF-8 when reading and writing strings through InputStreamReader and OutputStreamWriter. However it uses Modified UTF-8 for object serialization, for the Java Native Interface, and for embedding constant strings in class files.
The dex format defined by Dalvik also uses the same modified UTF-8 to represent string values.
Ну а для чего еще? Эти злоебучие asciiz строки куда только не протащили.