Пользователь
0,0
рейтинг
20 октября 2013 в 21:33

Разработка → PHP JSON был удален из PHP 5.5? перевод

Возможно некоторые из Вас обновив php до версии 5.5 на своих Linux машинах, обнаружили добрую часть своих приложений неработающими по причине фатальной ошибки похожей на эту:

PHP Fatal error: Call to undefined function json_encode()

Почему так произошло читайте в вольном переводе cтатьи «Has PHP JSON been removed in PHP 5.5?»,
под катом.

Что происходит?



Крокфордский (Douglas Crockford) JSON — широко используемый формат обмена данными, оказался в лицензионном конфликте с PHP в Linux дистрибутивах из за строки в лицензионном соглашении первого, которая гласит:

“The Software shall be used for Good, not Evil.”

В этом лицензия JSON не сходится с свободой номер ноль от Фонда Свободного Программного Обеспечения:
“The freedom to run the program for any purpose.”
(программу можно свободно использовать с любой целью)


Хотя это может показаться незначительным, но автор json.org «вежливо» отказывается вносить поправки в лицензию. Ответом стало удаление стандартного PHP расширение JSON в PHP 5.5rc2 в Debian, Fedora, и других дистрибутивах.

До тех пор пока менеджер пакетов вашего Linux дистрибутива не начнет предоставлять json расширение в виде пакета, json-функции могут быть недоступны. Любой код использующий эти стандартные функции приведет к ошибкам:

PHP Fatal error: Call to undefined function json_encode()
PHP Fatal error: Call to undefined function json_decode()

(прим. переводчика: в ubuntu server 13.10 PHP 5.5.3-1ubuntu2 расширение JSON идет отдельным пакетом php5-json)

Решение для тех кого это затронуло


JSON в PHP будет предоставлен другими расширениями в свое время и будем надеяться это будет прозрачно для конечного пользователя, но если вы не хотите ждать с обновлением и вас затронула эта проблема, вы можете установить PECL расширение JSON-C от Реми (jsonc by Remi Collet) которое использует библиотеку json-c.

Мое решение для CentOS 5.9 было в установке PECL JSON-C расширения из репозитория Реми для YUM:
yum --enablerepo=remi install php-pecl-jsonc


Для Дебиан дистрибутивов может оказаться полезным сторонний репозиторий от Ondřej (прим. переводчика: полагаю речь идет об этом)

Если вы установили расширение вручную, не забудьте добавить его в php.ini

Ссылки:
bugs.php.net/bug.php?id=63520
github.com/remicollet/pecl-json-c

Оригинал статьи

www.json.org/license.html
www.gnu.org/philosophy/free-sw.html

От переводчика

Статья датирована девятым августа и не совсем уже актуальна (для свежей убунту например, есть пакет php5-json). Я решил опубликовать этот перевод по двум причинам:
  1. Хочу уведомить тех кого это касается, чтобы не было как у меня. Проапгрейдив свой сервер до Ubuntu 13.10 потратил некоторое время на поиски причины слета части функционала и поиск решения;
  2. Сам повод удаления json из php мне показалась весьма… Интересным, если так можно выразиться. И повод для удаления и факт существования вышеозначенной строки в лицензии на json.org;
Перевод: Iteration 99
@FrEEz10
карма
20,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (105)

  • +12
    В принципе Дуглас прав…
    • +36
      Жаль он забыл опуьбликовать критерии Evil. Я посмотрел, он работает в PayPal, и, возможно, PayPal пользуется этой библиоткой. В этом случае блокировка акаунтов благотворительных акаунтов PayPal без разбора не входит в понятие «evil по Дугласу Крокфорду», и это очень грустно.
      • +6
        Я вообще не согласен с таким определением.

        The Software shall be used for Good, not Evil.


        На сколько я могу судить со своим средним знанием английского «shall» — рекомендательный глагол, а не наказуемый, как «must». То есть это правильно переводится как

        ПО стоит использовать для Добра, а не для Зла


        а не

        ПО должно быть использовано (можеть быть использовано исключительно) для Добра, а не для Зла


        И потому я не согласен и с тем, что «лицензия JSON не сходится с свободой номер ноль».
        • +4
          Вы не правы.

          shall — это приказное слово. То есть автор считает, что ПО должно использоваться в благих целях. Если бы было must — это значило, что автор констатирует факт, что ПО должно использоваться в благих целях, иначе просто никак.

          slovari.yandex.ru/shall/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4/#lingvo/
        • +15
          т.Шок, вы не правы.

          Для MUST, SHALL, SHOULD, etc. есть отдельный RFC: www.ietf.org/rfc/rfc2119.txt
          • 0
            Ну простите, я просто предположил.
          • +5
            Вы меня удивили.
            • +2
              Вот именно поэтому люди категорически не любят объявлять переведённые варианты документов имеющими юридическую силу. Для нормального человека и даже для обычного переводчика SHALL и SHOULD имеют примерно одинаковый смысл, а вот в RFC они сильно отличаются. Теоретически подобные документы должны переводиться «специально натасканными» переводчиками, которые про это знают… но и на старуху бывает проруха.
              • 0
                Если в документе не указана ссылка на этот RFC, то смысл они имеют такой, какой имеют для носителя языка, и никакой RFC никакого юридического значения не имеет. Если указана — то переводчик должен сам внести определение этих терминов.
                • +1
                  Строго формально никакие RFC вообще никакого юридического смысла не имеют — это ведь всего лишь рабочее предложение. Но вы забываете, что в Америке действует прецедентное право, так что достаточно будет этим словам и этому RFC всплыть в некотором количестве судебных процессов — и они начнут трактоваться так, как они трактовались в этом RFC. Или, ещё того хуже, могут начать трактоваться не совсем так, как в RFC.
                  • 0
                    А какое отношение RFC может иметь к типу правовой системы? Привести прецедент с RFC можете, или фантазируете на тему?
                    • 0
                      Скорее фантазия на тему. Но в целом такое может иметь место в прецедентном праве: RFC может быть использован в деле для обоснования той или иной трактовки слова, которая в результате будет иметь влияние на решения дела. Применение судом такого документа автоматически даст ему юридическую силу.

                      Так или иначе, достаточно заглянуть в любой англоязычный толковы словарь чтобы увидеть примерно следующее:

                      shall v. 1) an imperative command as in «you shall not kill.» 2) in some statutes, «shall» is a direction but does not mean mandatory, depending on the context.


                      В английском юридическом языке принято рассматривать shall исключительно как императивную форму, причем высшей степени.
                      • 0
                        Что же, занятная фантазия. Продолжим фантазировать.

                        > [...] Применение судом такого документа автоматически даст ему юридическую силу. [...]

                        Модальные глаголы в подобных документах, сдаётся мне, ничем не отличаются от любых других, определяемых на уровне документа слов. Так, «ПОДРЯДЧИК» из одного документа может кардинальным образом отличаться от «ПОДРЯДЧИК» в другом. И предполагать, что суд будет основываться на определении из RFC, довольно странно: не забывайте, RFC — это даже не стандарт. Вот когда (если) он станет стандартом с комитетом принявшим его, с описанием области применения и ограничений использования — тогда возможно.

                        > [...] Так или иначе, достаточно заглянуть в любой англоязычный толковы словарь чтобы увидеть примерно следующее [...]

                        Таки, если заглянуть в любой, подобного определения вы не найдёте.
          • 0
            Спасибо за RFC! Можно ещё про WILL, WOULD, CAN, COULD, MAY, MIGHT, OUGHT, HAVE TO, BE TO и NEED, пожалуйста?
        • +10
          Exodus 20:13: Thou shalt not kill.

          перевод:

          Исход 20:13: Было бы неплохо, если бы ты никого не убивал

          :)
          • +4
            • +11
              Лучше бы ты не тратил уйму денег на постройку церквей, храмов, мечетей, усыпальниц во имя прославления Моей макаронной благодати, ведь эти деньги лучше потратить — выбирай, на что:

              • на прекращение бедности.
              • на излечение болезней.
              • на мирную жизнь, страстную любовь и снижение стоимости кабельного телевидения.

              Пускай Я и сложноуглеводное всеведущее создание, но Я люблю простые радости жизни. Кому, как не мне, знать? Ведь это Я всё создал.

              Я задумался о переходе в Пастафарианство.
              • +3
                Раминь, брат
        • +2
          Shall — самый сильный из глаголов должествования. Выше приводили пример из библии; могу усилить примером американского УК:
          Whoever knowingly or willfully advocates, abets, advises, or teaches the duty, necessity, desirability, or propriety of overthrowing or destroying the government of the United States [...] Shall be fined under this title or imprisoned not more than twenty years, or both, and shall be ineligible for employment by the United States or any department or agency thereof, for the five years next following his conviction.

          Или, например, из классической поэзии:
          And my soul from out that shadow that lies floating on the floor
          Shall be lifted — nevermore

          Наиболее близкий синоним к shall — is destined to, т.е. shall имеет смысл не только обязательности определённых действий, но и неотвратимости наступления последствий.

          К сожалению, в советско-российской традиции преподавания английского почему-то сложилась безграмотная традиция учить, что shall следует употреблять вместо will в Future Simple от первого лица. От последствий этого тупняка мы все страдаем до сих пор.
          • +2
            Shall очень отличается по силе, в зависимости от того, к какому лицу относится. Thou shalt (второе лицо) — абсолютный императив, I shall — декларация намерения с оттенком долженствования. I shall if you will — обязывает не больше, чем русское «как вы изволите».
          • 0
            К сожалению, в советско-российской традиции преподавания английского почему-то сложилась безграмотная традиция учить [...]

            А чего она вам не угодила? Тем более, что эта советско-российская традиция сформировалась во времена Среднеанглийского %)

            Сейчас сложно вспомнить, но вроде бы в рамках школьной программы, хоть истории языка и не учили, но про употребление shall в качестве глагола должествования упоминали. А нынешние учебники западных издателей посвящают этой теме и того больше.

            Другой вопрос, посвящают ли ученики своё время учебникам ;)
        • +7
          You shall not pass!
          image
          • +1
            «Ты сюда не ходи, ты туда ходи. А то спелл башка попадет — совсем мертвый будешь».
        • –1
          Вы путаете SHALL с SHOULD.
          • –1
            PS. Хотя последнее тоже в разных контекстах может иметь разный оттенок.
      • 0
        Инстересно, знает ли автор, что как показано в «Алгебре совести» основателя исчислимой психофеноменологии В.А. Лефевра, «зло, осознающее себя злом, есть добро», причем как для первой, так и для второй этической системы?
  • +43
    Маразм крепчал…
    • +3
      У меня впечатление, что с каждым годом маразма все больше. Как качественно, так и количественно.
    • +1
      Представляю себе картину: Получает Дуглас письмо по поводу лицензии, в письме ему пишут, что вопросы бога и дьявола — это вопросы скорее философского характера и им вроде как не место в лицензионном соглашении на по\спецификацию\и т.п.

      А он читает такой и думает, «Это все от лукавого..! Бог просто меня испытывает..! Нельзя, нельзя поддаваться, как бы убедительно ни звучали их аргументы… Покайтесь, грешники!»
  • +15
    Не хватает трактовки «good» и «evil» в лицензии.
    • 0
      Ага. Не хватает. Без этого определения это требование никак нельзя трактовать. Пожалуй, то, что оно конфликтует с определением free software от FSF, это единственное что можно точно сказать. Эдинственное что даёт это требование — несовместимость с FSF.
  • 0
    Что одному, что другому документу явно не один год. Где же они раньше-то были?
    • +5
      Кто-то решил напомнить о себе на фоне копирайтинговых войн
  • +5
    Только в 5.4 добавили JSON_UNESCAPED_UNICODE, из-за отсутствия которого многие писали свои велосипеды, вместо использования json_encode. А тут на те, да и еще с такими причинами.
  • 0
    Я в упор не вижу на json.org никаких лицензий. Где именно она находится?
    • +1
      www.json.org/license.html
      Но где на неё ссылка напрямую с www.json.org я тоже не нашёл.
      • 0
        Лицензия про software, на главной json.org про него почти ничего не написано. Ссылка на лицензию есть, например, здесь.
  • +7
    Прочитал, посмотрел в календарь. Нет, вроде не 1 апреля…
  • +3
    Бардак
  • +10
    Как малые дети, «не играй в мои игрушки, не садись на мой горшок».

    P.S. Перводчик:
    Проапгрейдив свой сервер до Ubuntu 13.10

    Скажите, что это был тестовый сервер как раз на случай проверки, как будут работать обновления.
    • 0
      Не боевой ну конечно
      • +2
        Ваш ответ не понятен. Так как у вас нет запятой перед «ну», не понятно, должна ли быть запятая после «не».
        • 0
          Извините ) Я хотел сказать, что сервер не боевой. Просто сервер, для тестирования и вспомогательных, не ответственных проектов.
          • –5
            Хотел заметить, что странно видеть на сервере убунту, да ещё и не-LTS, да ещё и промежуточный нестабильный релиз .10
            • –1
              А что особенно удивительно, серверная убунту, по логике вещей, стабильнее чем десктопная.
              Но все, безусловно, согласны, что на сервере её видеть, ну и впрямь, странно.
              • +3
                Не вижу ничего странного. Особенно в случае с LTS.
                • +1
                  не, речь про .10
                • +9
                  +1, периодически наблюдаю её у клиентов.
                  Как по мне — странно — это когда на сервере винда, а на ней десяток сайтов на PHP, и все это под IIS.
                  • 0
                    Давно такого не видел. Не, чтобы апач на винде стоял — видел, требовал один разработчик ПО для определённой фичи. Но это не публичный веб, а API-сервис к БД MSSQL.
                    • 0
                      Эм, а в чем проблема подключаться к базе из ubuntu?
                      • 0
                        Не знаю, мне выдали екзешник, сказали — вот настройки. В убунте заработает?
                        • 0
                          Мы же про сайты на РНР говорим?
                          • 0
                            Да, возможно я неправ, сменил тему. Хотел привести пример, что апач на винде иногда бывает нужен по причинам, не зависящим от администратора.
            • +6
              Ну про не-LTS понятно, но чем вам в принципе Ubuntu на сервере не угодила? Вполне, по моему опыту, распространенное явление сейчас.
              • 0
                Так и винда вполне распространённое явление, в том числе там, где не нужна. Вон, у нас в городе висят на остановках такие экраны «когда придёт автобус» (нихрена не работает, как обычно, распилили) — там винда, иногда можно разглядеть характерные «память не может быть read». А по сути там должен был быть браузер на весь экран с обновлением информации об автобусах через XHR/JSON — стоимость клиентского ПО и оборудования была бы на порядки ниже, будь там линукс, а поддержка такой системы проще (по ssh, можно и через GPRS подключать).

                Что касается убунты на серверах — ну так а почему не дебиан тогда? Серьёзно, эксплуатировал на серверах убунту сервер и дебиан, с последним как-то более гладко всё.
                • 0
                  Ставил на VDS для своих сайтиков убунту только потому, что дома и на работе стоит Ubuntu и под нее я уже поднимал lamp, а под debian — нет (хотя возможно там все 1 в 1).
                  • 0
                    Ну, не всё там 1 в 1, но если вы именно LAMP ставили и именно потому, что «как дома», то да, скорее всего для вас различий не будет.
                • 0
                  Вы так говорите как будто это что-то плохое :)
                  Если серьезно, то то, что дистрибутив линукса популярен не значит, что он плох, в том числе и для сервера.
                  У этого есть свои достоинства. Да меньше стабильность, но лучше поддержка, свежее версии ПО и т.д. Лично я выбрал убунту потому, что у меня на десктопе убунту, я хорошо с ней знаком, её стабильности для моих задач хватает более чем, я всегда имею достаточно свежие версии ПО и т.д.
                  Недавно вот наши клиенты обновили весь свой серверный парк на Ubuntu Server с CentOS. Как я понимаю такое обновление это хорошие деньги и раз они пошли на это, значит считали, что бонусы от перехода на Ubuntu того стоят.
                  • 0
                    Вот есть HP. Он официально поддерживает (на серверах) RHEL, SLES и Debian. Бесплатный из них один — последний. Убунты в списке нет вообще. Конечно, работать всё скорее всего будет и в убунте, и даже если вы там соберёте арч, но если не будет, и вам потребуется производителю что-то доказать, что вы будете делать?
                    • 0
                      Вы исходите из каких-то своих собственных соображений которые к моим реалиям не имеют отношения. Я пользуюсь Убунту с 2007 или 8-го года и насколько я помню, ни разу не сталкивался с проблемой поддержки железа.
                      • 0
                        Я сталкивался как минимум с заменой неисправного железа (материнская плата HP ProLiant ML370 G5). Угадаете, какой мне задали первый вопрос? :)
        • 0
          $155, примечание 2: «Следует различать употребление одних и тех же слов и оборотов то в качестве вводных (и, следовательно, выделяемых запятыми), то в качестве усилительных (и запятыми не выделяемых).» therules.ru/comma-9/

          Здесь «конечно» усилительное и не обособляется, так что комментарий однозначен.
  • –5
    Да уж теперь вот задумываюсь, а есть ли смысл с 5.4 на 5.5 переезжать…
  • +4
    Никто из самого php json не удалял. Проверил в 5.5.5. Скачайте пакет исходников и посмотрите сами. Удалено в некоторых бинарных дистрах.
    • 0
      Никто и не писал, что из php удалили
      … оказался в лицензионном конфликте с PHP в Linux дистрибутивах…
      Ответом стало удаление стандартного PHP расширение JSON в PHP 5.5rc2 в Debian, Fedora, и других дистрибутивах
      • 0
        То-есть конечно-же из php но не везде.
      • 0
        Ну во-1, заголовок.
        Во-2, «оказался в лицензионном конфликте с PHP в Linux дистрибутивах»: в лицензионном конфликте не с php, а с некоторыми линукс дистрибутивами.
  • +19
    Красноглазые сектанты.
  • +1
    Меня вот ещё один пункт в этой «войне» интересует. Сколько хостингов поставят дополнение для JSON'a и сколько конечных проектов может пострадать при переходе хостера на РНР 5.5? Чуствую будет несколько драматично…
    • +1
      У меня несколько месяцев назад был вопрос с GoDaddy. Клиент пожаловался на неработающий код. Код был написан на php5.4. У GoDaddy декларировался тоже 5.4. А вот когда уже по функциям проверил, оказалось, стоит 5.2. Так что нескоро это будет, если будет вообще.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Вот phpinfo() как раз и показала 5.4, но не работала __DIR__.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Не знаю, в чем там было дело. Скорее всего, у них php собственной компиляции, потому что еще кое-что было подрезано. Сейчас уже не помню точно. Факт в том, что приходится это учитывать при разработке. А это бывает накладно. Особенно, когда это выясняется на стадии сдачи работы.
              • 0
                Простейший чекер нужных модулей сделать?
                • 0
                  Да какой там чекер :) Плагин немножко хитрого авторизованного доступа к постам и отладка чужого коммерческого плагина… И, как обычно, все нужно вчера. И, как всегда, «там работы на 5 минут»… Elance, сэр!
    • НЛО прилетело и опубликовало эту надпись здесь
    • –1
      Если хостеры вменяемые и проблема потенциально аффектит много клиентов — поставят быстро.
  • 0
    В арче все работает. Посмотрел пакеты Debian unstable — php5-ison идет отдельно в рекомендованных.
    Кому-то будет подарок. Но, думаю, годков через 4, наверное, не раньше. А до того времени, либо «ишак сдохнет, либо эмир умрет… ». Или решится вопрос с лицензией.
    • 0
      То, что в поле DEB пакета «Recommends» — ставится по умолчанию. Туда вписыватся всё, без чего программа ну хоть как-нибудь работоспособна.
  • +26
    Да стормозили чё-то. Надо было этот JSON-модуль засунуть в блок
    #ifndef THIS_APP_IS_FOR_EVIL
    ...JSON...
    #endif
    
    и в документации написать, мол «если ваше ПО для Зла — определите, пожалуйста, дефайн THIS_APP_IS_FOR_EVIL и теперь вам будет недоступен JSON», и кому надо — определяли бы себе.
    • +1
      Ну если debian его в бинарных пакетах использует, и поставит этот флаг, значит нарушит собственную лицензию.
  • +2
    Я так понял, в FreeBSD с этим JSON все еще хуже будет?
  • +1
    Причина какая-то дурацкая. Когда же уже наконец кончится это копирайтное безумие…
    • 0
      да тут даже не копирайт, а одна строчка в лицензии
    • +2
      Оно только начинается — столлман сейчас многих кусает :)
      Это не копирастическое безумие это лицензионный анонизм
  • –4
    Пехапе-проблемы.jpg
  • +1
    Непонятно, это лицензия на формат? Или на конкретную библиотеку?
  • +1
    Идиоты.
  • 0
    Понятно лицензия плохая. Но что мешало молча поставить парсер под другой лицензией? В ПХП частенько, что то меняют и все перестает работать.

    JSON еще от куда то убрали или только из ПХП? питон без json,…
    • 0
      насчет питона хм… я с питона отправлял данные в формате json и парсил приходящие
  • 0
    а можно сделать платный форк json, который можно использовать во имя зла?
    • 0
      Форк — нельзя, лицензия не позволит, нужно заново писать.
  • 0
    На убунте 12.04 пакет php5-json в связке с php5 от Ondřej работает иначе, чем раньше. Тексты на кириллице ни с того ни с сего выдают ошибку при json_encode. Пришлось возвращаться на 5.4 от того же Ondřej.
  • –1
    Следующим шагом будет отказ или призыв к отказу от хорошо известных денежных знаков с хорошо известной надписью?
  • +1
    теперь из за них придется сервер переделывать… мда… мой сервер на JAVA общается с php только json данными… а теперь надо какие то обходные пути делать, совсем мозги потеряли они
    • 0
      Т.е. ваш сервер JAVA и php используются для зла и с этими мыслями вы ещё и лицензии соблюдаете? Не быть вам тёмным властелином!
      • 0
        Lawful evil — вполне валидный, и довольно интересный алайнмент. В том числе и для тёмного властелина.
  • 0
    Спасибо тебе, добрый человек. Ты не только сэкономил мне несколько часов ковыряния в том, в чем мне не нужно бы ковыряться. Но и дал отличный повод для шуток в виде конфликта строк лицензий. Спасибо!
    • 0
      You are welcome!
  • –3
    Простите если задену чьи то чувства, но автор редкостный мудак. Его принципиальная «доброта» принесла всем обозы зла! Просто накипело…

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.