- idet, jeg gerne vil diskutere emnet med nogle af E's lidt tungere drenge. Naturligvis skal alle være mere end velkomne til at deltage, men jeg skal ikke skjule, at jeg meget håber, brugere som roenving, erikjacobsen og arne_v blander sig. Det, jeg gerne vil forsøge at afklare, er de principielle forhold omkring brugen af specialtegn i JS - herunder i RegExp :)
Problemstilling: En streng skal undersøges for, om den indeholder et eller flere 'bogstavs-tegn'. Hvis forskellige europæiske, lokale tegn skal inkluderes er et mønster som: /[a-z]+/gi - naturligvis ikke nok.
Ofte ses derfor mønstre som: /[a-záàãââæåçéèêëìíîïñòóôõöøùúûüýÿ]/gi
Jeg fik den idé, at prøve at undersøge, hvor disse tegn 'lå' og fandt ud af, at oktal-tal spannet fra \337 til \377 dækker tegnene: ßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
Hvis vi i første omgang squider på divisions tegnet, kunne et mønster derfor se sådan ud: /[a-z\337-\377]+/gi - hvilket jeg personligt finder lidt mere 'sexy' :)
roenving og jeg kom så til at diskutere, om man nu også kan stole på, at tegntabellen altid vil match de ønskede tegn eller ej. Min påstand var, at det ønskede match altid vil ske, hvis tegnsættet i dokumentet er iso-8859-1 ... men er det korrekt?
Naturligvis er det altid vigtigt at vide, hvad der virker og hvad der ikke virker. Den diskution, jeg ønsker i denne tråd, omhandler dog ikke den problematik :)
Hehe ... så fik jeg zq følgende at vide, da jeg ville oprette spørgsmålet: "...?" er ikke med til at beskrive dit problem, så formuler venligst en bedre titel.
Ikke at jeg aner meget om emnet. så lægger bare en kommentar for at følge tråden. Samt har et enkelt lille forståelses problem.. Ole > "oktal-tal spannet fra \337 til \377" er det de samme som &# 337 til 377 ? (Oktal...lyder som noget i benzin ..*G*... Mon ikke det har noget med 8 at gøre ... det må jeg kunne finde på wiki)
-- hvilket gav nogle ganske enkelte karakterer, som man kan benytte på dansk i spannet forbi 377 (f.eks. IJ !-)
-- ellers ser det ud til at 0300 til 0377 dækker ganske godt !o]
>>jesper-moeller
Oktal-tal er tal baseret på 8 cifre (eller base-8, eller hvad kan finde på af betegnelse !-), ligesom decimal er baseret på 10, binær på 2 og hexadecimal på 16 ...
-- i javascript har oktal-tal en helt speciel notation, et tal som ikke indeholder 8 eller 9 og har et foranstillet 0 tolkes som 8-tals-baseret, så det ovenstående 0300 betyder 192 !o]
-- ligeledes tolkes 'tal', som starter med 0x og indeholder 0-9a-f, som hexadecimale, prøv f.eks.
-- og jeg glemte, at jeg havde prøvet med simpelthen at ændre den benyttede tegntabel på dokumentet, men gad ikke mere, da jeg nåede til iso-8859-6, men checkede også -11 !-)
Nej, ligesom 10 betyder ti fordi det bageste tal betyder enere og det forreste tiere, så betyder base-8 at det bageste tal er enere (8^0), næstbageste 8'ere (8^1), tredjebageste 64'ere (8^2) ...
-- nullet foran er bare javascripts måde at kende forskel på oktal-tal og almindelige 10-tals ting !-)
Hehe ... ja, jeg tænkte zq da nok, jeg skulle rende ind i 'et par flamske', Jes ;D
Da man ikke kan komme længere i tegntabellen med oktal-tal, kunne man tage fat i hex-tal og unicode. På den anden side er langt de fleste tegn, der forekommer i danske sammenhænge, dækket med det omtalte span, så i langt de fleste tilfælde vil den efter min smag være tilstrækkelig.
I en 'skarp' situation, hvor f.eks. et navn skal valideres, er det nok smartest at lave en 'overfladisk' test på klienten - og så lave en mere stringent på serveren - hvor man i hvert fald i PHP kan sætte forskellige tegnsæt på RegExp-motoren. Nuvel ... det var den slags praktiske løsninger, der var emnet. Det er mere det principielle/teoretiske aspekt i 'problemet', der interesserer mig ;o)
roenvig >> Ja... man skal nok lige passe lidt på med hvor man bruger hvad....*G*....skulle bare lige finde et hurtigt letgenkendligt eksemple .....sku nok ha tilføjet det med html'en...
Forøvrigt... Tak for forklaringen...
Og undskyld til ole for at mase mig ind i hans tråd...*S*
-- jeg prøvede lige at forøge den ydre løkke til 64 blokke, og det er der intet galt i, så støder man ind i mange sjove tegn, græske, kyrilliske, arabiske, thailandske oma. !-)
-- men nok ikke så brugbart i vesteuropæiske sprog ...
-- og jeg er iøvrigt enig med dit udsagn om client-side over server-side !o]
-- i alle positionsbestemt tal-systemer (hvilket vist kun er dem, vi har pillet ved i denne tråd !-) kan man skrive lige så store tal, det skal være ...
-- det bliver måske lidt upraktisk, hvis man f.eks. skal skrive store tal binært, men det virker stadig !o]
-- i hvert fald afspejler det binære talsystem den grundlæggende måde en computer fungerer på: at man arbejder med to tilstande, tændt eller slukket !-)
-- oktal og hexadecimal er så hhv. 3 og 4 binære tegn forkortet, men stadig umiddelbart læselige, hvilket et system med 256 forskellige ikke ville være, selvom det ville afspejle den basale samlingsenhed, byte ...
Hex-tal er så praktiske, da der skal nøjagtig 2 til at give en byte (og derfor benyttes de til farve-angivelser en masse steder !-)
-- hvorfra ideen til at give oktal-tal specialbetydning i javascript er kommet, er jeg ikke i stand til at forklare ...
"Fordelen ved det oktale talsystem fremfor det hexadecimale er at man ikke skal 'opfinde' nye cifre, medens fordelen ved det hexadecimale talsystem er at det er endnu mere kompakt end det oktale." (wiki)
(er vel også lettere at sige 013 + 064 end #3a55e1 + #ff034a *G* ??? )
Tjah, men det ændrer ikke det principielle, for når du så skal gange 056 med 2 kan du blive forvirret af, at resultatet er 112 i decimal, 0xac i hexadecimal og 0134 i oktal ...
Jesper >> uha ... pas nu på (20/09-2005 18:14:38)! ;o) Når det gælder farveblanding, er der to måder at beregne resultatet: Additiv farveblanding ... gælder for lys (herunder PC-skærme) Subtraktiv farveblanding ... gæsler for blanding af faste/flydende farver (kendes fra tryk).
Blander du f.eks. lyset fra en gul og en blå lampe, får du hvidt lys. Blander du derimod gul og blå malig får du grøn maling ud af det.
En teaterscene, der skal virke som belyst med hvidt lys, ville se brækværdig kedelig ud, hvis den faktisk blev belyst med hvidt lys. Den vil altid blive belyst med forskellige farver, der sæmper og/eller fremhæver kostume-detaljer og forskellige områder af scenografien - samtidig med, det blander til hvidt.
Derfor gælder det virkelig om at holde tungen lige i bukserne som lysdesigner. Mens man blander lys, skal man tænke additivt - men når refektionen af der, hvor det rammer, skal beregnes, skal der pludselig tænkes subtraktivt!
Nå, men det er jo en helt anden sag, vi kunne sludre længe om i et helt andet forum :)
roenving >> Jeg aner heller ikke, hvor oktaltallene får så stor en plads i JS, men man skal nok tilbage til Netscape2.0, hvor JS blev introduceret - og meget så anderledes ud. Jeg kender ikke nok til Java, til at vide, hvormeget oktaltal bliver brugt dér. Sun og NS indgik jo en aftale om gensidig understøttelse - så om oprindelsen evt. kan ligge der ... hmmmm(?)
ole / roenvig >> Ved godt man ikke kan lægge farvene sammen på den måde...*GS* ... men nu var farvekoderne lige det første hex exempel jeg kom i tanke om.... men ja dårligt exempel .... (og enu dårligere hevet iland med malingen *G*)
ole >> du glemte en variation. fortætter du farvet gult og blåt lys dannes der magenta ..... ;-)
Ja. Lys og farver er ganske spændende emne....men nok ikke i denne tråd .. *G*
Nej, Jesper ... som gammel lyd-/lys-tekniker, må jeg desværre belære dig. Gul og blå er komplimentær-farver og danner derfor hvid ved additiv farveblanding. Gul ligger mellem rød og grøn - og derfor diamentralt overfor blå :) Magenta opnås ved blanding af blå og rød.
ole >> Jamen så bliver det jo lidt sjovt at "belære" en lysmand en smule...*GGG* Nu denne denne tråd jo ikke om lys og farver ... Så har lagt et svar til dig her ---> http://www.eksperten.dk/spm/650002
En deltager i denne debat rejste spørgsmålet om hvad ideen med oktal systemet er. Kunne det ikke have noget at gøre med at 1 byte = 8 bits ? :) Eller er det bare et tilfælde.....?
Et lille koriosum (at stave er sjovt) er at fly's transponder box (bruges til radar identificering) faktisk kun bruger tallene 0-7 til at lave en 4 ciffer kode - altså ialt 4096 koder. Hvorfor vælge denne funktionalitet hvis ikke der er fordele i forhold til 0-9 ?...men hvad er fordelene....Nå way off topic, bare strøtanker :)
Hmmm ... OleBole, vi må vist slå fast, at den høje pande primært skyldes aldersbetinget håraffald ........ læn dig ikke tilbage i forventning om en Nobelpris!
Jeg ved ikke, om Jesper og Jes stadig læser med (jeg havde faktisk selv glemt spm'et), men i så fald vil jeg gerne høre jeres mening. Personligt mener jeg, at Johan bør have alle 100 kylet lige mellem øjnene ;o)
Oktaltal er ældre en PC'en, så det er ikke derfor. Andre talsystemer bruges ofte, fordi de er mere kompakte. Ved mere kompleks matematik bruges af og til meget specielle talsystemer, når de almindelige - og deres tilhørende regnemetoder - ikke slår til ... f.eks. 'komplekse tal'
Men da \W jo er det præcis modsatte af \w er det jo også afhængig af den konkrete regexp-motor !-)
-- og i IE indeholder \w a-z, 0-9 og _, mens det i Geckoerne også indeholder alle de tegn, som indgår i det konkrete locale !o]
>>johan.o 11/11-2005 00:28:10 Da oktal-tal er tal, der er baseret på 3 bit er der vel ingen bestemt sammenhæng til 8 bit ?-)
-- og den oprindelige ascii (American Standard Code for Information Interchange !-) tabel indeholdt kun 7 bit information (128 karakterer, hvoraf de 32 nederste var kontrol-karakterer), fordi al kommunikation var så usikkert, at der altid var brug for en paritets-bit, man kunne forestille sig at det samme var tilfældet med radar-koden !o]
>>olebole: 'Oktaltal er ældre en PC'en, så det er ikke derfor.' >>roenving: 'Da oktal-tal er tal, der er baseret på 3 bit er der vel ingen bestemt sammenhæng til 8 bit'
PC teknologien 'opfandt' naturligvis ikke oktal systemet så langt er jeg med :), men det er da et pudsigt sammenfald at oktal systemets base er 8 og længden på en byte er 8. Bare vent den 8/8-8888 klokken 8 går det helt galt :) he he
Med hensyn til mit regexp forslag så kan det naturligvis ikke overraske at IE også skiller sig ud på dette punkt...tsk tsk...men havde nu også selv svært ved at 'accepterer' at det skulle være så enkelt :)
Det jeg fandt kunne være interessant er bemærkningen til \w :
Matches any word character. Equivalent to the Unicode character categories [\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nd}\p{Pc}]. If ECMAScript-compliant behavior is specified with the ECMAScript option, \w is equivalent to [a-zA-Z_0-9].
Så her er defineret præcis hvilke typer af bogstaver \w bør indeholde men så kommer ECMAScript-compliant i vejen.....eller ?
Hm, har nu læst øjnene trætte med unicode normalization og canonical :)
So far :
ã er et 'canonical' som består af ~ (\u007E) og a (\u0061)
reg_exp /[a-z]*\u007E[a-z]*/ matcher f.eks. jhg~fgh men kan jeg/vi enten lave en 'normalization' af strengen før reg_exp 'køres' eller få reg_exp til at forstå at 'tegn' kan bestå af to unicode værdier ?
Jeg har fundet en java-applet der laver noget der ligner :), her :
Knappen 'Test' åbner denne applet men er det 'konverterbart' til Jscript ?....'I doubt it :)'
roenving: jeg kom ikke rigtigt videre med ECMAScript-compliant, jeg ved ikke om din bemærkning skulle sætte nogle ting på plads for mig eller om det skulle være en hjælp til at komme videre, men du skal da være velkommen til at uddybe bemærkningen hvis der er noget jeg har brug for at vide :)
Ups, dette spørgsmål har jeg helt glemt. Kan jeg ikke lige få en håndfuld svar fra deltagerne i tråden? Så vil der blive delt lige over med tak for snakken ;o)
"Tjah, der er jo nogen [...]" >> Jaja, træd bare i det grædende øje (men pinligt er det zqi)! ;D
- og fortsat god Pinse til dig også =)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
