ASCII vs. ANSI

Jeg tror ikke at jeg vil kalde det for den udviddede ascii tabel, for tegnene ligger ikke på samme pladser...  Men 8bit istedet for 7 er rigtigt nok

ansi står for : American National Standards Institute og er en forening som har lavet flere forskellige standarder(Ansi C blandt andet).

I de "gode" gamle DOS dage, brugte man ANSI.SYS til at få skærmen til at følge ANSI standarden. Da kunne man bruge en sekvens af ASCII karaktere til beskrive hvordan man at skærmen skal opfører sig. (se http://www.computerhope.com/ansisys.htm)

Håber det hjalp... :-)

ASCII tegnene er alle sammen tegn som kun benytter de 7 bit ud af 8 mulige bit i en byte. At det forholder sig sådan er at det ikke altid har været sådan at man faktisk brugte 8-bit bytes i en computer. Det er altså gammel historie.

Efter at det blev almindelig med 8 bits pr. byte, havde man pludselig mulighed for at udvide den originale ASCII tabel med yderligere 128 tegn, nemlig dem som svare til at den øverste bit er sat til ’1’.

Desværre kunne man ikke blive enige om hvordan dette skulle gøres, og der kom derfor adskillige forslag, de såkaldte codepages, eller tegntabeller, som enhver DOS-connaisseur kender til; Stort set hvert land havde brug for sin egen codepage for at kunne benytte sine egne specielle tegn, Danmark har således mulighederne for at bruge codepage 850 og 865 som indeholder ’æ’, ’ø’ og ’å’ (samt deres uppercase-varianter).

Dette gav selvfølgeligt en slags kaos, som vi nu om dage forsøger at løse ved at indføre unicode; En tegntabel som samler hele verdenens alfabeters tegn i een tabel.

”ASCII” står for ”American Standard Code II” og er en gammel standard. Denne er senere blevet udvidet af ANSI som står for ”American National Standards Institute”. Det er altså begge to standarder som er udviklet af Amerikanske standardiserings institutioner (hvilket formentligt forklarer hvorfor at de har glemt at inkludere nadre nationaliteters specielle tegn)! ANSI er ikke et synonym for ASCII, men derimod en udvidelse af denne. ANSI samlede vist alle de eksisterende codepages og systematiserede dem ved at nummerere dem (850 og 865 til Norden).

GetDefault() oversætter altså blot i forhoild til den codepage som er din aktuelle computer bruger.

Typen ”string” benytter unicode internt. Når du derfor har et char- eller et byte-array og vil omdanne det til en string:

byte[] bArray = blah-blah
string BlahBlah = Encoding.Default.GetString(bArray);

har systemet behov for at vide hvilke tegn de enkelte bytes svare til i den lokale codepage for at det kan udvælge den rigtige unicodeværdi. Og selvfølgeligt også den anden vej med din Encoding.Default.GetBytes(blablabla).

Imidlertid er det jo slet ikke sikkert at dine bytes stammer fra en PC med den codepage som du benytter. Det kunne f.eks. sagtens tænges at den var UTF-8 encoded i stedet. Hvis du blot brugte brugte Default på sådanne tegn ville din streng ende med at være helt forkert. I dette tilfælde skulle du altså bruge:

Encoding.UTF8.GetBytes(blablabla);

- Niels

Hej Niels! Tak for dine lange forklaringer - de hjalp lidt på forståelsen :)

Men der er stadig nogle ting jeg er i tvivl om...

1. Hvad er forskellen på ANSI og unicode ? findes der både codepages for ANSI og unicode eller?

2. Hvad er forskellen på UTF7/8 og ANSI...?

Mvh. PabloPablo

ASCII : 1 byte/bogstav, kun engelske bogstaver
ISO-8859-1/IsoLatin1/ANSI/CodePage 1252 : 1 byte/bogstav, alle vesteuroæiske bogstaver
Unicode : 2 byte/bogstav, alle bogstaver
UTF-8 : 1 eller 2 byte/bogstav (ASCII som 1 byte, resten som 2 bytes), alle bogstaver

ovenstående er lidt overforsimplet, men til gængs programmering er det stort set
det du behøver vide

ok, tak arne...synes nu godt at det kunne have været lidt mere pædagoisk, at div. standarter, samt færre af dem :)

at = altså, arne læg et svar :)

ja - det er lidt sørgeligt at vi for 20-30 år siden kæmpede med ÆØÅ og at vi
nu stadigvæk kæmper med ÆØÅ.

svar

hov Arne, fik egentlig ikke fat i...er ANSI kún codepage 1252...eller?

ISO-8859-1, IsoLatin1, ANSI, CodePage 1252 er det samme

[næsten - der er vist lidt forskelle mellem de 2 første (ISO standard) og de
2 sidste (Microsoft), men de har ikke den store praktiske betydning]

http://www.lookuptables.com/ den tabel nederst som har overskriften "Extended ASCII" er det ANSI / Codepage 1252, ikke sandt?

Nej

det ligner CodePage 850 eller sådan noget

Det er nu codepage 865.

850 udemærkede sig ved at have samtlige nordiske specialtegn, mens 865 udemærkede sig ved at have ramme-tegnene.

ok! jeg har fundet dette link, men kunne godt tænkte mig, at finde en tabel, hvor alle tegn var med i, 0-31 mangler i denne.

Ved i hvor jeg kan finde sådan en?

hov, linket manglede vist lige :) http://www.kostis.net/charsets/cp1252.htm

0-31 er ikke printbare tegn som bruges til "styring"

Det kan sagtens være 865 - jeg kan ikke huske forskellene på 437, 850 og 865.

Jeg kunne bare se at det var ikke 1252.

arne_v> Jeg havde helt glemt codepage 437, som er den amerikanske. Denne indeholder faktisk ’æ’, ’Æ’, ’å’ og ’Å’, men mangler af en eller anden mystisk grund ’ø’ og ’Ø’. Hvis man forsøgte at skrive disse to tegn med 437 får man hhv. et cent-tegn og et yen-tegn.

http://www.lookuptables.com/

- er altså 437, hvilket man f.eks. kan se på at tegn 157 er et yen-tegn i stedet for et ’Ø’ (tegn 155 mangler af en eller anden grund i tabellen). Pga. denne mangel har det kun været 850 og 865 som skulle bruges her i det danske.

Forskellen på 850 og 865 er, at 850 indeholder flere nordiske specialtegn end 865, men at 865 til gengæld indeholder flere ramme-tegn end 850. 865 ligner faktisk mere 437 end den ligner 850. Jeg huskede lidt galt da jeg antydede at 850 ikke havde ramme-tegn. Sagen er den at ramme-tegn kommer i to varianter: En med enkelt-striber (f.eks. tegn 192 fra linket) og en med dobbelte-striber (f.eks. tegn 204). Men så var der også de tegn som kombinerede enkelt- og dobbelt-striber (som f.eks. tegn 199). Det var netop disse tegn som 865 havde med, mens at 850 i stedet havde nogle ekstra nordiske tegn på de pladser; I 850 var tegnet 199 således et ’Ã’. Der var engang i gamle dage (er det virkeligt ikke mere end 10 år siden?!) hvor de fleste programmer havde et DOS-baseret ”GUI” og hvor man brugte ramme-tegnene til at tegne pæne skærmvinduer med; Den gang kunne man hurtigt se om folk brugte 850 eller 865 idet at der blev vist skrald der hvor enkelt- og dobbelt-stribede rammer skar hinanden.

pablopablo> Dit seneste link viser godt nok ikke tegnene under 32, men dem har du jo i www.lookuptables.com (tegnene 0-127 har altid været de samme uanset codepage). Disse tegn bruges ganske rigtigt som styretegn - f.eks. er tegn 13 det samme tegn som ’\n’. Dette betyder imidlertid ikke at de ikke også har en grafisk repræsentation. Tegnet 13 er således et musiknode-tegn.

sikke en masse i ved om alle de tegn :) det var faktisk det du skrev til allersidst Niels, som jeg søgte bekræftigelse for, så tak for det ;) Jeg søger en tabel med alle tegnene også dem som går fra 0-31 idet jeg benytter hele skalaen ved rs-232 komm...men det findes måske ikke...? burde de ikke være til at finde på microsoft eller...?

normalt vil 13 slet ikke blive vist som et tegn men derimod flytte cursoren
til starten af linien.

pablopablo> Her kan du se den grafiske repræsentation af tegnene under 32:

http://en.wikipedia.org/wiki/Code_page_437

Ironisk nok er det et af linkene fra dit første URL ;^)

Arne har ret når han fortæller at det at skrive ’\n’ til et vindue kun vil resultere i at cursor bliver placeret i starten af linjen, og at du ikke får musiknode-tegnet. Så vidt jeg husker, var den eneste måde man overhovedet kunne udnytte de grafiske repræsentationer, faktisk når man skrev direkte til skærmhukommelsen.

Blev lige i tvivl omkring....nu hvor jeg benytter Encoding.Default.getBytes(...)

Idet default ref. til den aktuelle ANSI codepage, vil den så ændre sig hvis/når programmet køre på en anden computer...eller bliver den information gemt et sted? code page 1252 er nemlig den, som passer og det er jo derfor gerne den som altid skal benyttet...:)

hvis du kigger på Encoding.Default kalder den CreateDefaultEncoding som er denne metode

internal static Encoding CreateDefaultEncoding()
{
      int num1 = Win32Native.GetACP();
      if (num1 == 0x4e4)
      {
            return new CodePageEncoding(num1);
      }
      return Encoding.GetEncoding(num1);
}

Win32Native.GetACP(); består af dette interop

[DllImport("kernel32.dll")]
internal static extern int GetACP();

Og i følge MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_21bk.asp), så vil funktionen returnere den valgte ANSI codepage på den pågældende computer. Dvs, at ja, det kan du godt komme ud for vil ændre sig hvis du kører koden på en anden computer

hhm, det lyder jo ikke så godt, hvordan kan jeg sikre at det altid er codepage 1252 som benyttes?

ja... det er sq svært at se skoven for bare træ'er, hva' :P

:)

hvad er det frameworket gør? Jo, den får fat i encoding-nummeret, gemmer det i en variabel og kalder Encoding.GetEncoding(nummeret);

Mon ikke du kan gøre det samme?

Encoding enc = Encoding.GetEncoding(1252);
enc.GetBytes(...);

Cyberfessor, ja sry...du har helt ret ;) tak for det!

Jeg har dog stadig et spg. jeg jeg meget håber i kan hjælpe mig med...

Programmet jeg arbejder på, kan både modtage og sende data via com-porten...udfra det data som modtages (fra en maskine), bliver der bla. tegnet tre grafer...

Måden hvorpå jeg modtager data på før ser således ud:

...

for(int i=0; i<modtagetData.Length; i++)
                {
                    //Omregner decimalværdien til UNICODE-tegn
                    data += new string((char)modtagetData[i],1);
                }
...

og måden hvorpå jeg fik tegnet div. grafer på var således :

char[] wbcgraf = eo.wbcGraf.ToCharArray();

for(int i = 0; i < 128; i++)
                        {
                            yGrafValue1[i] = wbcgraf[i]-32;
                        }

og det har faktisk altid fungeret fint! graferne er altid blevet tegnet korrekt på denne måde, men nu hvor jeg er blevet lidt mere bevidst omkring codepages mv...så ville jeg også gerne sikre mig at dette altid var det samme og kørte på copepage 1252, som nu benyttes når data sendes, og det virker helt fint...

derfor prøvede jeg er lave modtagelse om til dette :

//Sætter codepage til 1252
                Encoding enc = Encoding.GetEncoding(1252);

                //Konvertere byte arrayet om til en gyldig string
                data += enc.GetString(modtagetData);

og når jeg kigger på data-variablen via quick-watch under debuging, så ser det også meget fint ud! det eneste jeg ikke kan få til at passe, er hvordan jeg får konveteret div. tegn som repræsentere div. grafer til heltal således at de bliver tegnet korrekt...

Først prøvede jeg at lade den oprindelige kode blive stående, men det gjorde at graferne kom til at se MEGET mærkelige ud...derfor prøvede jeg dette :

Encoding enc = Encoding.GetEncoding(1252);
                        char [] wbcgraf = enc.GetChars(enc.GetBytes(eo.wbcGraf));

                        for(int i = 0; i < 128; i++)
                        {
                            yGrafValue1[i] = wbcgraf[i]-32;
                        }           

Men det ændrer faktisk ikke på noget...? Så det er her jeg håber I kan fortælle mig hvad jeg gør galt...?-)

Mvh. PabloPablo

Hejsa, jeg har oprettet denne nye tråd : http://www.eksperten.dk/spm/610049, så der er lidt points at hente...har desværre ikke så mange, at gøre godt med, men håber at i vil hjælpe mig alligelvel :)