05.03.2013
Yleisimmät virheet lähetettäessä tietoja OOS:hen:
Yleiset virheet ja virheet, joita esiintyy lähetettäessä ilmoitus avoimesta huutokaupasta sähköisessä muodossa:
- Väärät tiedot. Yhdelläkään koodia käyttävistä organisaatioista ei ole rekisteröityä käyttötiliä ja/tai henkilökohtaista tiliä ja/tai BIC-koodia. - virhe tarkoittaa, että OOS:lle siirrettyjä tilitietoja ei ole rekisteröity virallisella verkkosivustolla joko asiakkaan organisaation tai järjestäjän organisaation osalta.
- Virheelliset käyttäjätiedot. Tilauksen tekevä organisaatio ei ole sama kuin käyttäjän organisaatio. - virhe osoittaa, että sen organisaation SDR:n rekisteröintinumero, jonka kirjautumisesta asiakirja lähetetään OOS:hen (käyttäjänimi) ei vastaa tilauksen tekevän organisaation rekisteröintinumeroa. Ympäristönsuojeluorganisaation rekisteröintitietolomakkeen täytön oikeellisuus on tarpeen tarkistaa tilauksen tekevältä organisaatiolta.
- Väärät tiedot. Koodilla valtuutetulla taholla ei ole valtuuksia tehdä tilausta koodilla varustetun asiakkaan puolesta. - todennäköisesti asiakkaan organisaatio ei ole huutokaupan järjestäjän alainen organisaatio. Ympäristönsuojelutesti suoritetaan SDR-numerolla, joten on täysin mahdollista, että asiakkaan SDR-numero on yksinkertaisesti väärä.
- Väärät tiedot. Organisaation SDR-koodi [xxx] ei sisälly käyttöjärjestelmään. - Se tarkoittaa, että se todella on niin. Sinun on varmistettava, että syötät tämän SDR-koodin oikein. SDR-koodin tulee olla 11 numeroa pitkä.
- Kaavion vahvistusvirhe. 66:21 cvc-complex-type.2.4.a: Virheellinen sisältö, joka alkaa elementistä "amount". Yksi '("?http://zakupki.gov.ru/oos/types/1":settlementAccount )' oli odotettavissa. - ongelma liittyy pankkitietoihin. Ehkä jossain tilauslomakkeessa on mainittu vakuuden/maksusumman määrä, maksun suorittamisen määräaika ja menettely, mutta varojen talletuksen yksityiskohtia ei ole valittu.
- Kaavion vahvistusvirhe. 41:31 cvc-complex-type.2.4.b: Elementin 'customerRequirement' epätäydellinen sisältö. Odotettu jokin seuraavista: ("?http://zakupki.gov.ru/oos/types/1":deliveryPlace , "?http://zakupki.gov.ru/oos/types/1":deliveryTerm , " )' . - tietoja sovelluksen suojauksesta ei ole täytetty. Itse asiassa kaikki sivuston vastaukset sisältävät tekstiä suunnilleen seuraavasti " Odotettiin yhtä [...] ?http://zakupki.gov.ru/oos/types/1":guaranteeApp )"Merkitys on sama. CAO huomautti myös, että tietoja tavaroiden/töiden/palvelujen toimituspaikasta ja -ajasta ei täytetty, mutta näitä tietoja ei tarvitse täyttää. Avain on hakemuksen turvaaminen .
- Kaavion vahvistusvirhe. 17:17 cvc-complex-type.2.4.b: Elementin 'contactInfo' epätäydellinen sisältö. Yksi '("?http://zakupki.gov.ru/oos/types/1":orgFactAddress )' oli odotettavissa. - yhteysorganisaation osoitetta ei ole määritelty.
- Kaavion vahvistusvirhe. 48:8 cvc-complex-type.2.4.b: Elementin "EP" epätäydellinen sisältö. Yksi '("?http://zakupki.gov.ru/oos/types/1":code )' oli odotettavissa. - lähetetty tiedosto ei sisällä tietoja kaupankäyntialustasta. Todennäköisesti tätä määritettä ei yksinkertaisesti ole valittu lomakkeessa.
- Kaavion vahvistusvirhe. 18:27 cvc-complex-type.2.4.a: Virheellinen sisältö, joka alkaa elementistä "notificationCommission". Odotettu yksi seuraavista: '("?http://zakupki.gov.ru/oos/types/1":printForm , "?http://zakupki.gov.ru/oos/types/1":documentMetas , " )' . - itse asiassa tämä virhe tarkoittaa todennäköisesti sitä, että ilmoituksen suunniteltua julkaisupäivää ei ole ilmoitettu. Itse asiassa kaikissa sivuston vastauksissa, jotka sisältävät tekstiä suunnilleen seuraavasti " Yksi [...] odotettiin ?http://zakupki.gov.ru/oos/types/1":publishDate)"Merkitys on sama.
- NotificationCommission-elementin sisältö epätäydellinen. Yksi '("?http://zakupki.gov.ru/oos/types/1":p1Date )' oli odotettavissa. - hakemusten jättämisen määräajan päivämäärää ja kellonaikaa ei ole ilmoitettu.
- Virheelliset käyttäjätiedot. Salasanan tarkistus käyttäjälle, jolla on sisäänkirjautuminen, epäonnistui - tämä virhe osoittaa, että tämän kirjautumisen OOS-salasana (user_login) on virheellinen. On syytä varmistaa, että syötetyt tiedot ovat oikein. Itse asiassa tämä virhe liittyy yleensä OOS-ongelmiin, joka jostain syystä "hylkää" kaikki salasanat (oikeat tai eivät). Se voidaan ratkaista soittamalla toiseen OOS:n teknisen tuen linjaan ja odottamalla. Joskus pelkkä odottaminen riittää.
- Etäpalvelin palautti virheen: (408,502,504) - Yleensä meillä ei ole mitään tekemistä tämän kanssa, mutta kannattaa varmistaa, että palvelimella on pääsy OOS:ään. Jos kaikki on hyvin viestintäkanavan kanssa, odotamme vain. Yleensä nämä ovat seurauksia rutiininomaisesta kunnossapidosta ympäristönsuojelujärjestelmään.
- Kaavion vahvistusvirhe. 68:23 cvc-complex-type.2.4.a: Virheellinen sisältö, joka alkaa elementistä "fullName". Yksi '("?http://zakupki.gov.ru/oos/types/1":regNum )' oli odotettavissa. - joko järjestäjällä tai asiakkaalla ei ole SDR-rekisteröintinumeroa WEB-Torgi-KS-järjestelmässä. Pääsääntöisesti asiakkaan luona.
- Väärät tiedot. Yhdessä erässä ei voida määrittää kahta tai useampaa identtistä OKDP-koodia - Tosiasia on, että kaikki, mitä OOS hyväksyy tuotelinjoilta, on KOODIA. Kaksi tuotetta, joilla on sama OKDP-koodi, mutta eri ominaisuudet (kuvaukset) koetaan samanlaisiksi. Sukupolvimyymälän uusimmissa versioissa merkkijonot yhdistetään, eikä tätä virhettä pitäisi enää esiintyä.
- 1. Virhe (poisto vaaditaan): Validointivirhe kaavion mukaisesti. 76:42 cvc-type.3.1.3: RegNum-elementin arvo '03762000029' on virheellinen. 2. Virhe (poisto vaaditaan): Kaavan mukainen validointivirhe. 76:42 cvc-pattern-valid: Arvo '03762000029' ei kelpaa, koska tyypin 'spzNumType' malli on \d(1,11). - SDR-numero on ilmoitettu väärin (on oltava 11 numeroa ilman välilyöntejä tai muita merkkejä)
- Virhe (täytyy ratkaista): Kaavan vahvistusvirhe. 76:22 cvc-complex-type.2.4.a: Virheellinen sisältö, joka alkaa elementistä docName. Yksi '("?http://zakupki.gov.ru/oos/types/1":sid , "?http://zakupki.gov.ru/oos/types/1":ordinalNumber )' oli odotettavissa. - sähköisessä muodossa lähetettäessä avointa huutokauppaa koskevaa ilmoitusta tapahtuu virhe, joka johtuu siitä, että rivin sarjanumeroa ei ole ilmoitettu yhdessä valmiissa hankintavaatimusten mukaisessa ruudukossa.
- Virhe (poisto vaaditaan): Kaavan vahvistusvirhe. 8:28 cvc-pattern-valid: Arvo ' ' ei kelpaa, koska tyyppi 'notificationNumberType' on kaava '\d(19) '. 2. Virhe (poisto vaaditaan): Kaavan mukainen validointivirhe. 8:28 cvc-type.3.1.3: NotificationNumber-elementin arvo ' on virheellinen. - virhe ilmenee, kun ilmoituksessa ei ole rekisterinumeroa.
- Virhe (poisto vaaditaan): Kaavan vahvistusvirhe. 586:12 cvc-complex-type.2.4.a: Virheellinen sisältö, joka alkaa elementistä "inn". Yksi '("?http://zakupki.gov.ru/oos/types/1":participantType )' oli odotettavissa. - tapahtuu virhe, kun toimittajahakemistossa ei ole SUPPLIER TYPE.
Artikkelissa Palvelusopimuksen suunnittelu totesimme, että todella itsedokumentoiva sopimus tarkoittaa kykyä automaattisesti validoida viestit, joita tietty palvelu viestii ulkomaailman kanssa. On aika tarkastella tätä prosessia yksityiskohtaisemmin.
Ensinnäkin selvitetään, missä tapauksissa viestin validointi on tarpeen.
Viestejä ei tarvitse vahvistaa seuraavissa tapauksissa:
Palvelusopimusten kuvaamiseen on kaksi tapaa:
- tiukasti kirjoitettu palvelu;
- heikosti kirjoitettu palvelu.
Vahvasti kirjoitettu palvelu
Tätä lähestymistapaa käyttämällä määrittelemme yksityiskohtaisesti kaikki rajoitukset jokaiselle tietorakenteen komponentille. Esimerkki muovikortista:
Tässä esimerkissä tarkistamme seuraavat ehdot:
- korttityyppi: Visa tai MasterCard;
- numero: 16 numeroa;
- kuukausi, johon asti kortti on voimassa, 1-12;
- vuosi, johon asti kortti on voimassa, 2010–9999;
- suojakoodi: 3 numeroa.
Heikosti kirjoitettu palvelu
Tässä lähestymistavassa skeemaa käytetään vain tietorakenteen määrittelemiseen, samalla kun skeeman komponenttien sisällölle asetetut rajoitukset pyritään minimoimaan.
Tämän lähestymistavan tärkeä etu: palvelusta tulee erittäin joustava, voit lisätä esimerkiksi uudentyyppisiä kortteja ilman, että joudut tarkistamaan, että olemassa olevien tyyppien validointiprosessi on katkennut.
Tämän lähestymistavan haittapuolena on, että siinä ei ole käytettävissä tiedonhallintamekanismeja, vaan tarvitaan lisämekanismeja käyttävä validointi. Tässä tapauksessa koodin monistaminen on mahdollista, jos samaa validointia käytetään useissa palveluissa.
Toinen haittapuoli on se, että palvelun kuluttaja ei voi tämän kuvauksen perusteella ymmärtää, mitkä tiedot ovat oikein, ts. karkeasti sanottuna, mitä he haluavat häneltä. Palveluparametreista vaaditaan lisädokumentaatio.
Siellä on myös ns yhdistetty lähestymistapa, joka tarjoaa tasapainon tietonäkymän laajennettavuuden ja täydellisyyden välillä. Tällä lähestymistavalla järjestelmän jokaiselle osalle asetetaan vähimmäisrajoituksia: oikea tietotyyppi (merkkijono, numero, päivämäärä) ja kentän pituus. Elementeille, jotka voivat saada rajoitetun joukon arvoja, on tarpeen määrittää pienin mahdollinen joukko vastaavia vakioita.
Joitakin vinkkejä skeeman validoinnin käyttöönotossa:
- saapuva asiakirja on vahvistettava mahdollisimman aikaisessa vaiheessa;
- Lähtevän asiakirjan vahvistus kannattaa tehdä välittömästi ennen ulkopuolisen palvelun soittamista;
- Jos puhumme kehitettävän järjestelmän vastauksen validoinnista, meidän on ymmärrettävä, että jos saimme oikean saapuvan asiakirjan (ja validoimme sen) ja olemme toteuttaneet sen käsittelylogiikan oikein, vastauksemme tulee myös olla oikea.
- jos korttityyppi on American Express, silloin numeron pituus on 15 merkkiä, muuten - 16;
- jos korttityyppi on Amerikkalainen Exptes, niin suojakoodin pituus on 4 merkkiä, muuten - 3;
- Kortin viimeinen voimassaolopäivä (kuukausi ja vuosi) on oltava suurempi kuin nykyinen (eli tulevaisuudessa).
Esimerkki: tarkistetaan, että kortin tyyppi on määritetty Visa tai MasterCard:
Luottokortin tulee olla MasterCard tai Visa
Katsotaanpa komponentteja Schematron-tiedosto.
Lausunnot ( väitteitä) on määritelty elementeissä väittää. Lausunnon tärkeä ominaisuus on testata- määrittelee XPath-ilmaus, joka voi palata totta tai väärä. Jos testilauseke palauttaa totta, niin lausuntoa pidetään pätevänä ( tavannut). Jos palautetaan väärä, niin vahvistusvirhe ja elementin sisältö tallennetaan väittää palautetaan viestinä tästä virheestä.
Säännöt ( säännöt) . Väitteet määritellään säännöissä. Sääntö sisältää määritteen yhteydessä, Johon sisältyy XPath-lauseke, joka valitsee vahvistetusta asiakirjasta solmut, joihin väitteitä sovelletaan. Jokaiselle solmulle sovelletaan vastaavassa elementissä kuvattuja sääntöjä sääntö.
lausekkeen käsittelyn seurauksena /emb:updateCreditCard/cmn:luottokortti yksi solmu palautetaan:
MasterCard
John Smith
10
2013
5285
johon sääntöä sovelletaan.
Jos säännölle on määritetty useita lauseita ja ne ovat kaikki vääriä, jokaiselle lauseelle palautetaan virhesanoma.
Voimme käyttää suhteellista kontekstia, esimerkiksi haluamme määrittää luottokortin vahvistussäännön riippumatta tapahtumasta, jossa korttia käytetään. Tätä varten sinun on määritettävä sääntö käyttämällä XPath ilme palaa luottokortti toiminnasta riippumatta, esimerkiksi näin:
Kuviot ( kuviot) . Säännöt määritellään kaavassa. Jokainen malli sisältää yhden tai useamman liittyvän säännön. Elementti kuvio sisältää yhden määritteen - nimi, joka määrittää vapaamuotoisen kuvauksen mallin sisältämistä säännöistä.
Schematron soveltaa kuvioita peräkkäin, kunkin kuvion sääntöjä sovelletaan myös peräkkäin.
Nimiavaruudet ( nimitilat). Nimiavaruudet kuvataan elementin avulla ns. Elementti ns sisältää kaksi attribuuttia: uri- URL, joka määrittää nimitilan ja etuliite- vastaava etuliite. Käytetään samalla tavalla kuin määrite xmlns järjestelmä.
Voit sitten käyttää etuliitettä säännöissä ja lausumissa cmn.
Kaava ( kaava) - juurielementti for Schematron, määritetty nimiavaruudessa http://www.ascc.net/xml/schematron.
Esimerkkejä
Validointi useiden kenttien sisällöstä riippuen:
Kortin numero ei kelpaa.
Sääntö voidaan kirjoittaa kauniimmin uudelleen - käytä mahdollisuuksia XPath kun määritellään sääntöjä:
Mastercard-kortin numerossa on oltava 16 numeroa.
Mastercardin suojakoodissa on oltava 3 numeroa.
Voit käyttää kohdassa esiteltyjä ominaisuuksia XPath 2.0:
Mastercardin numerossa on oltava 16 numeroa.
Päivämäärien vahvistaminen. Esimerkki sen tarkistamisesta, että määritetty päivämäärä on suurempi kuin nykyinen:
cmn:expiryYear > xp20:year-from-dateTime(xp20:current-dateTime()) tai
(cmn:expiryYear= xp20:year-from-dateTime(xp20:current-dateTime()) ja
Cmn:expiryMonth>=xp20:month-from-dateTime(xp20:current-dateTime()))
Elementin olemassaolon tarkistaminen:
Elementin olemassaolon tarkistaminen ja, jos se on olemassa, joidenkin sääntöjen suorittaminen:
Turvanumero on määritettävä
Tärkeä! Jos arvolle ei ole kuvattu sääntöä, tämä arvo vahvistetaan aina oikeaksi. Jos haluat rajoittaa mahdollisten arvojen joukkoa, sinun on luotava erillinen sääntö.
Esimerkki vahvistusvirheen palauttamisesta käyttämällä Schematron:
env: Palvelin
: Schematronin validointi epäonnistuu virheen vuoksi
Mastercardin suojakoodissa on oltava 3 numeroa.
Luottokortti on vanhentunut.
Liiketoimintasääntöjen käyttäminen validoinnissa Yksi validoinnin toteuttamistapa on määrittää validointisäännöt liiketoimintasäännöiksi. Tämän avulla voit määrittää vahvistussäännöt kerran ja käyttää niitä sitten useissa palveluissa. Säännöt voidaan puolestaan paljastaa verkkopalveluna, mikä tekee niistä helppokäyttöisiä E.S.B. tai BPEL-prosessit. Itse säännöt voidaan toteuttaa esimerkiksi käyttämällä Oraclen liiketoimintasäännöt, ja niitä voidaan käyttää paljastamaan ne verkkopalveluna BPEL- kääre tai vastaava Java API.
Ajatuksena on erottaa validointipalvelut juuripalveluista, jolloin validointipalveluita voidaan käyttää uudelleen. Tämän ratkaisun avulla voit myös muuttaa vahvistussääntöjä koskematta toiseen koodiin.
Vahvistusvirheiden palauttaminen synkronisesta palvelusta Tarvitaan mekanismi, jolla palautetaan tiedot validointivirheistä palvelun kuluttajille, mieluiten yksityiskohtaisilla tiedoilla siitä, mikä viestikenttä on virheellinen.Synkronisessa palvelussa palautusmekanismi perustuu käyttöön SOAP-vika. SOAP-vika sisältää 4 osaa:
- VersionMistmatch,
- Täytyy ymmärtää,
- Asiakas
- Palvelin.
Jos asiakkaalta saadun viestin sisällössä on virhe ja asiakkaan on korjattava tämä virhe, on palautettava Asiakas.
Palvelu voi myös palauttaa virheitä, joita ei ole kuvattu sen sopimuksessa, mutta virheen kuvaaminen helpottaa kuluttajan palvelun käyttöä ja mahdollistaa parempien virheenkäsittelyprosessien kehittämisen.
SOAP 1.1 mahdollistaa omien virhekoodien luomisen, jotka toteutetaan ns. pistemerkintä: client.invalidCreditCard nimiavaruudessa http://schemas.xmlsoap.org/soap/envelope/. Tämä johtaa kuitenkin törmäyksiin ja aiheuttaa yhteentoimivuusongelmia, joten se ei ole yhteensopiva WS-I -perusprofiili. Tällaisia päätöksiä tulee välttää.
Sen sijaan sinun on määritettävä virhekoodit niiden omissa nimiavaruuksissa. Voit esimerkiksi määrittää virhekoodisi virheellinen luottokortti samassa nimiavaruudessa kuin palvelu Käyttäjien hallinta.
Tärkeää: Vaikka omien virhekoodien määrittäminen omiin nimiavaruuksiin on yhteensopiva WS-I -perusprofiili, WS-I BP suosittelee vakiovirhekoodien käyttöä SOAP 1.1 ja lähettää tiedot tietystä virheestä kentälle yksityiskohta.
Validointivirheiden palauttaminen asynkronisesta palvelusta Asynkroninen palvelu ei voi palauttaa kuluttajalle mitään vastauksessa, koska vuorovaikutus asynkronisen palvelun kanssa perustuu kahteen yksisuuntaiseen viestiin: ensimmäinen sisältää alkuperäisen pyynnön, toinen on takaisinsoitto palvelusta, joka sisältää sen työn tuloksen.Sinun on käytettävä takaisinsoittoa virheen palauttamiseksi. On olemassa kaksi lähestymistapaa: palauta oikea tulos tai virhe yhdessä tavallisessa takaisinkutsussa tai määritä erilliset toiminnot virheiden palauttamiseksi. Toisen menetelmän avulla asiakas voi määrittää erilliset käsittelijät kullekin mahdolliselle virhetyypille.
Useimmissa tapauksissa toiminnon nimeä voidaan pitää virhekoodin vastineena ja vastaavan viestin sisällöllä voidaan välittää tarkempia tietoja virheestä (esim. vikamerkkijono Ja yksityiskohta). Esimerkki luottokortin käsittelypalvelun määrittämisestä asynkroniseksi:
Monitasoisessa validoinnissa huomioitavaa Validoinnissa voi olla mahdollisia suorituskykyongelmia (ilmeisesti vahvistusprosessi vie aikaa), joten sinun on seurattava puheluketjuja huolellisesti. Jos esimerkiksi käytämme palvelua luottokorttien vahvistamiseen ja korttitapahtuma kulkee palveluketjun läpi, joka käyttää tätä vahvistuspalvelua, se on ns. N kertaa, vaikka yksikin riittäisi.
Sinun on myös hallittava huolellisesti virheiden leviämistä ja tapahtumien peruutuksia (kompensaatioita). Esimerkiksi sisään BPEL-prosessi palvelusta A puhelupalvelut B Ja C. Palvelu B toimi oikein, ja kun soitit huoltoon KANSSA Tapahtui virhe. Tässä tapauksessa palveluun tehdyt muutokset on peruutettava SISÄÄN.
Ratkaisuksi näihin ongelmiin voidaan ehdottaa seuraavaa strategiaa: matalan tason palvelut suorittavat hyväksyttävän vähimmäisvalidoinnin ja korkean tason palvelut maksimaalisen validoinnin. Tässä tapauksessa korttimaksun käsittelyn esimerkissä maksuliiketoimintaprosessia toteuttava korkean tason palvelu kutsuu luottokortin validointipalvelun, ja matalan tason palvelut voivat rajoittua vain korttityypin kelpoisuuden tarkistamiseen. jokainen niistä, numeron oikea pituus ja viimeinen voimassaolopäiväkorttitoimintojen löytäminen tulevaisuudessa.
On syytä ottaa huomioon, että jos palvelu on kehitetty vain sisäiseen käyttöön, niin meillä on mahdollisuus hallita sitä ja meidän on taattava sen oikea toiminta, emmekä siis tuhlaa aikaa sen viestien validointiin. Jos meidän on esitettävä tällaiset palvelut ulkoiseen käyttöön, on parempi kehittää kääreitä ja toteuttaa validointi kääreissä. Silloin palveluita voidaan käyttää suoraan yrityksen sisällä, ilman validointia, ja ulkoisesti - kääreiden kautta validoinnilla.
Resurssit Tämä artikkeli perustuu luvun 13 sisältöön - Validoinnin rakentaminen palveluiksi kirjat Oracle SOA Suite -kehittäjäopas.Pidin viestistä -
Sivuston vahvistusvirheiden analyysi
Lopulta minulla oli vapaa-aikaa loputtoman tilaussarjan välissä ja päätin aloittaa blogini. Yritetään parantaa sitä validoinnin suhteen. Alla artikkelissa kerron sinulle, mitä verkkosivuston, html- ja css-koodin validointi on, miksi sitä tarvitaan ja kuinka verkkosivusto saatetaan standardien mukaiseksi tietyn esimerkin avulla.
Mikä on sivuston validointi?
Yksinkertaisesti sanottuna tämä on testi standardien noudattamisesta. Jotta mikä tahansa selain voi näyttää sivustosi oikein. Sivuston pätevyydellä ei ole suurta vaikutusta edistämiseen, mutta se ei varmasti pahenna tilannetta.
Erityinen esimerkki verkkosivuston sivun vahvistuksen läpäisystä
Otetaan ensimmäinen sivu, joka tulee vastaan verkkosivustollani - Base64-koodaus ja dekoodaus Java 8:ssa. Syötetään sivun osoite validaattoriin ja katsotaan tulosta:
Virheitä löydettiin tarkistettaessa tätä asiakirjaa HTML 4.01 Transitional! Tulos: 105 virhettä, 67 varoitus(ta) Kyllä, avautuva kuva on epämiellyttävä: yli sata virhettä ja 67 varoitusta - miten hakukoneet indeksoivat blogini ja ihmiset vierailevat siinä? Mutta älkäämme järkyttykö, vaan opetelkaamme käymään läpi validointi ja korjaamaan virheet. Eli ensimmäinen varoitus:
Jäsennystilaa ei voi määrittää! Validaattori voi käsitellä asiakirjoja joko XML-muodossa (asiakirjatyypeille, kuten XHTML, SVG jne.) tai SGML-muodossa (HTML 4.01 ja aiemmat versiot). Tämän asiakirjan osalta käytettävissä olevat tiedot eivät riittäneet jäsennystilan määrittämiseen yksiselitteisesti, koska: MIME-mediatyyppiä (text/html) voidaan käyttää XML- tai SGML-dokumenttityypeille Tunnettua asiakirjatyyppiä ei voitu havaita Ei XML-ilmoitusta (esim. löytyy asiakirjan alusta. XML-nimiavaruutta (esim.) ei löytynyt dokumentin juuresta. Oletuksena validaattori palaa SGML-tilaan. Varoitus: DOCTYPE:tä ei löytynyt! Tarkistetaan oletusarvoisella HTML 4.01 Transitional Document Type -asiakirjatyypillä. Tästä asiakirjasta ei löydy tai tunnistettu DOCTYPE-ilmoitusta. Tämä tarkoittaa yleensä sitä, että asiakirja ei ilmoita asiakirjatyyppiään yläreunassa. Se voi myös tarkoittaa, että DOCTYPE-ilmoitus sisältää kirjoitusvirheen tai että se ei käytä oikeaa syntaksia. Asiakirja tarkistettiin käyttämällä oletusarvoista "varaus" asiakirjatyypin määritelmää, joka muistuttaa läheisesti "HTML 4.01 Transitional". Se on sama. Ja korjaus on yksinkertainen: lisää tunniste sivun alkuun:
Tarkastellaan, mitä olemme tehneet, ja katsotaan, että tällä yhdellä tunnisteella poistimme 105 virhettä ja 3 varoitusta! Nyt meillä on enää 64 varoitusta jäljellä. Aloitetaan niiden purkaminen yksitellen.
Varoitus: style-elementin type-attribuuttia ei tarvita, ja se tulee jättää pois. riviltä 5, sarakkeesta 1; riville 5, sarake 23 /x-icon">↩↩↩↩↩A Tämä tarkoittaa, että tyylielementti ei tarvitse type-attribuuttia - se on tarpeeton. Sivulla on kaksi tällaista kommenttia. Samanlainen varoitus koskee JavaScriptiä:
Varoitus: Type-määrite on tarpeeton JavaScript-resursseille. Riviltä 418, sarakkeesta 1; riville 418, sarake 31 ↩↩$(doc Meillä on 8 tällaista virhettä. Poistamme nämä attribuutit ja hurraa - vielä 10 varoitusta vähemmän!
Virhe: CSS: tausta: Lineaarigradienttifunktion ensimmäisen argumentin tulee olla top, ei top. Rivillä 39, sarake 61 0%,#E8E8E8 100%);↩ border-r Seuraava virhe on, että lineaarisen gradientin ensimmäisen argumentin tulee olla to top, ei top. Me korjaamme sen. Seuraava virhe:
Virhe: CSS: Jäsennysvirhe. Riviltä 65, sarakkeesta 13; riville 65, sarakkeen 16 marginaali: 0 auto;↩pad Tässä olen kommentoinut css:tä väärin. Sinun tarvitsee vain poistaa tämä rivi. Tai kommentoi /* ja */ eri tavalla. Tein sen kuten ennenkin.
Virhe: CSS: @import eivät ole sallittuja muiden kelvollisten käskyjen jälkeen kuin @charset ja @import.. Rivillä 88, sarakkeessa 74 0,600,700,300);↩@import url(// Nyt on tuontivirhe. Siirretään nämä rivit aivan tiedoston alkuun ja se katoaa.
Virhe: Väärä arvo _blanc attribuuttikohteeseen elementissä a: Varatun avainsanan tyhjää käytetty. Riviltä 241, sarakkeesta 218; riville 241, sarakkeeseen 295 evästeet..php?id=98" target="_blanck" style="display: inline;">Tässä Seuraavaksi emme pidä target-attribuutin arvosta, meille kerrotaan, että tarvitsemme käyttää "tyhjää" ilman alaviivaa edessä. Poistetaan se.
Virhe: End tag li nähty, mutta siinä oli avoimia elementtejä. Riviltä 379, sarakkeesta 2; riville 379, sarake 6
- ↩ ↩↩
↩
↩↩↩↩
Piditkö?
Napsauta painiketta, jos pidit artikkelista, tämä auttaa meitä kehittämään projektia. Kiitos!