Pagina de cod Windows - Windows code page

Paginile de cod Windows sunt seturi de caractere sau pagini de cod (cunoscute sub numele de codificări de caractere în alte sisteme de operare) utilizate în Microsoft Windows din anii 1980 și 1990. Paginile de cod Windows au fost treptat înlocuite când Unicode a fost implementat în Windows , deși sunt încă acceptate atât în ​​Windows, cât și pe alte platforme, și se aplică în continuare când sunt utilizate comenzile rapide pentru codul Alt .

Există două grupuri de pagini de coduri de sistem în sistemele Windows: pagini de cod OEM și Windows-native („ANSI”). Paginile de cod din ambele grupuri sunt pagini de cod ASCII extinse . Pagini de cod suplimentare sunt acceptate de rutinele standard de conversie Windows, dar nu sunt utilizate ca ambele tipuri de pagini de coduri de sistem.

Pagină cod ANSI

Seria Windows-125x

Alias ​​(uri)	ANSI (nume greșit)
Standard	Standard de codare WHATWG
Se extinde	SUA-ASCII
Precedat de	ISO 8859
urmat de	Unicode UTF-16 (în API-ul Win32)
v t e

Paginile de cod ANSI (denumite oficial „pagini de cod Windows” după ce Microsoft a acceptat ca termenul anterior să fie un nume greșit) sunt utilizate pentru aplicații native non-Unicode (de exemplu, orientate pe octeți ) care utilizează o interfață grafică de utilizator pe sistemele Windows. Termenul „ANSI” este un nume greșit deoarece aceste pagini de cod Windows nu respectă niciun standard ANSI ; pagina de cod 1252 s-a bazat pe un proiect ANSI timpuriu care a devenit standardul internațional ISO 8859-1 , care adaugă încă 32 de coduri de control și spațiu pentru 96 de caractere tipărite. Printre alte diferențe, paginile de cod Windows alocă caractere imprimabile spațiului de cod suplimentar de control, făcându-le cel mai bine ilizibile pentru sistemele de operare conforme cu standardele.)

Majoritatea paginilor de cod "ANSI" vechi au numere de pagini de cod în modelul 125x. Cu toate acestea, 874 (thailandeză) și paginile de cod „ANSI” multi-octet din Asia de Est ( 932 , 936 , 949 , 950 ), toate folosite și ca pagini de cod OEM, sunt numerotate pentru a se potrivi IBM (dar nu identice) similare codificări. În timp ce pagina de cod 1258 este utilizată și ca pagină de cod OEM, este originală pentru Microsoft, mai degrabă decât o extensie la o codificare existentă. IBM și-a atribuit propriile numere diferite pentru variantele Microsoft, acestea fiind date ca referință în listele de mai jos, acolo unde este cazul.

Toate paginile de cod 125x Windows, precum și 874 și 936, sunt etichetate de Internet Assigned Numbers Authority (IANA) ca „Windows- number ”, deși „Windows-936” este tratat ca sinonim pentru „ GBK ”. Pagina de cod Windows 932 este în schimb etichetată ca „Windows-31J”.

Paginile de cod ANSI Windows și, în special, pagina de cod 1252 , au fost denumite astfel, deoarece se presupune că se bazează pe proiecte trimise sau destinate ANSI. Cu toate acestea, ANSI și ISO nu au standardizat niciuna dintre aceste pagini de cod. În schimb, acestea sunt fie:

• Superseturile seturilor standard, cum ar fi cele din ISO 8859 și diversele standarde naționale (cum ar fi Windows-1252 vs. ISO-8859-1 ),
• Modificări majore ale acestora (făcându-le incompatibile la diferite grade, cum ar fi Windows-1250 vs. ISO-8859-2 )
• Nu are codificare paralelă (cum ar fi Windows-1257 vs. ISO-8859-4 ; ISO-8859-13 a fost introdus mult mai târziu). De asemenea, Windows-1251 nu urmărește nici ISO-8859-5 standardizat ISO, nici KOI-8 care prevalează atunci .

Microsoft a atribuit aproximativ douăsprezece dintre tipografii și caractere comerciale (inclusiv în special, semnul euro , €) în CP1252 punctelor de cod 0x80-0x9F care, în ISO 8859, sunt atribuite codurilor de control C1 . Aceste atribuții sunt, de asemenea, prezente în multe alte pagini de cod ANSI / Windows la aceleași puncte de cod. Windows nu a folosit codurile de control C1, deci această decizie nu a avut niciun efect direct asupra utilizatorilor Windows. Cu toate acestea, dacă este inclus într-un fișier transferat pe o platformă conformă standardelor precum Unix sau MacOS, informațiile erau invizibile și potențial perturbatoare.

Pagina codului OEM

În paginile de cod OEM ( producător de echipamente originale ) sunt utilizate de către consola Win32 aplicații, și prin virtuale DOS , și poate fi considerat o relicvă din DOS și original IBM PC arhitectura. O suită separată de pagini de cod a fost implementată nu numai datorită compatibilității, ci și datorită faptului că fonturile hardware-ului VGA (și descendent) sugerează codificarea caracterelor de desenare a liniilor pentru a fi compatibile cu pagina de cod 437 . Majoritatea paginilor de cod OEM partajează multe puncte de cod, în special pentru caractere care nu sunt litere, cu a doua jumătate (non-ASCII) a CP437.

O pagină tipică de cod OEM, în a doua jumătate, nu seamănă nici cu o pagină de cod ANSI / Windows, nici măcar aproximativ. Cu toate acestea, două pagini de cod cu un singur octet, cu lățime fixă ​​(874 pentru Thai și 1258 pentru Vietnameză ) și patru pagini de cod CJK multibyte ( 932 , 936 , 949 , 950 ) sunt utilizate atât ca pagini de cod OEM, cât și ANSI. Pagina de cod 1258 folosește combinarea diacriticelor , deoarece vietnamezul necesită mai mult de 128 de combinații de litere-diacritice. Acest lucru este în contrast cu VISCII , care înlocuiește unele dintre codurile de control C0 (adică ASCII).

Istorie

Inițial, sistemele informatice și limbajele de programare a sistemului nu făceau distincție între caractere și octeți : pentru scripturile segmentare utilizate în cea mai mare parte a Africii, America, Asia de sud și sud-est, Orientul Mijlociu și Europa, un personaj are nevoie doar de un octet. , dar sunt necesare doi sau mai mulți octeți pentru seturile ideografice utilizate în restul lumii. Acest lucru a dus la multă confuzie ulterior. Software-ul și sistemele Microsoft anterioare liniei Windows NT sunt exemple în acest sens, deoarece utilizează paginile de cod OEM și ANSI care nu fac distincția.

De la sfârșitul anilor 1990, software-ul și sistemele au adoptat Unicode ca format de stocare preferat; această tendință a fost îmbunătățită prin adoptarea pe scară largă a XML , care oferă un mecanism mai adecvat pentru etichetarea codificării utilizate. Produsele Microsoft recente și interfețele programelor de aplicații utilizează Unicode intern, dar multe aplicații și API continuă să utilizeze codificarea implicită a „localizării” computerului atunci când citesc și scriu date text în fișiere sau ieșiri standard. Prin urmare, pot fi întâlnite fișiere care sunt lizibile și inteligibile într-o parte a lumii, dar mojibake neinteligibil în alta.

UTF-8, UTF-16

Microsoft a decis să adopte sistemul UTF-16 pe 16 biți (doi octeți) pentru toate sistemele sale de operare începând cu Windows NT. Această metodă codifică în mod unic toate caracterele Unicode din Planul multilingv de bază și un cod pe 32 de biți (patru octeți) pentru alții - dar restul industriei ( sisteme de tip Unix și web) a ales UTF-8 (care utilizează un octet pentru setul de caractere ASCII pe 7 biți , doi sau trei octeți pentru alte caractere din BMP și patru octeți pentru restul). De la Windows 10 versiunea 1803 , mașinile Windows pot fi configurate pentru a permite UTF-8 ca pagină de cod "ANSI" și OEM.

Listă

Următoarele pagini de cod Windows există:

Seria Windows-125x

Aceste nouă pagini de cod sunt toate codificări SBCS pe 8 biți ASCII extinse și au fost proiectate de Microsoft pentru a fi utilizate ca pagini de cod ANSI pe Windows. Acestea sunt cunoscute în mod obișnuit prin numele lor înregistrate în IANA , dar sunt numite uneori și „cp” pentru „pagina de cod”. Toate sunt utilizate ca pagini de cod ANSI; Windows-1258 este, de asemenea, utilizat ca pagină de cod OEM. windows-<number>cp<number>

Seria Windows-125x include nouă dintre paginile de cod ANSI și acoperă în mare parte scripturi din Europa și Asia de Vest, cu adăugarea Vietnamului . Codificările de sistem pentru limbile thailandeză și pentru cele din Asia de Est au fost numerotate pentru a se potrivi cu pagini de cod IBM similare și sunt utilizate atât ca pagini de cod ANSI, cât și OEM; acestea sunt prezentate în secțiunile următoare.

ID	Descriere	Relația cu ISO 8859 sau alte codificări stabilite
1250	Latină  2 / Europa Centrală	Similar cu ISO-8859-2, dar mută mai multe caractere, inclusiv mai multe litere.
1251	chirilic	Incompatibil atât cu ISO-8859-5, cât și cu KOI-8 .
1252	Latină 1 / vest-europeană	Superset ISO-8859-1 (fără controale C1). Repertoriul de litere în consecință similar cu CP850 .
1253	Greacă	Similar cu ISO 8859-7, dar mută mai multe caractere, inclusiv o literă.
1254	turc	Superset ISO 8859-9 (fără controale C1).
1255	Ebraică	Aproape un superset ISO 8859-8 , dar cu două modificări de punctuație incompatibile.
1256	arabic	Nu este compatibil cu ISO 8859-6 ; mai degrabă, codul OEM pagina 708 este un superset ISO 8859-6 (ASMO 708).
1257	Baltic	Nu ISO 8859-4 ; ISO 8859-13 ulterior este strâns legat, dar cu unele diferențe în punctuația disponibilă.
1258	Vietnameză (de asemenea, OEM)	Fără legătură cu VSCII sau VISCII , folosește mai puține caractere de bază cu combinarea diacriticelor.

Pagini de cod DOS

Acestea sunt, de asemenea, bazate pe ASCII. Cele mai multe dintre acestea sunt incluse pentru a fi utilizate ca pagini de cod OEM; pagina de cod 874 este, de asemenea, utilizată ca pagină de cod ANSI.

Pagini de cod multi-octet din Asia de Est

Acestea adesea se potrivesc doar parțial cu paginile de cod IBM ale aceluiași număr: paginile de cod 932, 936 și 949 diferă de paginile de cod IBM ale aceluiași număr, în timp ce Windows-951, ca parte a unui kludge , nu are legătură cu IBM-951. Paginile de cod echivalente IBM sunt date în a doua coloană. Paginile de cod 932, 936, 949 și 950/951 sunt utilizate atât ca pagini de cod ANSI, cât și OEM pe locațiile în cauză.

ID	Echivalent IBM	Limba	Codificare	Utilizare
932	943	japonez	Shift JIS (varianta Microsoft)	ANSI / OEM (Japonia)
936	1386	Chineză simplificată)	GBK	ANSI / OEM (RPC, Singapore)
949	1363	coreeană	Codul Hangul unificat	ANSI / OEM (Republica Coreea)
950	1370, 1373	Tradițional chinezesc)	Big5 (varianta Microsoft)	ANSI / OEM (Taiwan, Hong Kong)
951	5471	Tradițional chinezesc)	Big5-HKSCS (ed. 2001)	ANSI / OEM (Hong Kong, 98 / NT4 / 2000 / XP cu patch HKSCS)

Câteva pagini de coduri cu mai mulți octeți sunt acceptate pentru decodare sau codificare utilizând biblioteci de sisteme de operare, dar nu sunt utilizate ca niciun fel de codificare a sistemului în nici o locație.

ID	Echivalent IBM	Limba	Codificare	Utilizare
1361	-	coreeană	Johab (KS C 5601-1992 anexa 3)	Conversie
20000	964	Tradițional chinezesc)	CNS 11643	Conversie
20001	-	Tradițional chinezesc)	TCA	Conversie
20002	-	Tradițional chinezesc)	Big5 (varianta ETEN)	Conversie
20003	?	Tradițional chinezesc)	IBM 5500	Conversie
20004	-	Tradițional chinezesc)	Teletext	Conversie
20005	-	Tradițional chinezesc)	Wang	Conversie
20932 , 51932	954 (aproximativ)	japonez	EUC-JP	Conversie
20936 , 51936	-	Chineză simplificată)	GB2312	Conversie
20949 , 51949	-	coreeană	Wansung (8 biți cu ASCII, adică EUC-KR )	Conversie

Pagini de cod EBCDIC

Pagini de cod legate de Unicode

Pagini de cod compatibilitate Macintosh

Pagini de cod ISO 8859

Pagini de cod UIT-T

Pagini de cod KOI8

• 20866 - rusă - KOI8-R
• 21866 - ucraineană - KOI8-U (sau KOI8-RU în unele versiuni)

Probleme care decurg din utilizarea paginilor de cod

Microsoft recomandă cu tărie utilizarea Unicode în aplicațiile moderne, dar multe aplicații sau fișiere de date depind în continuare de paginile de cod vechi.

• Programele trebuie să știe ce pagină de cod să utilizeze pentru a afișa corect conținutul fișierelor (pre-Unicode). Dacă un program folosește o pagină de cod greșită, acesta poate afișa textul ca mojibake .
• Pagina de cod utilizată poate diferi de la o mașină la alta, astfel încât fișierele (pre-Unicode) create pe o mașină pot fi necitite pe alta.
• Datele sunt adesea etichetate necorespunzător cu pagina de cod sau nu sunt deloc etichetate, ceea ce face dificilă determinarea paginii de cod corecte pentru a citi datele.
• Aceste pagini de cod Microsoft diferă în diferite grade de unele dintre standarde și implementările altor furnizori. Aceasta nu este o problemă Microsoft în sine , așa cum se întâmplă cu toți furnizorii, dar lipsa de coerență face ca interoperabilitatea cu alte sisteme să nu fie de încredere în unele cazuri.
• Utilizarea paginilor de cod limitează setul de caractere care pot fi utilizate.
• Caracterele exprimate într-o pagină de cod neacceptată pot fi convertite în semne de întrebare (?) Sau alte caractere de înlocuire sau într-o versiune mai simplă (cum ar fi eliminarea accentelor dintr-o literă). În ambele cazuri, caracterul original poate fi pierdut.

Vezi si

• AppLocale  - un utilitar pentru a rula aplicații non-Unicode (bazate pe pagini de cod) într-o locație la alegerea utilizatorului.

Referințe

linkuri externe

• Referință API National Language Support (NLS) . Tabel care arată paginile de cod ANSI și OEM pe limbă (din arhiva web de când Microsoft a eliminat pagina originală)
• Înregistrări de nume IAS Charset
• Tabel de mapare Unicode pentru paginile de cod Windows
• Asocieri Unicode ale paginilor de cod Windows cu „cea mai bună potrivire”