Проблема у наступному.
На сторінці розміщено деякий аплет, а також інтерфейс для керування ним, написаний на HTML + JavaScript. Потрібно визначити JavaScript, що аплет завантажений і готовий до роботи. Рішення має бути гранично надійним - крос-броузерним, що нормально реагує на повільний Інтернет і т.п.
Коментую. Поки аплет не завантажився, звернення з JavaScript до його public-методів та/або полів загрожує появою дуже негарного повідомлення приблизно такого змісту: "Цей метод відсутній". А аплет часом завантажується набагато довше, ніж сама сторінка. Більше того, деякі речі іноді має сенс зробити автоматично (з JavaScript), як тільки аплет завантажиться – скажімо, подати йому деяку команду.
Тут проблема не стільки в тому, що немає способу перевірити, що аплет вже завантажився, скільки вдосталь таких способів. Наприклад: onload у аплету, onload у сторінки, звернення до методу або полю аплета, "активне" інформування сторінки про завантаженість аплету спеціальним Java-кодом зсередини самого аплету, і т.д. А впевненості, що ці способи працюватимуть:
на всіх можливих броузерах,
при всіх налаштуваннях Security у броузерах,
у поєднанні з усіма можливими платформами,
з усіма JRE,
у мене немає. І здобути таку впевненість майже нереально: надто багато комбінацій.
Гірше тогоТут, здається, дуже легко "перемудрити". Наприклад, я вчора довго "боровся" з помилкою - на чужому комп'ютері (XP+ MSIE +Java2) JavaScript помилково вважав, що аплет не завантажений, хоча у мене на комп'ютері все було гаразд. Підозрюю, річ у тому, що я тоді використав для перевірки доступності звернення до якоїсь public-змінної аплети (не методу!). Всі броузери на моєму комп'ютері (теж XP) при зверненні до такої змінної недозавантаженого аплета повертають null, а як тільки аплет завантажиться – повертають її значення. (На відміну від цього, звернення до методу недозавантаженого аплета видає помилку.) Боюся, що на чужому комп'ютері броузер відмовився зчитувати public-змінну. Доступ до змінних - взагалі неочевидна річ, що працює по-різному з-під різних броузерів та JRE. Надійний лише виклик методів, але лише коли аплет завантажений.
Поки що я написав наступну паруфункцій:
Function showMyErrorMessage(msg,url,line) ( if (window.errorMessage != null) alert(window.errorMessage); window.onerror = window.onerrorSave; return true; ) function getApp(name,notShowMessage null; var a = "Error while accessing applet information for the \"" + name + "\" Java applet."; var b = "Maybe, this applet is not correctly loaded.Please try to reload this page."; if (notShowMessage==null || !notShowMessage) (window.errorMessage = a + b; ) ("document."+name); var appInfo = app == null? null: app.getAppletInfo(); window.onerror = onerrorSave; if (app == null || appInfo == null) ( if (window.errorMessage != null) ( if (app == null) alert("Cannot access \"" + name + "\" Java applet." + b); else alert("Cannot access applet information for the \"" + name + "\" Java applet." + b); ) return null; ) return app; )
Використовується досить давня (за ідеєю крос-броузерна) техніка придушення повідомлення про помилки через window.onerror. Все працює під Mozilla 1.4, MSIE 6.0 і навіть під стародавнім Netscape 4.5, але, на жаль, не під (куди популярнішою) Opera 7.23: остання видає повідомлення про помилку JavaScript. Звернення до деякого методу аплету необхідне - бо майже всі броузери (крім Netscape) успішно повертають ненульовий об'єкт document.
З інших методів перевірки всілякі onload у мене викликають недовіру - свого часу (на старих броузерах) мені часто доводилося налагоджувати ситуації, коли onload без видимих причин відмовлявся спрацьовувати, наприклад, при натисканні Refresh для сторінки або чогось подібного. Найнадійнішим здається "активне" інформування сторінки – коли Java-код аплету звертається до JavaScript. Але тут як би єдине крос-броузерне рішення - showDocument в окреме вікно (або фрейм), що робить рішення вкрай громіздким.
Можливо, хтось підкаже надійний, бажано опублікований та широко відомий спосіб перевірки завантаженості аплету?
Для Opera, до речі, нормально працює конструкція try...catch. Але тільки ця ж конструкція, якщо не помиляюся, призведе до помилки синтаксису в ранніх MSIE, які досі, здається, перевершують Opera за популярністю. Як би надійно впевнитись, що можна використовувати try...catch? Умовна компіляція MSIE -
/*@cc_on @*/ /*@if (@_jscript_version >= 5) (використовуємо тут try..catch та інші хороші речі) @*/ /*@end @*/
Як водиться, в Opera ігнорується: (
Мабуть, мають на увазі пакет netscape.javascript.* ?
Це рішення нестерпне - якщо не помиляюся, в MSIE з вбудованим JRE 1.1.4 ця техніка почала працювати тільки десь із версії 5.5 або навіть вище. Я цим пакетом ніколи не користувався - через непереносимість; можливо, я не правий? Я писав про це вище: "тут як би єдине крос-броузерне рішення - showDocument в окреме вікно (або фрейм), що робить рішення вкрай громіздким".
Аплети я зазвичай компілюю в JDK 1.1.6 (найраніша версія, наявна в архівах Sun); там цього пакета зовсім нема.
А якщо городити город, що враховує, що пакета netscape.javascript.* може не бути, то вийде нітрохи не краще, ніж, наприклад, окремо перевіряти оперу і використовувати для неї try...catch.
Давно було:) Варіанти:
public void init() (
//....
getAppletContext().showDocument("js_page.htm", "another_frame");
}
Приклад 1998 - http://www.copris.com/optocontrol/home.htm - в IE5.5 і Мозилла 1.6 працює (робилося в часи NN3 і IE3) :)
function checkApplet() (
if (document && document["appletName"] && document["appletName"].isActive())
//Do something
else
setTimeout(checkApplet, 100);
}
isActive() – це метод класу java.applet.Applet.
Олексій Рюмін aka Dwarf[досьє]
Велике спасибі. Але...
У мене, на жаль, сторінка за природою не фреймова, і вводити туди фрейми лише заради аплету дуже незручно. А варіант з IFRAME не крос-броузерний - це буде нічим не кращим за моє рішення з window.onerror.
Власне, вже зараз мої аплети з 3D-структурами присутні на кількох наших сторінках, а в майбутньому таких сторінок буде набагато більше (усілякі галереї прикладів структур тощо). Власне, на нашому сайті аплети займатимуть приблизно те саме місце, що й картинки ( ): ілюстрація до тексту, яку можна заразом "покрутити" мишкою. І біля кожного такого аплету, можливо, будуть деякі найпростіші кнопки, що керують JavaScript: ну хоча б для розвороту повернутою тривимірної картинкиу вихідну позицію.
Звідси – необхідність універсальної функціїна кшталт моєї getApp, яку можна покласти в js-файл, що підключається, і заради якої не треба перекроювати сайти на фрейми.
Пишемо простий тест.
... alert(document.XXXX+""+document.XXXX.isActive());
Після чого вантажимо цю сторінку через будь-який не-миттєвий Internet, почистивши попередньо кеш MSIE. Як і слід очікувати, поки аплет реально не завантажився (сірий квадрат), виклик isActive() породжує вищезгадане повідомлення про помилку. У той же час, звернення document.XXXX спрацьовує нормально, в чому можна переконатися, змінивши код на
alert(document.XXXX);
Якщо об'єкт сторінки XXXX був уже відрендерований, браузер дозволяє вільно звертатися до цього об'єкта.
Щоправда, тут випливає цікавий нюанс. При перетворенні об'єкта-аплета в рядок виходять різні результати, залежно від того, завантажився аплет чи ще ні. Саме якщо аплет завантажений, то перетворення DHTML -об'єкта в рядок дає результат виклику "toString()" в аплеті. За ідеєю, написати б у методі toString якесь ключове словоі перевіряти, чи є це слово в рядку document.имяапплета+"".
Було б просто чудово, дуже просто і красиво, і навіть Opera працює. Але - на жаль - цього разу підкачала Mozilla. Показує, зараза, безглузде незалежно від факту завантаження. Так що - не піде...
Поки що - підкажіть, як надійно "виявити", що ми маємо справу з сучасної Opera- Точніше, що працюють try...catch? Opera, здається, має звичай прикидатися іншими броузерами. Якщо з'ясувати, що try..catch працюють, можна викликати через eval версію коду з цими операторами - вона працює і під Opera.
Ще в цю тему. Пропоную поділити можливі рішенняпроблеми на дві групи.
Якщо можна, прошу обмежитись рішеннями другого типу.
Щось ви не розумієте, шановні.
Не можна явно викликати toString()! У DHTML -об'єкта "аплет" немає власного методу toString, він з'являється тільки коли завантажиться Java-клас. Відповідно, спроба вивести
alert(document.PackingSpheresForDesign.toString());
при незавантаженому аплеті призводить до помилки JavaScript, у моєму MSIE це "Unspecified error".
Неявно викликати toString, зрозуміло, можна завжди - перетворенням DHTML-об'єкта в рядок. І тут, як я вже казав, Mozilla веде себе некрасиво: ніколи не викликає toString() аплету, навіть коли аплет повністю завантажений. Та й не документовано ніде, що броузер повинен використовувати дляString Java-класу. Рішення, що спирається на перевірку рядкового представлення DHTML-об'єкта Applet, очевидно потрапляє в першу категорію: якщо якийсь броузер не захоче викликати метод toString, то на такому броузері аплет ЗАВЖДИ буде вважатися незавантаженим, і користувач взагалі не зможе працювати.
Як же переконатися в JavaScript, що броузер досить хороший, щоб зрозуміти конструкцію try...catch? Я поки що схиляюся піти цим шляхом.
Даніель Алієвський[досьє]
Не зрозуміло, що в MSIE виклик toString() помилка, але браузер-то в JavaScript легко визначити. Якщо браузер mozilla, викликайте toString(), якщо ні, просто applet.
Що стосується виклику методу toString в браузері, то наскільки я розумію у будь-якого об'єкта в javascript має бути метод toString і якщо браузер не викликає цей метод у аплету, тоді є сумніви в тому, що в цьому браузері взагалі можливо викликати методи аплету - безвідносно до поведінки у цьому випадку mozilla.
Коротше, треба спочатку знайти такий браузер і бажано щоб він був досить поширений, бо в іншому випадку я сам в змозі досить швидко написати браузер, який саботував би всі спроби визначення завантаженості аплету.
Ну так. Я просто не здогадався. Справді, треба просто до моєї функції звернутися не до методу getAppletInfo, а до методу toString. У MSIE правда, як і раніше, буде помилка, але вона благополучно ловиться через window.onerror. Зате в Opera - і у всіх броузерах, які дозволяють викликати toString у недозавантаженого аплета - ніяких помилок взагалі не буде, просто toString поверне або рядок з кодовим словом, якщо аплет завантажений, або щось замовчування. При цьому начебто не повинно бути настільки дивного броузера, щоб у нормально завантаженого аплету JavaScript-виклик toString не звернувся б до однойменного методу аплету.
Здається, знайдено непогане рішення. Спасибі за допомогу. Дотестую його під всякими кривими броузерами на зразок Netscape 3 - і запропоную для FAQ.
Олександр Самойлов [досьє] "Що стосується виклику методу toString у браузері, то наскільки я розумію у будь-якого об'єкта в javascript має бути метод toString і якщо браузер не викликає цей метод у аплету, тоді є сумніви в тому, що в цьому браузері взагалі можливо викликати методи аплету..." - тут я не зовсім вас зрозумів, адже саме найпопулярніший MSIE вважає, що ніякого toString у об'єкта Applet немає, якщо аплет не завантажений (наприклад, якщо вказано неправильний шлях до класу). Я взагалі не бачив виразних вказівок у документації, що КОЖНИЙ JavaScript об'єктповинен мати такий спосіб. Якщо такі є - тицьніть пальцем, якщо не важко.
цитата з довідки для JScript
The Object object is contained в all other JScript objects; всі його методи і властивості є доступними в усіх інших об'єктах. Методи можуть бути визначені в user-defined objects, і він називається JScript в відповідних випадках. У String метод є наслідком frequently redefined Object method.з неї, звичайно не можна однозначно зробити висновок, про те, що і для всіх інших інтерпретаторів JavaScript подібне виконується.
Що стосується MSIE, то він не вважає, що аплет не має методу toString, він вважає, що сталася невизначена помилка під час виконання цього методу.
наприклад, якщо спробувати викликати заздалегідь неіснуючий метод аплету то помилка буде інший.
Чорт! Ви сміятиметеся, але MSIE + Java 2 ЗАГАЛЬНО не бажає викликати toString() у НОРМАЛЬНО завантаженого аплета. Стійко видає Unspecified error. А при умовчому перетворенні в рядок, відповідно, мій перекритий до String просто ігнорується.
Можливо, звичайно, у мене щось не те з аплетом - треба було б, по ідеї, зробити чистий тест. Але в будь-якому випадку - якщо хоча б на моєму аплеті це так, то технологія неправильна.
Щоб його. Вчора забув перевірити цю ситуацію (перевіряв під Java 1.1.4). Сьогодні півгодини вбив на таємничий глюк сторінки. Гірше того, як " побічного ефекту MSIE почав глухо зависати при відкритті сторінки (мабуть, через різні мої допоміжні скрипти). Жахливо.
Повернувся до старої методики із викликом getAppletInfo().
Так що, панове, чекаю на подальші пропозиції. Зокрема – як відловити Оперу (щоб боротися з нею окремо).
Володимир Палант[Досьє] Дякую. Можна першоджерело, якщо не ускладнить? (Здогадуюсь, що десь на сайті opera.)
Мені б хотілося не так знайти Оперу, скільки перевірити Javascript, що він підтримує try...catch - сумісний з Opera способом. Мікрософтоський варіант такої перевірки – умовна компіляція – природно, під Opera не працює.
На крайній випадок достатньо і перевірки Опери: в цьому випадку можна (сподіваюся:-)) сміливо викликати toString у аплету.
Даніель Алієвський[досьє]
а чому б не використовувати версію яваскрипту для вилову підтримки try catch
var try_catch = false
try_catch=true
if (try_catch) ()
правда в опері не перевіряв
Даніель Алієвський[досьє]
Ні, на opera.com рекомендують перевіряти за User-Agent (http://www.opera.com/support/search/supsearch.dml?index=570) - ІМХО збочення. Перевіряти по window.opera надійніше - ніякий інший браузер цю властивість підтримувати не стане.
Opera підтримує try/catch як мінімум з версії 4.0, тому можете вважати, що підтримує завжди.
Є ще одна ідея – доки не перевірив. Звернення до властивостей DHTML-об'єкта (property), наскільки я знаю, ніколи не породжує винятків. Якщо такої властивості немає, просто повертається null. Добре було б забезпечити аплет деякою властивістю (наприклад, boolean iAmLoaded = true), і перевіряти, чи встановлено воно. Наскільки я розумію, у випадку Java 2 це не так просто - недостатньо завести public-поле, потрібно оголошувати пару методів get/set, як це належить JavaBeans (поки ще не вивчив відповідну документацію).
Як вважаєте, наскільки це надійна та крос-броузерна техніка?
Не зрозумів я, до чого тут JavaBeans, доступ до властивостей здійснюється без будь-яких get/set. Але в будь-якому випадку - можна перевіряти наявність методу, який для DHTML теж властивість: if (typeof(applet.notifyAll) != "undefined") . А ось кросбраузерність вам вже доведеться самим перевірити...
Володимир Палант[досьє]
Натяк на JavaBeans Introspection є ось тут: http://java.sun.com/j2se/1.4.2......loper_guide/compatibility.html
Як я зрозумів, проблема мала тимчасовий характер: у мене на комп'ютері у всіх броузерах та JRE доступ до public-поля чудово працює. Причому неважко додати в аплет "справжнє" public-поле типу booleanтоді не потрібно вдаватися до більш екзотичних прийомів типу typeof(applet.notifyAll). (До речі, згаданий typeof не працює у мене в MSIE ні з 1.1.4, ні з Java 2.)
Проблема в тому, що раніше я застосовував саме таку техніку - перевірку існування public-поля - і одного разу зіткнувся з проблемою, причому, очевидно, того самого неприємного першого типу: поле не виявлялося, аплет детектувався як незавантажений і відмовлявся працювати. Це сталося на 2 "чужих" комп'ютерах із цілком нормальною конфігурацією (MSIE + Java 2, щось на кшталт JRE 1.4.2_01), хоча на моєму комп'ютері все працювало. Звичайно, я перестав користуватися перевіркою поля - від гріха подалі.
Але, можливо, я просто зробив усе недостатньо грамотно? Скажімо, не оголосив методів get/set "по-JavaBean-овськи"? Якщо я не побачу в документації чіткого опису цієї проблеми з поясненням, чому на деяких броузерах доступ до звичайного public-поля не працює, і вказівкою, як це робити коректно, я, звичайно, не ризикну застосовувати перевірку поля - занадто висока ціна помилки.
Перехоплення повідомлення про помилку, як з'ясувалося, працює навіть під Netscape 3. Але трохи не так, як потрібно: цей древній броузер викликає процедуру показу повідомлення асинхронно із загальним потоком JavaScript-коду, що призводить до тонких помилок. Поки що не налагодив. Звичайно, сумісність з Netscape 3 нікому не потрібна, але насторожує, що методика (звернення до методу аплету, або toString для Опери, з перехопленням помилки) вимагає налагодження "по новій" мало не для кожного класу броузерів: (Мабуть, все-таки техніка крива А яка техніка "пряма" - поки незрозуміло.
З Netscape 3.0 пісня виявилася зовсім в іншому. Цей броузер взагалі не дуже дружив із зверненнями типу document.xxxx, де xxxx – ім'я аплета. Навіть для реально завантаженого аплета він мав звичай при такому зверненні видавати цілу пачку помилок:
Can't reflect applet "(null)": not loaded yet
(Найсмішніше, що це відбувається і під час перевірок типу "if (document.getElementById != null)...".) Боротьба з цим дуже проста. Достатньо кожне звернення до будь-якого document.xxxx обрамляти кодом на кшталт:
var onerrorSaveLocal = window.onerror;
window.onerror = null; // - avoiding an incorrect exception в Netscape Navigator 3
var v = document.xxxx;
window.onerror = onerrorSaveLocal;
При цьому, як і в Netscape 4, і у вбудованому "броузері" з JavaBuilder, при недозавантаженому аплеті document.ім'я Аплета просто повертає null.
Загалом, я витратив деякий час і налагодив свою процедуру під усіма броузерами, до яких зміг "дотягнутися" - включаючи попередні версії MSIE. Ось що вийшло:
Function showMyErrorMessage(msg,url,line) ( if (window.errorMessageA != null) alert(window.errorMessageA+"(System error message: "+msg+")"+window.errorMessageB); window.onerror = window.onerror return true; ) function getApp(name,notShowMessage) ( // Для компетентності з цією функцією, всі Java applets повинні override "toString()" method // and return a string containing "Successfully loaded Java applet" substring as it" window.errorMessageA = window.errorMessageB = null; if (notShowMessage==null || .errorMessageB = "Maybe, цей applet не є правильно loaded." + "Додаток не буде повністю налаштований, " + "або натисніть на цю сторінку."; ) var opera = window.opera != null; if (window.onerrorSave==null) window.onerrorSave=window.onerror;var app=null;var appInfo=null;var onerrorSaveLocal=window.onerror; window.onerror = null; // - avoiding an incorrect exception в Netscape Navigator 3 // ("Can"t reflect applet "(null)": not loaded yet") // sometimes appeared while accessing correctly loaded applets app = eval("document."+name ); window.onerror = onerrorSaveLocal; var systemErrorMessage = null; based catching @else @*/ window.onerror = showMyErrorMessage; // catching exceptions while calling non-existing method /*@end @*/ appInfo = app == null? toString(): // MSIE + Java2 cannot call applet"s toString app.getAppletInfo(); // MSIE and Mozilla (але не Opera) буде catch an exception here /*@if (@_jscript_version >= 5) ) catch( e) ( systemErrorMessage = e==null || e.description==null? "unknown error": e.description+""; ) @else @*/ window.onerror = window.onerrorSave; *@end @*/ if (app == null || systemErrorMessage != null || appInfo == null || (opera && (appInfo+"").indexOf("Successfully loaded Java applet")==-1)) ( if (window.errorMessageA != null) ( if (app == null) alert("Cannot find \"" + name + "\" Java applet." + window.errorMessageB);else if (systemErrorMessage != null) alert("An exception occured while accessing applet information for the \"" + name + "\" Java applet. (System exception information: " + systemErrorMessage + ")" + window.errorMessageB);else if (appInfo == null) alert("Cannot access applet information for \"" + name + "\" Java applet. " + window.errorMessageB); else alert("Cannot call \"" + name + "\" Java applet." + window.errorMessageB); ) return null; ) return app;
Як правило, MSIE доставили максимум проблем. З тих, що стосуються справи: MSIE 5.0, як з'ясувалося, відмовляється блокувати повідомлення про помилки через window.onerror. Довелося спеціально для "примхливого" MSIE написати гілку з умовною компіляцією та try..catch. На перший погляд, try..catch - найнадійніше рішення, тому цілком логічно застосовувати його в найпопулярнішому сімействі броузерів. При цьому в MSIE 4 (де немає try..catch), а також Mozilla продовжує працювати блокування помилки через window.onerror. В Opera використовується виклик доString і перевірка "кодового слова" всередині результату. Ще принагідно з'ясувалося, що в MSIE 4 краще не намагатися звертатися до аплету знеобов'язково - можуть бути помилки.
Я дійшов навіть до MSIE 3.0:-) Там, здається, моя процедура не спрацювала, хоча, можливо, річ тут у тому, що мої класи скомпільовані несумісним з Java 1.0.2 способом, а підтримувати подібну сумісність я не маю жодного бажання.
Тепер маю величезне прохання до всіх присутніх. Будь ласка, протестуйте цю процедуру з якимось аплетом на всіх своїх броузерах. Наприклад, чи це працює в Unix Mozilla/Opera, чи на Macintosh? Чи у всіх варіантах Windows + MSIE? Що щодо більш ранніх версій Opera?
Я протестував у наступних броузерах:
Windows XP: MSIE 6.0 з Java 1.4.2 та Java 1.1.4, Mozilla 1.4, Opera 7.23, Netscape 4.5, Netscape Navigator 3.0;
Windows NT 4.0: MSIE 5.0 з Java 1.4 та Java 1.1.4, Netscape 4.5, Netscape Navigator 3.0;
Windows 95: MSIE 3.0 (Java 1.0.2), Netscape 4.5.
Тестувати найпростіше, вказуючи на сторінці свідомо неправильний шлях до аплету (і, для порівняння, правильний) - на мою думку, це досить схоже на ситуацію, коли аплет не довантажився. Якщо все нормально, то, по ідеї, процедура заслуговує на приміщення в FAQ .
На цій сторінці кнопка "Get JVM information" (яка використовує вищеописану функцію) повинна спрацьовувати, як тільки аплет завантажиться, або "лаятися", поки він не завантажений.
(До речі, в MSIE 3.0 ця техніка таки не працює - у моїй версії 3.02 JavaScript взагалі відмовляється що-небудь робити, якщо аплет не завантажений. І бог з ним.)
Багато років тому, працюючи адміністратором на одному з градоутворюючих підприємств російської глибинки, мені довелося вперше зіткнутися з поняттям «електронно-цифровий підпис» (далі ЕЦП).
У головах керівництва, на той момент, укоренилася думка, що ЕЦП - це звичайний підпис, відсканований і доданий на всі документи, які мають бути підписані.
Давайте розберемося, що таке ЕЦП і як вона працює.
Для роботи з ЕЦП нам насамперед необхідний цифровий сертифікат і закритий ключ.
Спочатку нам необхідно встановити ЕЦП під документом.
Установка ЕЦП відбувається у два кроки:
1. Беремо документ, який хочемо підписати і обчислюємо хеш від цього документа. (Спрощено, хеш – це одностороння математична функціяперетворення документа довільної довжини, документ фіксованої довжини).
2. Потім цей отриманий хеш шифруємо нашим закритим ключем. 
Тепер документ, з прикріпленою до нього ЕЦП та нашим сертифікатом, надсилаємо одержувачам. 
Отримавши підписаний документ, нам необхідно перевірити підпис - дійсний він чи ні.
Перевірка ЕЦП відбувається дещо складніше:
1. Беремо документ, підпис під яким необхідно перевірити, обчислюємо хеш від цього документа.
2. Беремо цифровий сертифікат користувача, який підписав документ та прикріплену до документа ЕЦП (яка є зашифрованим на закритому ключі підпису хешом оригінального документа) та розшифровуємо за допомогою відкритого ключа.
Таким чином, у нас є два хеші – той, який ми вирахували самі і той, який ми отримали разом із документом та розшифрували відкритим ключем підписувача.
3. Тепер порівнюємо ці хеші. Якщо хеші збігаються, значить підпис дійсний, якщо хеші різняться, значить підпис недійсний. 
На закінчення визначимо, що нам дає використання цифровий підпис:
1. Незмінність в процесі передачі або зберігання - якщо документ був змінений, то хеш, який ми обчислимо, і який був прикріплений до документа, будуть різні, отже, підпис буде недійсним, з чого можна зробити висновок, що документ був змінений;
2.
Для того, щоб було неможливо підробити ЕЦП, закритий ключ повинен бути в єдиному екземплярі та доступ до нього повинен бути лише у власника. Це можна реалізувати, використовуючи смарт-карти, але це вже зовсім інша історія.
Привіт всім! Сьогодні спробую написати масштабну статтю про Java. Адже багато програм зараз їй використовують.
А під час роботи виникають часом помилки.
Java - що таке і для чого потрібна ця програмаJava - це мова програмування або технологія, якою пишуть онлайн-додатки. Тобто. чати на сайтах, ігри, завантаження файлів (у тому числі фото, відео) та багато інших речей.
Перевага даної технології:
А з недоліків швидкість виконання, хоч і були удосконалення.
Можливо, ще є, але це основні з офіційних джерел.
А ось яка історія:
Для того, щоб оновити java (або встановити) необхідно перейти на офіційний сайт програми. І натиснути на завантажити java.
І ще ... У браузерах, які розроблені на движку хроміум, java може не працювати. Якщо версія стара, то можна спробувати у адресному рядкуввівши chrome://flags/#enable-npapi даліпункт "Увімкнути NPAPI".
Але швидше за все, доведеться завантажувати стару версію браузера, шукати доповнення або використовувати Intenet Explorer.
Установка проста, просто натискаємо інстал.
Оновити так само можна через панель керування:
А у додатку вкладка Update.
До речі, ось інструкція, щодо включення в браузерах.
Для перевірки версії, також можна зайти в панель управління, вибрати java.
Кнопка About.
У вікні бачимо версію.
Видаляється Java звичайним способом, через засіб видалення програм, проте якщо ви не змогли видалити, скористайтеся утилітою .
Ось так виглядає видалення через JavaUninstallTool.
Тут я спробую розібрати часті помилкипри роботі. Якщо раптом у вас були помилки і ви їх вирішили, теж не соромтеся пишіть у коментарях, допоможемо один одному, так би мовити.
Java аплет не завантаженийДля початку, виконайте звичайні дії, переконайтеся, що встановлена необхідна версія java, не блокує і фаєрвол. Перезавантаження комп'ютера та роутера. Далі, якщо нічого не допомогло, йдемо на панель управління, вибираємо java.
Якщо ви використовуєте проксі, потрібно в General — Network Settings — Use proxy server прописувати проксі.
Ще є випадки, коли потрібно не зберігати тимчасові файли javaна комп'ютері, а зберігати на сервері банку, наприклад, але це індивідуальна ситуація. У таких ситуаціях слід читати інструкції на сайтах банків. І взагалі завжди, якщо налаштовуєте під банк java, читайте індивідуальні інструкції банку.
Помилка 1603: Оновлення Java не завершеноУ цій ситуації видаліть java за допомогою програми або можна спробувати вручну за допомогою панелі керування. Далі встановлюєте заново.
- Тут також спробуйте видалити якщо є стара версіята заново встановити. Під час встановлення спробуйте встановлювати від імені адміністратора.
- Переконайтеся, що ви маєте повний доступ до всіх папок.
- Завантажте офлайн установник і спробуйте встановити його.
- Якщо нічого не допомагає, переконайтеся, що нічого не перешкоджає встановленню, наприклад: антивірус, брандмауер.
- Для роботи всіх додатків потрібні NET Frameworkта Microsoft Visual C++, спробуйте їх оновити.
У цій помилці копіюємо шлях до програми, у мене це: C: Program Files (x86) Java jre1.8.0_144 bin
Шукаємо PATH та натискаємо редагувати.
Тут тепер акуратніше!
Наприклад ось мій шматок коду: C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;
Тобто. кожен параметр має бути відокремлений крапкою з комою. Якщо ви не впевнені у своїх силах, скопіюйте про всяк випадок цей рядок кудись.
Отже, що ми робимо:
Також можете спробувати такий шлях: C:\ProgramData\Oracle\Java\javapath;
У статті, я розповім як виправити помилку Java аплет не завантажено. Протягом більш як десятиліття існувало велика кількістьвеб-технології. Так, наприклад, для мультимедіа та простих ігорвикористовувався Flash, а проведення операцій, пред'являють високі вимогидо безпеки – ActiveX та Java. Але якщо розроблена Microsoft ActiveX вже давно канула в лету, Java EE продовжує бути актуальною досі. І справа не в тому, що не існує гідних і простіших для кінцевого користувачааналогів (вони саме з'явилися кілька років тому), проблема в тому, що деякі організації вклали десятки і сотні тисяч доларів у розробку додатків на підставі цих технологій, і вони просто так не можуть від них відмовитися. Саме тому, користувачі при спробі увійти до певний сервісможуть бачити повідомлення: Java аплет не завантажений, що робити, якщо ви зустріли його ми якраз і розглянемо нижче.
У деяких клієнтів ВТБ24 при спробі зайти до ВТБ24 онлайн виникає помилка. Вона якраз пов'язана з тим, що Java аплет або не встановлений у системі, або він вимкнений.
Щоб виправити цю помилку із завантаженням Java і без проблем увійти в панель керування рахунком, потрібно виконати ряд простих дій.
Що робити, якщо Java аплет не завантажений
Насамперед потрібно встановити саме програмне забезпечення. Якщо воно завантажене, але не включене, все одно завантажте – нехай буде встановлена найсвіжіша версія. Для цього:
Слід зазначити, що в Google Chrome(починаючи з 42 версії) аплет Java офіційно не підтримується, так як корпорація вважає відповідну технологію застарілою. Тому, щоб скористатися Java, запустіть інший веб-браузер, наприклад FireFox.
Щоб проблем із Java не виникало, виконайте такі дії:
Після виконання зазначених дійзаходьте на сайт, що вас цікавить - весь його функціонал (звичайно, якщо він не використовує інших сторонніх технологій) буде працювати, а помилки із завантаженням Java аплет не виникне.
Чи можна обійтися без JavaЯкщо у вас немає необхідності використовувати веб-додатки (як у випадку з банківським клієнтом ВТБ24), створені на основі Java EE, тоді відповідний аплет вам ні до чого. Поступово навіть великі компаніїпереходять на більш актуальні зараз для веб-а технології, взаємодіючи з функціями їх сервісів набагато простіше для кінцевого користувача.
Вконтакте
Завантажити та встановити java аплетДля встановлення та подальшого налаштування КриптоПро системи «Банк-клієнт Онлайн» вам потрібно буде скачати java аплет для «ВТБ 24». Завантажити можна безкоштовно на сторінці http://www.java.com/ru/. Цей компонент знадобиться, якщо ви використовуватимете у своїй роботі такі браузери, як Mozilla Firefox, Opera, Internet Explorer. Але це не єдині браузери, які підтримує ця система.
Установка java аплет проходить у два етапи:
Якщо java стоїть на вашому персональному комп'ютеріПерший етап слід пропустити. До речі, ПК не попросить вас встановити цей компонент. Установка проходить за п'ять кроків:
Налаштування здійснюється через "Пуск" у "Панелі управління". Потім відкрийте контрольну панель. Вам залишиться тільки відключення протоколів: TLS 1.1 і TLS 1.2. Зробити це просто: зніміть галочки навпроти. Аналогічно відключаємо «Use SSL 2.0 compatible Client Hello format». Все готово.
