15. april 2005 - 16:27Der 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 :
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) :
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"...
Virksomheder er på vej fra store sprogmodeller, der svarer på spørgsmål, til AI-agenter, der kan udføre opgaver på egen hånd. Det gør teknologien mere nyttig – og langt mere risikabel.
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...
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...?
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...
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...
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...
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...?
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?
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?
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...?
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)
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
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?-)
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...?
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?
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
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...
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?
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?
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...
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...
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...
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.