Avatar billede pablopablo Nybegynder
15. april 2005 - 16:27 Der er 49 kommentarer og
1 løsning

Codepages og unicode

hejsa...

Jeg arbejder på et program, som både modtager og sender 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;
                        }           

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

-------------------------------------------------------

Grunder til at jeg roder lidt rundt i det, er pga. at jeg ikke ved / har ikke noget dokumentattion på den maskine, hvad den reelt sender i...

2. Men nu hvor jeg er i stand til at modtage data korrkte ved brug af : ...new string((char)modtagetData[i],1); det er jo UNICODE, kan jeg så også blot bruge Encoding.Unicode.getBytes(... og så altid være sikker på, at den vil sende det samme uanset på hvilken computer i verdenen programmet køre på, eller vil det være bedre hvis jeg bruger (som det faktisk køre med lige nu) :

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

Jeg har sammenlignet data som bliver sendt fra maskinen til et analyse-program som modtaget i unicode format....og fra min winform (som sender via codepage 1252 lige nu) til analyse-programmet og de sender præcist de samme data...

Unicode bygger det ikke også på codepages ligesom ANSI men fylder blot forskelligt, eller er jeg helt galt på den?

Ja, som i sikkert kan fornemme er jeg lidt forvirret i denne helt "tegn-verden"...

Men håber I kan gøre det mere klart for mig :)

Mvh. PabloPablo
Avatar billede arne_v Ekspert
15. april 2005 - 16:53 #1
Du kan vel lave:

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

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

som du altid har gjordt. Du bruger Encoding til at konstruere den String. Men
hvordan den er konstrueret påvirker jo ikke hvordan den kan bruges.
Avatar billede arne_v Ekspert
15. april 2005 - 16:54 #2
Men det vil nok være kønnere med:

for(int i = 0; i < 128; i++)
                        {
                            yGrafValue1[i] = eo.wbcGraf[i]-32;
                        }
Avatar billede pablopablo Nybegynder
15. april 2005 - 21:50 #3
Hej arne! Jeg ved godt at stringen kan bruge til de samme ting ligegyldigt encodingen, men grunden til at spørger hvordan jeg skal gøre, er jo pga. at når jeg modtager data via 1252, så kan jeg ikke bare tegne graferne som ovenstående idet graferne bliver helt forkerte(der til skal det selvfølglelig nævnes at al modtaget data ser fint ud under debug...)....detfor tænkte jeg, at der måtte være en anden/rigtig måde at konvertere tegnene til int, idet graferne ser meget mærkelige ud hvis jeg bruger den gamel metode...?

Derudover vil håber jeg meget du vil prøve at svare mig på følgende :

1. Lige nu modtager programmet i unicode, konverterer unicode til int til graferne og det virker fint, men jeg sender via codepage 1252...og jeg synes selv at det giver mest mening at der modtages og sender via samme encodig...det var et forsøg på at få det hele til at køre via 1252...

2. Unicode bygger det ikke også på codepages ligesom ANSI, men fylder blot forskelligt, eller er jeg helt galt på den? grunden til dette spg. er pga. jeg i noget dokumentaion skal beskrive hvad programmet sender.

3. Vil du mene det er ligegyldigt for modtageren om programmet sender via 1252 eller unicode?

4. Hvis winformen sender unicode eller ANSI 1252, vil det så i begge tilfælde altid være de samme tegn som sendes over mediet, uanset hvilken computer/i hvilket land det kører? Altså om de hver i sig altid altid vil sende de samme tegn som de gør nu på min maskine...
Avatar billede arne_v Ekspert
15. april 2005 - 21:54 #4
Hvis du modtager unicode (UTF-16 encoded) så kan du jo ikke fortælle
.NET at det er CodePage 1252 !?
Avatar billede pablopablo Nybegynder
15. april 2005 - 22:31 #5
men det ved jeg jo heller ikke om det reelt er, jeg tror det er 1252, derfor prøvede jeg at det til cp1252 når jeg sender det og det virker fint...
Avatar billede pablopablo Nybegynder
15. april 2005 - 23:41 #6
kan du svare på spg. 2,3 og 4?-)
Avatar billede arne_v Ekspert
15. april 2005 - 23:47 #7
re 2)

nej - unicode har ikke codepage conceptet

re 3)

nej

re 4)

ja
Avatar billede pablopablo Nybegynder
15. april 2005 - 23:53 #8
hej igen, det er lige gået op for mig at det IKKE ak nvære codepage 1252 :) havde ikke studeret alle div. koder ordentlig...cp 1252 koder er fortøbende fra 32 til 126...men herfra begynder der at komme nogle gevaldige spring i koderne...helt op til over 8000, det forklare jo hvorfor graferne så så sjove ud...:)

Drop de foregående spg. om svar mig heller på dette...hvis du nu skulle lave et program som kunne modtage det data jeg sender, er det så fint nok at fortælle at det er Unicode (little endian)...er det helt entydigt hvad det så er?

Er det ikke også korrekt, at det er ligegyldigt hvordan en string er encodet før den sendes, blot den ikke encoder noget som fylder 2 bytes til 1byte...det afgørende er jo, at modtageren encoder det korrekt for at få det samme visuelle resultat ud af det og afsenderen har...pga. bits'ne / mønsteret som sender igennem ledningen er jo præcis den samme uafset encodingen, ikke sandt...?

Mvh. PabloPablo
Avatar billede arne_v Ekspert
15. april 2005 - 23:57 #9
codepage 1252 går kun fra 0 til 255

Unicode en entydigt - unicode er hverken little eller big endian

Unicode i UTF-16 encoding kan være enten little eller big endian
Avatar billede arne_v Ekspert
15. april 2005 - 23:58 #10
encoding er en oversættelse mellem bits og betydning
Avatar billede pablopablo Nybegynder
16. april 2005 - 00:15 #11
jeg synes dette er modsigende : dit svar # 3 "nej" og "encoding er en oversættelse mellem bits og betydning"...jeg er efterhånden fuldt ud med på hvad encoding betyder :) Og derfor kan jeg ikke forstå at det ikke er ligegyldigt, hvilken encoding man benytter ved forsendelse...? Siger du nej til spg. 3 pga. unicode og 1252 tegnene fylder forskelligt? ellers forstår jeg det nemlig ikke...?

http://www.kostis.net/charsets/cp1252.htm tjek tegn 126 og nedefter der er flere hvor koden er over 8000, hvilket også var de værdier som mit char array i koden blev fyldt op med og derfor blev graferne underlige, så den er go nok, det er korrekt at nummeret på div. tegn i dec-tal går fr 0-255...
Avatar billede pablopablo Nybegynder
16. april 2005 - 00:20 #12
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemtextencodingclassunicodetopic.asp ---> Gets an encoding for the Unicode format in little-endian byte order.

Derfor skrev jeg det, men det er pga. det unicode(UTF16)...og ikke unicode(UTF8) det er det du mener ik?

i mit tilfælde kunne jeg så vel ligeså godt benyttet UTF8...hvor finder jeg unicode tabellen henne?
Avatar billede arne_v Ekspert
16. april 2005 - 00:20 #13
Altså man sender jo ikke bits - man sender betydning.

Man vil sende et ø f.eks. - i CodePage 1252 sender man 8 bit med værdien 248 - i UTF-8
sender man 16 bit med noget som jeg ikke kan huske hvad
Avatar billede arne_v Ekspert
16. april 2005 - 00:22 #14
http://www.kostis.net/charsets/cp1252.htm går da fra 32 til 255 ??
Avatar billede arne_v Ekspert
16. april 2005 - 00:23 #15
Encoding.Unicode er UTF-16
Avatar billede pablopablo Nybegynder
16. april 2005 - 00:28 #16
ang. linket, nope - tjek kolonne "Code" scrol halvvejs ned på side, der står bla. Code = 8364 = EURO SIGN og det var disse høje værdier som ødelagde mine grafer.

ja, okey nu er jeg med, dvs. encoding hos afsender og modtager skal altås være den samme, eller i hvert fald begge indeholde de samme tegn som sendes og naturligvis ska lde have det samme nr i hver tabel...
Avatar billede arne_v Ekspert
16. april 2005 - 00:34 #17
den kolonne som hedder code er ikke codepage 1252 men den unicode værdi som svarer
til codepage 1252 værdierne i de første 2 kolonner
Avatar billede pablopablo Nybegynder
16. april 2005 - 00:41 #18
okey, det giver også mening og det derfor tænke jeg også der var noget galt med den måde jeg konverterede til int på...remember? pga. jeg fik åbenbart unicode værdierne frem istedet for cp 1252's værdier...
Avatar billede pablopablo Nybegynder
16. april 2005 - 00:42 #19
Idet jeg modtager data således her lige nu : data += new string((char)modtagetData[i],1); har jeg slået nedenstående op på msdn...

Char : The Char value type represents a Unicode character, also called a Unicode code point, and is implemented as a 16-bit number ranging in value from hexadecimal 0x0000 to 0xFFFF.

Når der er afsat 16bit til hvert tegn/char er det så ikke UTF16, det lyder da i hvert fald logisk?-) eller hvordan hænger det teknisk sammen? du skrev nemlig tidligere : 00:20:50 >> at UTF8 benytter 16bit...?
Avatar billede arne_v Ekspert
16. april 2005 - 00:44 #20
det var noget sludder - jeg mente UTF-16
Avatar billede pablopablo Nybegynder
16. april 2005 - 00:51 #21
ok, så er jeg da ikke helt tabt :) hehe...nå men når jeg modtage og sende via unicode UTF16, så er der vel ikke nogen grund til at undersøge en masse videre...? trods det msåke kunne være en anden encoding maskienen som data reelt kommer fra benytter...? men når det ikke er muligt, at fremskaffe noget dokumentation hvori det står, så er det vel ok....eller hvad siger du? hvad ville du gøre?
Avatar billede pablopablo Nybegynder
16. april 2005 - 00:51 #22
jeg mente når selvfølgelig pga. UTF16 virker perfekt...
Avatar billede arne_v Ekspert
16. april 2005 - 10:21 #23
man skal være forsigtigt med at post efter midnat

ø er 16 bit både i UTF-8 og UTF-16

a er 8 bit i UTF-8 og 16 bit i UTF-16
Avatar billede pablopablo Nybegynder
16. april 2005 - 11:20 #24
ja okey....men de resterende tegn fylder vel 8 bit i UFT8 og 16 bit i UTF16?-)

lige nu benytter programmet UFT16 (pga. char), er det fint nok at blive ved det, eller er UTF8 at foretrække hvis det også virker fint? Er det ene mere benyttet/anvendt i programmer end det andet?

Jeg har et program (jeg ikke selv har skrevet) kørende på en bærbar og det kan fint modtage data i UTF16 encoding og det er indstillinget med en databit-længde på 8...hvordan kan det så egentlig forstår det jeg sender til den?
Avatar billede arne_v Ekspert
16. april 2005 - 11:22 #25
alle tegn der også er i ASCII fylder 8 bit i UTF-8

resten af dem som er relevante i europa fylder 16 bit i UTF-8
Avatar billede pablopablo Nybegynder
16. april 2005 - 11:40 #26
ok....men UTF16 benytter jo altid 16bit og det er derfor jeg ikke kan forstå at programmet som er indstillinget med en databit længde på 8, kan modtage data fra mit program...?
Avatar billede arne_v Ekspert
16. april 2005 - 11:46 #27
"databit længde på 8" betyde "8 bit no parity" ikke ? (i modsætning til
"7 bit even parity")

det er bytes ikke chars man snakker om

kommunikation aner intet om encodinger
Avatar billede pablopablo Nybegynder
16. april 2005 - 12:12 #28
jo, partibit none, databit 8, stopbit 1 og flow control none....

jeg er med på hvad du mener ang. bytes og chars....men forstår ikke helt hvordan det funger teknisk set...når databit mv. er indstillet ens hos modtager og afsender, så kan der efterfølgende benyttes den encodig man vil...det er jeg med på...men tænker blot på hvordan  hvis jeg fx. sender et tegn i UTF8 (som fylder 8 bit), så kan det ene tegn altså både fylde fx. 5,6,7 eller 8bits i længden når det sendes over mediet (i programmet på den bærbar kan man nemlig vælge imellem databit længde på : 5,6,7 eller 8)
Avatar billede arne_v Ekspert
16. april 2005 - 13:54 #29
Du skal skelne mellem byte og char.

8 data bit er 8 bit per byte

UTF-8 er 1 eller 2 byte per char

prøv og tænk på copy kommandoen

den kopierer N bytes fra en fil til en anden fil - det er bedøvende ligeglad med
om det er N bogstaver i ISO-8859-1 eller mellem N/2 og N bogstaver i UTF-8
Avatar billede pablopablo Nybegynder
16. april 2005 - 14:36 #30
oookey, det er nok pga. jeg har faft i hovedet at et tegn skulle sendes i en omgang, altså på en gang, hvis du kan følge mig selvfom jeg godt kan se nu at det ikke giver så meget mening...

Jeg kunne fx. sende en string på 10 tegn afsted over mediet i UFT8, hvoraf hveranden af div. tegn fyldte 16bit og de resterende 8 bit per byte....modtageren ville være ligeglad, den forståer det alligevel ikke på det niveau, den modtaget blot x-antal bits bidder af gangen (det samme som afsenderen fx. 5,6,7 eller 8) og først senere skal modtageren benytte den korrekte encoding for at få de samme tegn frem på skærmen, ikke sandt?-)

Men hvad er grunden egentlig til, at der fx. benyttes en databit længde på 8, nu hvor der ikke har noget med encodingen af gøre...? den kunne vel ligeså godt være 14, 27 eller 88 ik`? det er vel blot noget som er besluttet, ligesom de går 100cm på en meter?-)
Avatar billede arne_v Ekspert
16. april 2005 - 14:39 #31
ja egenligt

det er blevet standard med at en byte et 8 bit

andet er set i gamle dage (jeg har engang brugt en computer hvor en byte var 6 bit)
Avatar billede pablopablo Nybegynder
16. april 2005 - 14:45 #32
jamen, så begyder brikkerne jo at falde på plads ;)

Jeg vil lade mit program sende UTF16 fra nu af, idet det ser fint ud...

Findes der ikke en samlet unicode tabel et sted på nettet? på unicode.org kan jeg nemlig ikke finde den?
Avatar billede arne_v Ekspert
16. april 2005 - 14:47 #33
Avatar billede pablopablo Nybegynder
16. april 2005 - 14:52 #34
ja okey...der er de opdelt i kategorier, men alle div. tegn i div. tabeller findes jo samlet i under unicode, så når man fx. skriver Encodig.Unicode...så har man adgang ti lalle de mange tegn på siden...?
Avatar billede arne_v Ekspert
16. april 2005 - 14:55 #35
deres indgangsvinkler er vist at man ved hvilket tegn man har og at man skal finde
koden for det

du vil gerne have det de anden vej - du har koden og vil gerne vide hvilket tegn det er
Avatar billede pablopablo Nybegynder
16. april 2005 - 14:57 #36
ja fx. det ville da være rart hvis det hele var samlet i en tabel, kode, tegn osv...
Avatar billede arne_v Ekspert
16. april 2005 - 15:01 #37
Du kan slå en kode op på http://www.unicode.org/charts/About.html men der fortæller
kun hvilken chart den er i (dog med link)
Avatar billede pablopablo Nybegynder
16. april 2005 - 15:11 #38
ja okey, det kunne godt nok være lavet lidt smartere en dden skal åbne det via Acrobat for hvert eneste tegn...:/

mit sidste spg.: Når en maskine fx modtager 0101010001001010010010010001111010101010 :) så selv om modtageren kender den benyttede encodingen, hvordan ved encodingen så hos modtageren, hvor/hvordan den skal dele div. bits fra hinanden? det er logisk nok ved UFT16, når alle tegn fylder det samme. Men hvordan foregår det ved fx. UTF8, når længden er variabel...? sendes noget info med "imellem" databits'ne som indikere, at hér starter og slutter et tegn eller...hvordan?
Avatar billede arne_v Ekspert
16. april 2005 - 15:18 #39
det kan den heller ikke altid finde ud af

40 bits vil altid blive oversat til 5 bytes fordi det er standard idag

men de 5 bytes bliver oversat til 3-5 chars efter encoding - hvis programmøren
eksplicit angiver en så den - ellers bare hvad der tilfældigvis er default
Avatar billede pablopablo Nybegynder
16. april 2005 - 15:22 #40
hmm...men hvis jeg fx. benytter UTF8 og sender det til dig og du véd det er UFT8 (men tegn hhv. fylder 8 og 16 bit) er der så ikke en måde hvordan UTF8-encodingen har markeret hvor div. tegn reelt ligger henne? eller kan der jo stadig gå kuk i den...
Avatar billede arne_v Ekspert
16. april 2005 - 15:27 #41
det er lavet så snedigt at når jeg får 1 bytes så kan jeg se om den ene byte er
en char eller om jeg skal have en byte mere for at få en char

jeg kan ikke huske UTF konventionen men forestil dig følgende simple
princip: højeste bit - 0=ikke mere 1=mere
Avatar billede pablopablo Nybegynder
16. april 2005 - 15:31 #42
ja okey, det kender jeg fra datamatikker udd...:) ok, det er dér den tjekker det...

Så det er altså ikke mere sikker tat benytte UFT16 end UTF8, når begge er mulige i mit program, er så en go grund til at vælge det ene istedet for det andet?
Avatar billede arne_v Ekspert
16. april 2005 - 15:50 #43
UTF-8 er langt mere brugt end UTF-16.

Af 2 årsager:
  - fylder mindre
  - alle bogstaver i ASCII kan ses i en viewer som kun understøtter ASCII/ISO-8859-1
Avatar billede pablopablo Nybegynder
18. april 2005 - 13:54 #44
Hej Arne, jeg prøvede at sende via UTF8, men et af tegnene "ý" det blev lavet og til noget mærkeligt "½A" tror jeg det var...så jeg holder mig til UTF16 :)

Men jeg sørger stadig en tabel hvor alle unicode tegn står i, findes det ikke tror du? ud over dem folk selv har lavet, altså en officel en?

Har fundet denne : http://stargazer.whitebeach.org/unicode.html den er dog ikke så sej idet man af tegnene bliver vist som firkanter...
Avatar billede pablopablo Nybegynder
18. april 2005 - 14:53 #45
Kan det passe, at de første 256 codepage 1252 er de samme som de første 256 tegn i unicode?-) det ligner det nemlig meget og det er faktisk kun dem jeg er interesseret i...
Avatar billede arne_v Ekspert
18. april 2005 - 14:57 #46
ja sådan da

0 byte + tegn i ISO-8859-1 = unicode i UTF-16

(og forskellen på ISO-8859-1 og CP-1252 er ikke stor)
Avatar billede pablopablo Nybegynder
18. april 2005 - 15:13 #47
ok! det er pga. jeg i dokumentationen skriver at programmet sender viá UTF16 og så jeg jeg i et bilag tabellen 1252, blot så de kan se alle div. tegn...for de ser ud til at være helt ens...
Avatar billede pablopablo Nybegynder
20. april 2005 - 14:11 #48
Hej igen arne, når det virkede ikke med unikode hos de kunder i DK hvor det køre test :/ men fint med CP1252...Jeg modtager godt nok data i UTF16, men det er kun de først 256 tegn, som benyttes så det er jo derfor det kan lade sig gøre...

Jeg tænkte på, ville det være godt at brugeren selv i programmet kunne vælge hvordan data skal sendes? Fx. via UTF8/UFT16 eller via den Codepage de ønsker, simpelt ved at have muligheden for, at indtaste nummeret på den codepage de ønsker at benyttet?
Grunden det dette, er selvfølgelig hvis de kører med en anden encoding i forvejen i det system, som modtager data, idet det er mange forskellige systemer verdenen over og nogle vil også udvikle nye systemer til at kunne modtage vores data...
Avatar billede pablopablo Nybegynder
25. august 2005 - 23:43 #49
Hej Arne...længde siden...jeg fanst ud af at det faktisk var Latin 1 - ISO 8859 - Code page 28591... ;)

Læg et svar...
Avatar billede arne_v Ekspert
26. august 2005 - 07:51 #50
kommer her
Avatar billede Ny bruger Nybegynder

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.

Loading billede Opret Preview
Kategori
IT-kurser om Microsoft 365, sikkerhed, personlig vækst, udvikling, digital markedsføring, grafisk design, SAP og forretningsanalyse.

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester