Probleem on selles.
Leht sisaldab apletti ja selle haldamise liidest, mis on kirjutatud HTML + JavaScriptis. Peate JavaScripti abil kindlaks tegema, kas aplett on laaditud ja kasutamiseks valmis. Lahendus peab olema ERITI töökindel – ristbrauseriga, tundlik aeglasele internetile jne.
ma kommenteerin. Kuni apleti laadimiseni ilmuvad JavaScripti kõned selle avalikele meetoditele ja/või väljadele väga inetu järgmise sisuga sõnumiga: "See meetod puudub." Ja apleti laadimine võtab mõnikord palju kauem aega kui lehe enda laadimine. Pealegi on mõnikord mõttekas teha mõningaid asju automaatselt (JavaScriptist) kohe, kui aplet on laaditud – ütleme, et anna talle mingi käsk.
Probleem pole siin mitte niivõrd selles, et pole võimalik kontrollida, kas aplett on juba laaditud, vaid selles, et selliseid meetodeid on palju. Näiteks: apleti laadimine, lehe laadimine, apleti meetodi või välja kutsumine, lehe "aktiivne" teavitamine, et aplett on laaditud spetsiaalse Java koodiga apleti enda seest jne. Ja kindlustunne, et need meetodid töötavad:
igas mõeldavas brauseris,
kõigi brauseri turvaseadetega,
kombineerituna kõigi mõeldavate platvormidega,
kõigi JRE-dega,
Mul ei ole. Ja sellise enesekindluse saavutamine on peaaegu võimatu: kombinatsioone on liiga palju.
Veel hullem, tundub, et siin on väga lihtne “üle mõelda”. Näiteks eile “vaevlesin” pikka aega veaga - kellegi teise arvutis (XP+ MSIE + Java2) eeldas JavaScript ekslikult, et apletti ei laaditud, kuigi minu arvutis oli kõik korras. Ma kahtlustan, et fakt on see, et kasutasin seejärel saadavuse kontrollimiseks juurdepääsu apleti teatud avalikule muutujale (mitte meetodile!). Kõik minu arvuti brauserid (ka XP) tagastavad sellisele alakoormatud apleti muutujale ligipääsul nulli ja niipea, kui aplett laaditakse, tagastavad nad selle väärtuse. (Seevastu alakoormatud apleti meetodi kutsumine tekitab vea.) Kardan, et kellegi teise arvutis keeldus brauser avalikku muutujat lugemast. Juurdepääs muutujatele on üldiselt mitteilmne asi, mis töötab erinevate brauserite ja JRE-de korral erinevalt. Usaldusväärsed on ainult helistamismeetodid, kuid ainult siis, kui aplett on laaditud.
Siiani olen kirjutanud järgmine paar funktsioonid:
Funktsioon showMyErrorMessage(msg,url,line) ( if (window.errorMessage != null) alert(window.errorMessage); window.onerror = window.onerrorSave; return true; ) funktsioon getApp(nimi,notShowMessage) ( window.errorMessage = null; var a = "Viga apletile juurdepääsul teave jaoks\"" + nimi + "\" Java aplett."; var b = "Võib-olla see aplett on mitte õigesti loaded.Proovige see leht uuesti laadida."; if (notShowMessage==null || !notShowMessage) ( window.errorMessage = a + b; ) window.onerrorSave = window.onror; window.onror = showMyErrorMessage; var app = eval ("dokument."+nimi); var appInfo = app == null: app.getAppletInfo(); = null) ( if (app == null) alert("Ei pääse juurde \"" + nimi + "\" Java aplet." + b); else alert("Ei pääse juurde apleti teabele \"" + nimi + " \" Java applet" + b) tagastab rakendus;
Veateadete mahasurumiseks window.onror kaudu kasutame üsna iidset (teoreetiliselt brauseritevahelist) tehnikat. Kõik töötab Mozilla 1.4, MSIE 6.0 ja isegi iidse Netscape 4.5 all, kuid paraku mitte (palju populaarsema) Opera 7.23 all: viimane annab JavaScripti veateate. Mõne apletimeetodi väljakutsumine on vajalik – kuna peaaegu kõik brauserid (v.a Netscape) tagastavad edukalt mitte-null-dokumendi.Objekt AppletName niipea, kui lehel TAG-i loetakse
Muude kontrollimeetodite hulgas tekitavad minus umbusaldust igasugused sisselaadimised - omal ajal (vanemates brauserites) pidin sageli siluma olukordi, kus onload keeldus ilma nähtava põhjuseta töötamast, näiteks kui vajutate lehe või muu sarnase jaoks nuppu Refresh. Kõige usaldusväärsem tundub olevat "aktiivne" lehe teavitamine - kui apleti Java-kood pääseb ligi JavaScriptile. Siin aga tundub, et ainuke brauseriülene lahendus on showDocument eraldi aknas (või raamis), mis teeb lahenduse äärmiselt tülikaks.
Ehk oskab keegi soovitada mõnda usaldusväärset, soovitavalt avaldatud ja tuntud viisi, kuidas kontrollida, kas aplett on laetud?
Opera jaoks muide töötab try...catch konstrukt hästi. Kuid ainult see sama konstruktsioon, kui ma ei eksi, toob kaasa süntaksivea varases MSIE-s, mis tundub endiselt populaarsuselt Operat ületavat. Kuidas ma saan usaldusväärselt veenduda, et try...catchit saab kasutada? MSIE tingimuslik kompileerimine -
/*@cc_on @*/ /*@if (@_jscript_version >= 5) (kasuta try..catchit ja muid häid asju siin) @*/ /*@end @*/
Nagu tavaliselt, ignoreeritakse seda Operas :(
Oletan, et mõtlete paketti netscape.javascript.*?
See lahendus pole kaasaskantav – kui ma ei eksi, siis sisseehitatud JRE 1.1.4-ga MSIE-s hakkas see tehnika tööle alles kuskil versioonis 5.5 või isegi kõrgemas. Ma pole seda paketti kunagi kasutanud – talumatuse tõttu; äkki ma eksin? Kirjutasin sellest eespool: "siin tundub, et ainuke brauseriülene lahendus on showDocument eraldi aknas (või raamis), mis teeb lahenduse äärmiselt tülikaks."
Tavaliselt kompileerin aplette versioonis JDK 1.1.6 (kõige varasem versioon, mis Suni arhiivides saadaval); Seda paketti pole üldse olemas.
Ja kui aia aiaga piirata, arvestades, et netscape.javascript.* paketti ei pruugi olla, siis ei tule see parem välja, kui näiteks ooperit eraldi kontrollida ja kasutada try...catch'i.
Sellest on kaua aega möödas :) Valikud:
public void init() (
//....
getAppletContext().showDocument("js_page.htm", "teine_raam");
}
Näide aastast 1998 - http://www.copris.com/optocontrol/home.htm - töötab IE5.5 ja Mozilla 1.6 puhul (tehtud NN3 ja IE3 päevil) :)
funktsiooni checkApplet() (
if (dokument && dokument["apletinimi"] && dokument["apletinimi"].isActive())
//Tee midagi
muidu
setTimeout(checkApplet, 100);
}
isActive() on meetod klassis java.applet.Aplet.
Alexey Ryumin ehk kääbus[toimik]
Tänud. Aga...
Kahjuks ei ole mu leht oma olemuselt raamipõhine ja sinna raamide sissetoomine lihtsalt apleti pärast on väga ebamugav. Ja IFRAME-i valik ei ole brauseriülene - see pole parem kui minu lahendus windows.onror.
Tegelikult on minu 3D-struktuuridega apletid juba mitmel meie lehel olemas ja tulevikus on selliseid lehti palju rohkem (igasugused näidisstruktuuride galeriid jne). Tegelikult võtavad apletid meie veebisaidil umbes sama ruumi kui pildid ( ): illustratsioon tekstile, mida saab ka hiirega “keerata”. Ja iga sellise apleti kõrval on ilmselt mõned lihtsad JavaScripti juhtnupud: noh, vähemalt pööratud ümberpööramiseks kolmemõõtmelised pildid algasendisse.
Sellest ka vajadus universaalne funktsioon nagu minu getApp, mille saab paigutada kaasasolevasse js-faili ja mille jaoks pole vaja saite raamideks teisendada.
Kirjutame lihtsa testi.
... märguanne(dokument.XXXX+""+dokument.XXXX.onAktiivne());
Seejärel laadime selle lehe läbi mis tahes mitte-instant Interneti, olles esmalt tühjendanud MSIE vahemälu. Nagu arvata võis, genereerib isActive() kutse ülaltoodud veateate seni, kuni aplett on tegelikult laaditud (hall ruut). Samal ajal töötab document.XXXX kutsumine normaalselt, mida saate kontrollida, muutes koodi väärtuseks
hoiatus(dokument.XXXX);
Kuna leheobjekt XXXX on juba renderdatud, võimaldab brauser sellele objektile vaba juurdepääsu.
Tõsi, siin tuleb välja üks huvitav nüanss. Apletiobjekti stringiks muutmine annab erinevaid tulemusi olenevalt sellest, kas aplett on laaditud või mitte. Nimelt, kui aplett on laaditud, siis DHTML-objekti stringiks teisendamine annab tulemuseks apletis “toString()” kutsumise. Teoreetiliselt kirjutaks ma midagi toString meetodil märksõna ja kontrollige, kas see sõna on real document.appletinimi+"".
See oleks lihtsalt imeline, väga lihtne ja ilus ning töötab isegi Ooperis. Aga - paraku - seekord vedas Mozilla meid alt. Näitab infektsiooni, loll, olenemata laadimise faktist. Nii et see ei tööta...
Praegu – öelge mulle, kuidas usaldusväärselt "tuvastada", millega me tegeleme kaasaegne ooper- täpsemalt, mida proovida...tööle püüda? Operal näib olevat kombeks esineda teiste brauseritena. Kui avastad, et try..catch töötab, siis võiks eval kaudu helistada nende operaatoritega koodi versioonile - see töötab ka Opera all.
Veel samal teemal. Soovitan jagada võimalikud lahendused probleemid kahte rühma.
Võimalusel piirduge teist tüüpi lahendustega.
Midagi te ei mõista, kallid.
ToString() ei saa SELGELT kutsuda! DHTML-apleti objektil EI ole oma meetodit toString, see ilmub ainult siis, kui Java klass on laaditud. Sellest lähtuvalt katse tuletada
alert(document.PackingSpheresForDesign.toString());
kui apletti ei laadita, tekib JavaScripti tõrge, minu MSIE-s on see "Unspecified error".
Muidugi võite alati kutsuda toStringi kaudselt – teisendades DHTML-objekti stringiks. Ja siin, nagu ma juba ütlesin, käitub Mozilla inetult: ta ei kutsu kunagi apletis välja toString(), isegi kui aplett on täielikult laetud. Ja pole kuskil dokumenteeritud, et brauser peab kasutama toString Java klassi. Lahendus, mis tugineb DHTML-apleti objekti stringi esituse kontrollimisele, kuulub ilmselgelt esimesse kategooriasse: kui teatud brauser ei taha kutsuda meetodit toString, siis selles brauseris loetakse aplett ALATI laadimata ja kasutaja ei saa üldse töötada.
Kuidas veenduda JavaScriptis, et brauser on piisavalt hea, et mõista konstruktsiooni try...catch? Ma kaldun praegu seda teed minema.
Daniel Alievsky[toimik]
Ei, noh, on selge, et MSIE-s on kõne toString() viga, kuid brauserit on JavaScriptis lihtne kindlaks teha. Kui mozilla brauser, kutsuge toString(), kui mitte, siis lihtsalt aplet.
Mis puutub brauseris meetodi toString kutsumisse, siis minu arusaamist mööda peab igal javascripti objektil olema meetod toString ja kui brauser seda meetodit apletis välja ei kutsu, siis on kahtlusi, et apletti on üldse võimalik kutsuda meetodid selles brauseris – sõltumata käitumisest antud juhul mozilla.
Ühesõnaga, me peame esmalt leidma sellise brauseri ja on soovitav, et see oleks piisavalt levinud, sest muidu saan ma ise kiiresti kirjutada brauseri, mis saboteeriks kõik katsed kindlaks teha, kui hõivatud aplet on.
Nojah. Ma lihtsalt ei mõelnud sellele. Tõepoolest, oma funktsioonis pean lihtsalt viitama mitte meetodile getAppletInfo, vaid meetodile toString. MSIE-s aga, nagu varemgi, tekib viga, kuid see püütakse edukalt läbi window.onror. Kuid Operas – ja kõigis brauserites, mis võimaldavad alalaaditud apleti puhul kutsuda toStringi – ei esine üldse vigu, lihtsalt toString tagastab kas koodsõnaga stringi, kui aplett on laaditud, või midagi vaikimisi. Samas tundub, et brauser ei tohiks olla nii imelik, et tavapäraselt laetavas apletis JavaScripti kõne toString ei kutsuks samanimelist apletimeetodit.
Tundub, et hea lahendus on leitud. Aitäh abi eest. Testin seda kõikvõimalike kõverate brauserite (nt Netscape 3) all ja pakun selle KKK-sse.
Aleksander Samoilov[toimik] „Mis puudutab brauseris meetodi toString kutsumist, siis minu arusaamist mööda peab igal javascripti objektil olema meetod toString ja kui brauser seda meetodit apletis välja ei kutsu, siis on kahtlusi, et see on üldiselt võimalik seda selles brauseris nimetada apleti meetoditeks..." - ma ei saanud teist siinkohal päris hästi aru, sest kõige populaarsem MSIE usub, et apleti objektil pole toStringi, kui apletti ei laadita (näiteks kui on määratud vale klassitee). Ma ei ole näinud dokumentatsioonis ühtegi selget viidet, et KÕIK JavaScripti objekt see meetod peab olema. Kui neid on, osutage näpuga, kui mitte raske.
tsitaat JScripti abist
The Objekti objekt sisaldub kõigis teistes JScripti objektides; kõik selle meetodid ja omadused on saadaval kõikides teistes objektides. Meetodeid saab kasutaja määratud objektides uuesti määratleda ja JScript kutsub neid sobivatel aegadel. Meetod toString on näide sageli uuesti määratletud objektimeetodist.Sellest ei saa muidugi üheselt järeldada, et sama kehtib ka kõigi teiste JavaScripti tõlkide kohta.
Mis puutub MSIE-sse, siis see ei leia, et apletil pole meetodit toString, vaid see, et selle meetodi täitmisel tekkis täpsustamata viga.
nt kui proovite apletis kutsuda ilmselgelt olematut meetodit, on viga erinev.
Jama! Sa naerad, aga MSIE + Java 2 ei taha ÜLDSE TAVALIKULT laaditud apletil toString() kutsuda. Pidevalt toodab täpsustamata viga. Ja kui teisendatakse vaikimisi stringiks, siis minu alistatud toString lihtsalt ignoreeritakse.
Võib-olla on muidugi mu apletiga midagi valesti - teoreetiliselt peaksin puhta testi tegema. Aga igal juhul - kui vähemalt minu apletis see nii on, siis on tehnoloogia vale.
Mida iganes. Eile unustasin seda olukorda kontrollida (kontrollisin Java 1.1.4 alt). Täna veetsin pool tundi salapärase lehe tõrke kallal. Veelgi hullem, nagu " kõrvalmõju" MSIE hakkas lehte avades tarduma (ilmselt minu erinevate abiskriptide tõttu). Kohutav.
Naasis vana tehnika juurde getAppletInfo() kutsega.
Seega, härrased, ootan edasisi ettepanekuid. Eelkõige kuidas Opera kinni püüda (et sellega eraldi võidelda).
Vladimir Palant[toimik] Aitäh. Kas ma saan originaalallika, kui see mind ei häiri? (See on vist kuskil ooperi veebisaidil.)
Mulle meeldiks mitte niivõrd Opera avastada, kuivõrd kontrollida JavaScripti versioon et see toetab try...catch - ühildub Ooperi viis. Sellise kontrolli - tingimusliku kompileerimise - Microsofti versioon Opera all loomulikult ei tööta.
Halvimal juhul piisab Opera kontrollimisest: sel juhul saab (loodetavasti :-)) apletis turvaliselt toStringile helistada.
Daniel Alievsky[toimik]
miks mitte kasutada püüdmiseks javascripti versiooni proovi püüdmise tugi
var try_catch = vale
try_catch=true
kui (try_catch) ()
Ooperis ma seda ei kontrollinud
Daniel Alievsky[toimik]
Ei, saidil opera.com soovitatakse kontrollida User-Agenti (http://www.opera.com/support/search/supsearch.dml?index=570) abil – IMHO see on perversioon. Usaldusväärsem on kontrollida windows.opera abil – ükski teine brauser seda atribuuti ei toeta.
Opera on proovimist/püüdmist toetanud vähemalt versioonist 4.0, nii et võite eeldada, et see toetab seda alati.
On veel üks idee – ma pole seda veel katsetanud. Juurdepääs DHTML-objekti (omaduse) omadustele ei tee minu teada kunagi erandeid. Kui sellist vara pole, tagastatakse lihtsalt null. Hea oleks anda apletile mingi kindel omadus (näiteks tõeväärtus iAmLoaded=true) ja kontrollida, kas see on määratud. Niipalju kui ma aru saan, pole see Java 2 puhul nii lihtne - avaliku välja loomisest ei piisa, tuleb deklareerida paar get/set meetodit, nagu JavaBeansis nõutakse (ma pole veel teinud tutvunud vastavate dokumentidega).
Kui usaldusväärne ja brauseriteülene tehnoloogia see teie arvates on?
Ma ei saa aru, mis JavaBeansil sellega pistmist on, atribuutidele pääseb juurde ilma hankimise/määramiseta. Kuid igal juhul saate kontrollida meetodi olemasolu, mis on ka DHTML-i omadus: if (typeof(applet.notifyAll) != "undefined") . Kuid brauseritevahelise ühilduvuse peate ise kontrollima...
Vladimir Palant[toimik]
Siin on vihje JavaBeans Introspectioni kohta: http://java.sun.com/j2se/1.4.2......loper_guide/compatibility.html
Nagu ma aru saan, oli probleem ajutine: minu arvutis, kõigis brauserites ja JRE-s töötab juurdepääs avalikule väljale suurepäraselt. Pealegi pole apletile “päris” avaliku välja lisamine sugugi keeruline tüüp Boolean, siis ei pea te kasutama eksootilisemaid tehnikaid, nagu typeof(applet.notifyAll). (Muide, mainitud tüüp ei tööta minu jaoks MSIE-s ei 1.1.4 ega Java 2-ga.)
Probleem on selles, et ma kasutasin just sellist tehnikat - avaliku välja olemasolu kontrollimist - ja ühel päeval tekkis probleem ja ilmselgelt seda väga ebameeldivat esimest tüüpi: välja ei tuvastatud, aplett tuvastati laadimata kujul. ja keeldus täielikult töötamast. See juhtus kahel täiesti tavalise konfiguratsiooniga “võõral” arvutil (MSIE + Java 2, midagi sellist nagu JRE 1.4.2_01), kuigi minu arvutis kõik töötas. Loomulikult lõpetasin välikontrolli kasutamise – mitte kahjulikult.
Aga võib-olla ma lihtsalt ei teinud kõike piisavalt õigesti? Kas te näiteks ei deklareerinud get/set meetodeid "JavaBeani viisil"? Kui ma ei näe dokumentatsioonis selle probleemi selget kirjeldust, mis selgitaks, miks tavalisele avalikule väljale juurdepääs mõnel brauseris ei tööta, ja näitan, kuidas seda õigesti teha, ei riski ma kindlasti välja valideerimisega. vea hind on liiga kõrge.
Veateadete pealtkuulamine, nagu selgub, töötab isegi Netscape 3 all. Kuid - natuke vale: see iidne brauser kutsub sõnumi kuvamise protseduuri asünkroonselt JavaScripti koodi üldise vooluga, mis toob kaasa peeneid vigu. Ma pole seda veel kohandanud. Loomulikult ei vaja keegi Netscape 3-ga ühilduvust, kuid on murettekitav, et tehnika (apleti meetodi või toString for Opera kutsumine vigade pealtkuulamisega) nõuab peaaegu iga brauseriklassi jaoks "uuesti" silumist: (Ilmselt lõppude lõpuks, tehnika on viltu Ja milline tehnika on “sirge”, on siiani selgusetu.
Netscape 3.0-ga osutus lugu täiesti erinevaks. See brauser ei olnud üldiselt väga sõbralik selliste päringutega nagu document.xxxx, kus xxxx on apleti nimi. Isegi tõeliselt laaditud apleti puhul tekitas see sel viisil käsitlemisel terve hulga vigu:
Apletti "(null)" ei saa kajastada: pole veel laaditud
(Naljakas on see, et seda juhtub ka selliste kontrollidega nagu "if (document.getElementById != null)...".) Võitlus selle vastu on väga lihtne. Piisab, kui raamida iga kõne mis tahes dokumendile.xxxx sellise koodiga nagu:
var onrorSaveLocal = window.onror;
aken.onror = null; // - vale erandi vältimine Netscape Navigator 3-s
var v = dokument.xxxx;
window.onror = onrorSaveLocal;
Samal ajal, nagu Netscape 4-s ja JavaBuilderi sisseehitatud brauseris, tagastab apleti alalaadimisel document.Aplettnimi lihtsalt nulli.
Üldiselt kulutasin natuke aega ja silusin oma protseduuri kõigis brauserites, mis mulle kättesaadavad olid - sealhulgas varasemad versioonid MSIE. See juhtus järgmiselt.
Funktsioon showMyErrorMessage(msg,url,line) ( if (window.errorMessageA != null) alert(window.errorMessageA+"(Süsteemi veateade: "+msg+")"+window.errorMessageB); window.onerror = window.onerrorSave; return true ) funktsioon getApp(name,notShowMessage) ( // Selle funktsiooniga ühilduvuse tagamiseks peavad kõik Java-apletid alistama meetodi "toString()" // ja tagastama stringi, mis sisaldab alamstringi "Java aplet on edukalt laaditud" window.errorMessageA = window.errorMessageB = null if (notShowMessage==null || !notShowMessage) ( window.errorMessageA = "Viga \"" + nimi + "\" Java apleti teabele juurdepääsul."; "+" .onrorSave == null) window.onrorSave = window.onror var appInfo = null; aken.onror = null; // - Netscape Navigator 3 vale erandi vältimine // ("Ei saa kajastada apletti "(null)": pole veel laaditud") // ilmus mõnikord õigesti laaditud aplettidele juurdepääsul app = eval("document."+nimi window.onror = onerrorSaveLocal var systemErrorMessage = null /*@cc_on@*/ /*@if (@_jscript_version >= 5) proovige ( // mõni MSIE (näiteks MSIE 5.0) ei mõista onror-based; püüdmine @else @*/ window.onror = showMyErrorMessage // erandite püüdmine olematu meetodi kutsumisel /*@end @*/ appInfo = app == null: // Netscape'i brauserirakenduse juhtum toString(): / / MSIE + Java2 ei saa helistada apletile toString app.getAppletInfo(); // MSIE ja Mozilla (kuid mitte Opera) tabavad siin erandi /*@if (@_jscript_version >= 5) ) catch( e) ( systemErrorMessage = e==null ||. e.description== null? if (rakendus == null || systemErrorMessage != null || appInfo == null || (opera && (appInfo+"").indexOf("Java aplett on edukalt laaditud")==-1)) ( if (window.errorMessageA != null) ( if (app == null) alert("Ei leia \"" + nimi + "\" Java aplett." + window.errorMessageB); else if (systemErrorMessage != null) alert("Java apleti \"" + nimi + "\" apleti teabele juurdepääsul ilmneb erand. (Süsteem erandi teave: " + systemErrorMessage + ")" + window.errorMessageB); else if (appInfo == null) alert("Ei pääse juurde apleti teabele \"" + nimi + "\" Java apleti jaoks. " + window.errorMessageB); else alert("Ei saa helistada \"" + nimi + "\" Java aplett." + window.errorMessageB); ) return null; ) tagasta rakendus; )
Nagu tavaliselt, põhjustas MSIE maksimaalseid probleeme. Asjakohane: näib, et MSIE 5.0 keeldub tõrketeadete blokeerimisest läbi window.onror. Tuli kirjutada tingimusliku kompileerimisega haru ja proovida..saak spetsiaalselt “kapriisse” MSIE jaoks. Esmapilgul try..catch on kõige töökindlam lahendus, seega on üsna loogiline kasutada seda kõige populaarsemas brauserite perekonnas. Samal ajal töötab MSIE 4-s (kus puudub try..catch), aga ka Mozillas vigade blokeerimine läbi window.onror edasi. Opera kasutab toString-kutset ja kontrollib tulemuse sees olevat "koodsõna". Samuti selgus teekonnal, et MSIE 4-s on parem mitte proovida rakendusest onbeforeunload apletile juurde pääseda - võib esineda vigu.
Jõudsin isegi MSIE 3.0-ni :-) Tundub, et seal minu protseduur ei töötanud, kuigi võib-olla on asi selles, et mu klassid on kompileeritud viisil, mis ei ühildu Java 1.0.2-ga ja mul pole soovi sellist säilitada. ühilduvus.
Nüüd on mul suur palve kõigile kohalviibijatele. Palun testige seda protseduuri mõne apletiga kõigis oma brauserites. Kas see töötab näiteks Unix Mozilla/Opera või Macintoshi peal? Kas see on saadaval kõigis Windows+MSIE versioonides? Mis siis veel varasemad versioonid Ooper?
Testisin järgmistes brauserites:
Windows XP: MSIE 6.0 koos Java 1.4.2 ja Java 1.1.4-ga, Mozilla 1.4, Opera 7.23, Netscape 4.5, Netscape Navigator 3.0;
Windows NT 4.0: MSIE 5.0 koos Java 1.4 ja Java 1.1.4, Netscape 4.5, Netscape Navigator 3.0;
Windows-95: MSIE 3.0 (Java 1.0.2), Netscape 4.5.
Lihtsaim viis testimiseks on märkida lehele teadlikult vale apleti tee (ja võrdluseks õige) - minu arvates on see üsna sarnane olukorraga, kui aplett ei laaditud. Kui kõik on korras, siis teoreetiliselt väärib protseduur KKK-sse lisamist.
Sellel lehel peaks nupp "Hangi JVM-i teave" (kasutades ülalkirjeldatud funktsiooni) käivituma kohe pärast apleti laadimist või "vannuma", kuni see laaditakse.
(Muide, MSIE 3.0 puhul see tehnika ei tööta – minu versioonis 3.02 keeldub JavaScript üldse midagi tegemast, kui apletti ei laadita. Ja jumal õnnistagu teda.)
Palju-palju aastaid tagasi, töötades administraatorina ühes Venemaa tagamaade linna moodustavas ettevõttes, puutusin esimest korda kokku mõistega “elektrooniline digitaalallkiri” (edaspidi EDS).
Sel ajal oli juhtkonna peas juurdunud mõte, et elektrooniline allkiri on tavaline allkiri, skannitakse ja lisatakse kõikidele dokumentidele, mis tuleb “allkirjastada”.
Mõelgem välja, mis on digitaalallkiri ja kuidas see töötab.
Digiallkirjaga töötamiseks vajame ennekõike digitaalset sertifikaati ja privaatvõti.
Esiteks peame dokumendi alla installima elektroonilise allkirja.
Digitaalallkirja installimine toimub kahes etapis:
1. Võtke dokument, millele tahame allkirjastada, ja arvutage selle dokumendi räsi. (Lihtsustatult öeldes on räsi ühesuunaline matemaatiline funktsioon suvalise pikkusega dokumendi muutmine fikseeritud pikkusega dokumendiks).
2. Seejärel krüpteerime saadud räsi oma privaatvõtmega. 
Nüüd saadame dokumendi koos digiallkirja ja sellele lisatud meie sertifikaadiga adressaatidele. 
Pärast allkirjastatud dokumendi saamist peame kontrollima allkirja - kas see on kehtiv või mitte.
EDS-i kontrollimine on mõnevõrra keerulisem:
1. Võtke dokument, mille allkiri vajab kontrollimist, ja arvutage selle dokumendi räsi.
2. Võtame dokumendi allkirjastanud kasutaja digisertifikaadi ja dokumendile lisatud digiallkirja (mis on allkirjastaja privaatvõtmele krüpteeritud räsi originaaldokument) ja dekrüpteerida avaliku võtmega.
Seega on meil kaks räsi – see, mille me ise arvutasime, ja see, mille saime koos dokumendiga ja mille dekrüpteerisime allkirjastaja avaliku võtmega.
3. Nüüd võrdleme neid räsi. Kui räsid ühtivad, on allkiri kehtiv, kui räsid erinevad, on allkiri kehtetu. 
Kokkuvõtteks otsustame, mida kasutada digitaalne allkiri:
1. Muutmatus edastamise või säilitamise ajal - kui dokumenti on muudetud, siis meie arvutatud ja dokumendile lisatud räsi on erinev, seetõttu on allkiri kehtetu, millest saame järeldada, et dokument on muutunud;
2.
Digiallkirja võltsimise võimatuks muutmiseks peab privaatvõti olema ühes eksemplaris ja sellele peab olema juurdepääs ainult omanikul. Seda saab rakendada kiipkaartide abil, kuid see on hoopis teine lugu.
Tere kõigile! Täna proovin kirjutada suuremahulise artikli Java kohta. Lõppude lõpuks kasutavad seda nüüd paljud rakendused.
Ja töö ajal juhtub mõnikord vigu.
Java - mis see on ja milleks see programm on mõeldud?Java on programmeerimiskeel või tehnoloogia, milles kirjutatakse võrgurakendusi. Need. vestlused veebisaitidel, mängud, failide (sh fotod, videod) allalaadimine ja palju muud.
Selle tehnoloogia eelised:
Üks puudujääke on täitmise kiirus, kuigi parandusi on tehtud.
Neid võib olla rohkem, kuid need on peamised ametlikud allikad.
Siin on lugu:
Java värskendamiseks (või installimiseks) peate minema rakenduse ametlikule veebisaidile. Ja klõpsake nuppu Laadi alla java.
Ja veel üks asi... Chromiumi mootoril arendatud brauserites ei pruugi java töötada. Kui versioon on vana, võite proovida aadressiriba sisenedes chrome://flags/#enable-npapi järgmiseksÜksus "Luba NPAPI".
Kuid tõenäoliselt peate alla laadima brauseri vana versiooni, otsima lisandmooduleid või kasutama Intenet Explorerit.
Installimine on lihtne, klõpsake lihtsalt installi.
Saate värskendada ka juhtpaneeli kaudu:
Ja rakenduses on vahekaart Värskenda.
Muide, siin on juhised selle brauserites lubamiseks.
Versiooni kontrollimiseks võite minna ka juhtpaneelile, valida java.
Nupp Teave.
Avanevas aknas näeme versiooni.
Java eemaldatakse tavapärasel viisil, programmi eemaldamise tööriista kaudu, kuid kui te ei saanud seda eemaldada, kasutage utiliiti.
Nii näeb desinstallimine välja JavaUninstallTooli abil.
Siin ma püüan selle välja mõelda levinud vead tööl. Kui teil tekkis ootamatult vigu ja lahendasite need, ärge kartke kommentaaridesse kirjutada, me aitame üksteist nii-öelda ...
Java apletti pole laaditudAlustamiseks järgige tavalisi samme, veenduge, et vajalik java versioon, ei blokeeri tulemüüri. Taaskäivitage arvuti ja ruuter. Järgmiseks, kui kõik muu ebaõnnestub, minge juhtpaneelile ja valige Java.
Kui kasutate puhverserverit, peate puhverserveri registreerima jaotises Üldine - Võrguseaded - Kasuta puhverserverit.
Endiselt tuleb ette juhuseid, kui on vaja mitte ajutist ladustada java failid arvutis ja näiteks pangaserveris, kuid see on individuaalne olukord. Sellistes olukordades peate lugema juhiseid pankade veebisaitidel. Ja üldiselt, alati, kui seadistate java panga jaoks, lugege panga individuaalseid juhiseid.
Viga 1603: Java värskendus pole lõpetatudSellises olukorras desinstallige java rakenduse abil või proovige seda käsitsi juhtpaneeli kaudu. Seejärel installige uuesti.
- Siin proovige ka kustutada, kui on vana versioon ja installige uuesti. Installimisel proovige installida administraatorina.
- Veenduge, et teil oleks täielik juurdepääs kõikidele kaustadele.
- Laadige alla võrguühenduseta installiprogramm ja proovige seda installida.
- Kui kõik muu ebaõnnestub, veenduge, et miski ei takista installimist, näiteks: viirusetõrje, tulemüür.
- Kõik rakendused nõuavad NET Framework ja Microsoft Visual C++, proovige neid värskendada.
Selles veas kopeerime programmi tee, minu jaoks on see: C:\Program Files (x86)\Java\jre1.8.0_144\bin
Otsime üles PATH ja klõpsame Muuda.
Olge siin nüüd ettevaatlik!
Näiteks siin on minu koodilõik: C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;
Need. iga parameeter tuleb eraldada semikooloniga. Kui te pole oma võimetes kindel, kopeerige see rida igaks juhuks kuhugi.
Mida me siis teeme:
Võite proovida ka seda teed: C:\ProgramData\Oracle\Java\javapath;
Artiklis räägin teile, kuidas Java-apleti viga parandada. Juba üle kümne aasta on olnud suur hulk veebitehnoloogiad. Nii näiteks multimeedia ja lihtsad mängud Välku kasutati ja seda nõudvate toimingute tegemiseks kõrged nõuded turvalisusele – ActiveX ja Java. Kuid kui Microsofti arendatud ActiveX on ammu unustusehõlma vajunud, on Java EE aktuaalne tänaseni. Ja asi ei ole selles, et poleks väärt ja lihtsamaid lõppkasutaja analooge (need ilmusid just mitu aastat tagasi), on probleem selles, et mõned organisatsioonid on investeerinud kümneid ja sadu tuhandeid dollareid nendel tehnoloogiatel põhinevate rakenduste väljatöötamisse ja nad lihtsalt ei saa neist keelduda. Sellepärast, kui kasutajad proovivad sisse logida konkreetne teenus võib näha teadet: Java-apletti pole laaditud, mida teha, kui sellega kokku puutute, vaatame allpool.
Mõnel VTB24 kliendil tekib võrgus VTB24 sisselogimisel tõrge. See on tingitud just sellest, et Java apletti pole süsteemi installitud või see on keelatud.
Selle vea parandamiseks Java laadimisel ja oma konto juhtpaneelile probleemideta sisselogimiseks peate järgima mitmeid lihtsaid samme.
Mida teha, kui Java apletti ei laadita
Kõigepealt peate installima tarkvara ise. Kui see on alla laaditud, kuid pole lubatud, laadige see ikkagi alla – installige uusim versioon. Selle jaoks:
Tuleb märkida, et sisse Google Chrome(alates versioonist 42) Java apletti ametlikult ei toetata, kuna ettevõte peab vastavat tehnoloogiat vananenuks. Seetõttu käivitage Java kasutamiseks mõni muu veebibrauser, näiteks FireFox.
Java probleemide vältimiseks toimige järgmiselt.
Pärast hukkamist täpsustatud toimingud minge teid huvitavale saidile - kõik selle funktsioonid (muidugi, kui see ei kasuta muid kolmanda osapoole tehnoloogiaid) töötavad ja Java-apleti laadimisel vigu ei esine.
Kas ilma Javata saab hakkama?Kui Sul ei ole vaja kasutada Java EE baasil loodud veebirakendusi (nagu VTB24 pangakliendi puhul), siis pole vastavast apletist Sulle kasu. Tasapisi isegi suured ettevõtted lülituvad praegu asjakohasematele veebitehnoloogia, mis muudab lõppkasutaja jaoks nende teenuste funktsioonidega suhtlemise palju lihtsamaks.
Kokkupuutel
Laadige alla ja installige java aplettCryptoPro Bank-Client Online süsteemi installimiseks ja seejärel konfigureerimiseks peate alla laadima VTB 24 jaoks mõeldud java apleti. Saate selle tasuta alla laadida lehelt http://www.java.com/ru/. Seda komponenti läheb vaja, kui kasutate selliseid brausereid nagu Mozilla Firefox, Opera, Internet Explorer. Kuid need pole ainsad brauserid, mida see süsteem toetab.
Java-apleti installimine toimub kahes etapis:
Kui java on teie peal personaalarvuti, tuleks esimene samm vahele jätta. Muide, arvuti ei palu teil seda komponenti installida. Paigaldamine toimub viies etapis:
Seadistamine toimub "Juhtpaneeli" "Start" kaudu. Seejärel avage kontrollpaneel. Kõik, mida pead tegema, on keelata protokollid: TLS 1.1 ja TLS 1.2. Seda on lihtne teha: tühjendage nende märge. Samamoodi keelake "Kasuta SSL 2.0-ga ühilduvat ClientHello vormingut". Kõik on valmis.
