В процессе веб -разработки взаимодействие данных является незаменимым, что требует указания соответствующего формата интерактивных данных, чтобы данные могли передаваться между клиентом и сервером. Обычно существует два типа форматов данных: 1. XML; 2. Json. Вообще говоря, JSON используется для передачи данных. В этой статье представлены несколько проблем, возникающих при преобразовании JSON и объектов в Java и связанных с ним предложений.
Во -первых, у нас есть две концепции для JSON:
JSON Object (javaScript объект, нотация, javaScript объекта). Похоже, это пользовательский бит JavaScript, но он является специфичным для языка и платформы в качестве синтаксиса. Это просто означает, что обычно, когда мы передаем данные на сторону сервера (браузер), мы используем формат JSON, и этот формат используется для представления объектов JavaScript. Он состоит из серии «ключевых значений», таких как {«id»: 1, «name»: «kevin»}, что несколько похоже на то, как хранятся пары клавишных клавиш карты. The JSON object described in Java actually refers to the JSONObject class, which is usually named after this name in each third-party JSONjar package. Различные пакеты JAR имеют немного разные внутренние реализации.
Json String. Преобразование между объектами JSON и строками JSON - это процесс сериализации и десериализации, который похож на сериализацию и десериализацию объектов Java. Передача данных в сети выполняется через строки, или двоичные потоки и т. Д. То есть, когда клиент (браузер) должен передавать данные в формате JSON, строка передается в сеть в настоящее время, а сторона сервера, конечно, также будет иметь строку (тип строки) после получения данных. Иногда необходимо преобразовать строку JSON в объект JSON, а затем выполнить следующую операцию (тип строки преобразуется в тип jsonObject).
Вышеуказанные два понятия в основном проясняют формат данных JSON или также называют синтаксисом JSON. В JAVA есть много пакетов JAN для JSON. Наиболее «обычно используется» - это пакет JAR, предоставляемый «Net.sf.json». Эта статья будет сосредоточена на этом пакете пит. Хотя это яма, он имеет широкий спектр приложений. На самом деле, есть и другие отличные пакеты JSON, такие как Fastjson, которые Alibaba утверждает, что является самым быстрым пакетом JSON, Google GSON и Jackson. Попробуйте использовать пакет "net.sf.json". Мало того, что есть какие -либо ловушки, но и очень старые, настолько старые, что не может загрузить исходный код в идее. Репозиторий Maven показывает, что он был остановлен в версии 2.4 в 2010 году. Давайте поговорим о двух ошибках, которые я уже знаю о «net.sf.json» и о том, как были созданы эти две ошибки.
Пакет JSON PIT в Java - Net.sf.json
1. Когда объекты Java преобразуют объекты JSON, все методы, начинающиеся с GET, будут преобразованы.
Что это означает, например, доступны следующие объекты Java.
Package sfjson; импорт java.util.list;/*** Создан Кевином 2017/12/1. */студент открытого класса {private Int ID; частный список <long> курсы; public int getId () {return id; } public void setId (int id) {this.id = id; } public list <long> getCourseIds () {return CourseIDS; } public void setcourseIds (list <long> courseids) {this.courseids = courseids; } public String getSql () {// Метод для получения операторов SQL в этом классе не имеет соответствующего поля атрибута «Возвращение». Это SQL. »; }}Когда мы конвертируем студенческий объект в объект JSON, мы надеемся, что преобразованный формат JSON должен быть:
{"id": 1, "CourseIDS": [1, 2, 3]}However, the result after the conversion of the JSONObject json = JSONObject.fromObject(student); API есть:
Другими словами, можно догадаться, что «net.sf.json» получает метод, который начинается с публичного модификатора, полученного в объекте Java, и определяет его суффикс как «ключ» объекта JSON, и определяет возвращаемое значение метода, который начинается с Get как «значение» соответствующего ключа. Обратите внимание, что это метод, который начинается с общественного модификатора, и имеет возвратное значение.
Я думаю, что это необоснованное правило обращения. Если я определю метод в объекте Java, и только потому, что этот метод начинается с «Get» и имеет возвратное значение, он будет выставлен? Или он подвергается воздействию консоли передней консоли, когда она возвращается клиенту (браузер)? Автор предусматривает это правило преобразования. Грубая причина, по которой я думаю: поскольку вы определяете его как публичный метод и назвал его Get, он намеренно разоблачает этот метод, чтобы клиент, называемый его, имеет право его получить. Но я все еще думаю, что это необоснованно, и даже я определяю это как ошибку. Мне может быть не разумно определять это, потому что, согласно моему фактическому тесту, не только пакет «net.sf.json» будет преобразован в соответствии с этим правилом, но и Fastjson и Jackson также следуют этому правилу, но Google GSON не конвертирует объекты в JSON в соответствии с этим правилом.
Преобразовать построенный объект студента в объект JSON через jsonObject json = jsonObject.fromObject (студент); и студент, как описано выше. После ввода этого метода перегруженный метод FromObject (Object, jsonConfig) будет продолжаться. В этом перегруженном методе экземпляры будут использоваться для определения того, является ли преобразованный объект объекта, является перечисление, аннотация и другие типы. Эти специальные типы будут иметь специальные методы суждения. Вот обычный объект Java Pojo, поэтому он введет _FromObject (Object, jsonConfig), и в этом методе будут некоторые суждения, и, наконец, объект JSON создается путем вызова defaulbeanProcessing. Этот метод является ключом, и он будет продолжать получать «дескриптор свойства» с помощью метода PropertyUtils.getPropertyDescriptors (Bean). Фактически, он должен получить метод с помощью GET, который инкапсулируется в качестве PropertyDescriptor здесь. Этот класс ученика получит 4, а именно: GetClass, GetId, GetCourseIds, GetSQL.
Фактически, PropertyDescriptor подробно инкапсулируется, и все методы чтения и записи были назначены.
Например, этот метод GetSQL был проанализирован в свойство Descriptor на рисунке выше. Следующее отфильтровано некоторые методы через этот класс. Например, метод GetClass не является методом в POJO, поэтому его не нужно преобразовать в объект JSON. PropertyDescriptor получается через BeanInfo#GetPropertyDescriptors, а BeanInfo получается с помощью нового интросспектора (Beanclass, NULL, use_all_beaninfo) .getbeaninfo (); И тогда вы наконец достигнете следующего метода.
Частный beaninfo getbeaninfo () бросает IntrossectionException {… MethodDescriptor MDS [] = getTargetMethodinfo (); // Этот метод будет вызывать getPublicDeclaredMethods. Вы можете видеть, что он действительно ищет публичные методы, и все публичные методы, включая ожидание и другие недвижимость pds [] = getTargetPropertyInfo (); // Фильтр в соответствии с определенными правилами. Правила фильтрации все в этом методе, который должен выбрать метод, где общедоступный модификатор имеет префикс Get и возвратное значение ...Я кратко проанализировал исходный код net.sf.json и обнаружил, что, как я думаю, конкретный исходный код относительно большой и ограничен в космосе, и его необходимо просмотреть и отслеживать меня.
2. При преобразовании объекта Java в объект JSON ошибка преобразования будет произойдет в списке <dly>
Название не может быть четко объяснено в одном предложении, и я очень уверен, что эта проблема является ошибкой.
Теперь существует json -строка {"id": 1, "CourseIDS": [1,2,3]}, и ее необходимо преобразовать в объект студента, упомянутый выше. В объекте студента есть два поля атрибута типа int и list <long>, что означает, что эта строка JSON следует преобразовать в соответствующий тип данных.
String json = "{/" id/": 1,/" courseids/": [1,2,3]}"; студент -студент = (студент) jsonobject.tobean (jsonobject.fromobject (json), студентПриведенный выше выход должен быть истинным, но, к сожалению, он ложный. Чтобы быть точным, это много времени, но целое число во время выполнения. Следует сказать, что это ловушка, и ни один из трех других пакетов JSON не имеет такой ошибки. Так что я уверен, что это ошибка. Давайте посмотрим, как эта ошибка происходит в net.sf.json. Вам также необходимо сравнить исходный код самостоятельно, чтобы просмотреть его. В то время как я постоянно углублял отладку точки останова, я обнаружил, что, когда Net.sf.json обрабатывал целочисленные данные, я обнаружил этот метод numberUtils#createNumber. Этот класс судит тип данных при извлечении данных из строки. The original intention is to process the number as Long if it has "L" or "l" after it. С этой точки зрения конечный результат должен быть правильным.
case 'L':case 'l': if (dec == null && exp == null && (numeric.charAt(0) == '-' && isDigits(numeric.substring(1)) || isDigits(numeric))) { try { return createLong(numeric); } catch (numberFormateXception var11) {return createBigInteger (numeric); }} else {Throw New NumberFormateXception (str + "не является допустимым номером."); }Действительно, до сих пор net.sf.json точно оценил тип данных через идентификатор после числа. Проблема заключается в том, что после получения этого значения и типа данных его необходимо хранить в jsonObject. Метод jsonutils#Transformnumber существует в процессе хранения. Существование этого метода, по крайней мере, исключительно экстравагантно в текущем представлении.
Общественное статическое число Transformnumber (number input) {if (instanceOf float) {return new Double (input.ToString ()); } else if (instanceOf short) {return new Integer (input.intValue ()); } else if (instanceOf byte) {return new Integer (input.intValue ()); } else {if (instanceOf instanceOf) {long max = new Long (2147483647L); if (input.longvalue () <= max.longvalue () && input.longValue ()> = -2147483648l) {// Даже если исходный тип длинный, до тех пор, пока он находится в пределах целого диапазона, он в конечном итоге будет преобразован в целое число. вернуть новый целый integer (input.intvalue ()); }} return input; }}Приведенный выше код ясно показывает виновника, будь то длинный тип (длинный тип в целочисленном диапазоне), включая байт и короткий, он будет преобразован в целое число. Я не понимаю, в чем смысл этого кода. Точный тип данных должен быть определен на основе букв после числа, и точный тип данных должен быть снова преобразован позже, что приводит к ошибке, упомянутой в начале. Эта проблема почти неизбежна, поэтому лучший способ не использовать ее.
Эти две ловушки были обнаружены случайно. Рекомендуется не использовать пакет JSON net.sf.json, который не поддерживался. Кроме того, пакет Net.sf.json не так строго в проверке формата JSON. Если такой формат - «{" id ": 1," courseids ":" [1,2,3] "}", в остальных трех пакетах будет брошено исключение, но net.sf.json не будет.
В приведенной выше статье подробно обсуждаются подводные камни JSON и передача объектов в Java. Это весь контент, которым я делюсь с вами. Я надеюсь, что это может дать вам ссылку, и я надеюсь, что вы сможете поддержать Wulin.com больше.