Az IBM véleménye a Novell-MS egyezséggel kapcsolatban

IBM, Lenovo

Eddig már szinte mindenki kifejtette véleményét a nemrég megköttetett Novell-Microsoft egyezséggel kapcsolatban, kivéve az IBM-et. Scott Handy, az IBM Linux és nyílt forrású ügyekért felelős globális alelnöke úgy gondolta, itt az ideje elmondani, hogy mit gondol az IBM az ügyről. Handy egy a LinuxWatch.com-nak adott interjúban elmondta, hogy az IBM régóta támogatója a Linux - Windows együttműködési képesség kérdésének. A cég, mint a nyílt forráskód és a nyílt szabványok támogatója csak megtapsolni tud minden olyan törekvést, amely hidat képez e szakadék felett. A cikk itt.

( bacsa81 | 2006. 11. 22., sze – 15:36 )

Business is business...
**********************************************
Heavy Metal for Human Bee(Gees)ings!
**********************************************

and the business of business is business.... akkor most hogy kerül ez egy informatikai témájú oldalra?!:D
_________________________________________
Valódi paraszt vagyok. Csak előre tudok lépni, nem azt ütöm le, aki velem szembenáll, és ha nincs tovább, megváltozom.

( uid_2813 | 2006. 11. 22., sze – 15:46 )

Gondolom ot is megvettek kilora. Sot, ot meg regebben. :)

( PDA_FAN | 2006. 11. 22., sze – 21:04 )

"az IBM régóta támogatója a Linux - Windows együttműködési képesség kérdésének" - b#sszátokmeg, még arra sem vagytok képesek, hogy egy nyomorult iso-8859-2 karakterkészletet rendesen támogassatok, és itt tépitek a szátokat az együttműködési képességről??? (Aki már találkozott mongyuk egy WebSphere-re írt alkalmazással, az sejtheti, mire gondolok...)

WE [] UNICODE.

Masszoval, hujjj de okos mar megint valaki, megmondja a frankot. Tamogatnam en az Unicode-t (NEM), ha egyreszt az alkalmazasok rendesen tamogatnak (de leginkabb nem), valamint mondjuk a regi kodlapokbol az ujakba, es vica-versa vegre zokkenomentesen lehetne konvertalni. Peldaul, nekem igen nagy gondot okoz, az UTF-8 -> ISO-8859-1 konverzio, amit regi cuccok miatt surun hasznalok (pl. fizetos meloban DOS-os clipperes hulladmanyhoz, de regi Amigas progikat is mondhatnek, ami ugye hobbi), mert az osszes bazi expert konvertalo stuff az UTF-8-as hosszu u" es hosszu o"-t, szepen kerdojelle, szokozze vagy hasonlo szepsegge konvertalja. Azt a combot mar meg se emlitem, amikor a nevezett karaktereket egyszeruen KIHAGYJAK a celszovegbol. Holy shit. Ez kinek a fejebol pattant ki!? Gondolom valami kulhoni barom volt, akinek koze nincs a hazai szamitastechnika tortenetehez, igy nem tudja, hogy hasonlo esetben tessek kalapos o^-ve es u^-va konvertalni, mert a regi kodlapot hasznalo magyar cuccokban pontosan e ket karakter helyen helyezkedik el a rendes o" es rendes u" (CWI-2 a baratom, meg mindig!).

Arrol nem is beszelve, hogy hasznalnek en UTF-8 karaktereket, pl. fajlrendszerben, de ha megosztok egy UTF-8-as filerendszert pl. Samban, akkor minden Windows verzio, ill korabbi Sambak, ill. masfele OS-ek (OS/2 peldaul) mashogy bugzik ossze vele. Ergo ittis marad a 8859-2 egyelore, amig ki nem kopnak a regi cuccok vegleg.

Az Unicode koncepciorol magarol meg korulbelul az a velemenyem, hogy b#?sszak meg a kinaiak a felcsillio karakteruket, ami miatt itt nekem europaban, Ugy min. jo 25+ evnyi jol mukodo nemzeti nyelvu szamitastechnikai kulturaval a hatam mogott, szopnom kell a ketbyteos binaris szemettel. IMHO.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Egy-két éve én is ilyesmit gondoltam ..., aztán tájékozódtam. Addig is, ha ezek egyikét vagy másikát (vagy valami hasonlót) beállítasz a .bashrc-ben, akkor a terminálod a megfelelő nyelven és karakterkészlettel fog működni.

export LANG=en_US.ISO-8859-1
export LANG=hu_HU.ISO-8859-2
export LANG=en_GB.UTF-8

A www.comfirm.hu-n egy olyan Clipper származékot találsz, ami érti az UTF-8-at.

"hosszu u" es hosszu o"-t, szepen kerdojelle"

Konvertáld ISO-8859-2-vé és ez a resze jó lesz. Hidd el. Ami karakterkod latin2-ben az ő és ű az latin1-ben a kalapos o es u.

"meg korulbelul az a velemenyem, hogy b#?sszak meg a kinaiak a felcsillio karakteruket"

Na most egy amcsi kb ugyanezt gondolhatja a magyarokrol meg a hulye egzotikus karakterukrol. Ez a hozzaallas nem vezet sehova, nem produktiv. Inkabb orulnel, hogy a korabbi ugyfelekrol le lehet huzni meg egy bort az uj programverzioval, ami mar utf-8 tamogatassal is bir es igy alkalmas a nemzetkozi uzleti kapcsolatok kezelesere (Kinat meg nem bantani, szepen lassan teljesen fuggeni fogunk az onnan jovo aruktol).

Oke. A konvertalo programnak igaza van, mert az ő, az õ és az ô három kulonbozo karakter, es a magyar duplaekezetes valtozatok az iso-8859-1-ben nincsenek. Viszont te a konverziot megelozoen cserelhetsz kalaposra (unicode kornyezetben ezt konnyen meg tudod tenni, pl. a tr őű ôû | iconv -f utf8 -t latin1 parost hasznalva), vagy ha nem akarsz szep megoldast, akkor kihasznalhatod, hogy ha iso-8859-2-be konvertalsz, akkor ez magyar szovegnel vesztesegmentes, majd a kapott szovegre mint iso-8859-1-re tekintesz, es nem volt benne semmi igen specialis, akkor a megfelelo helyeken "pont jo" karakterek fognak allni (konkretan ő helyen õ (hullámos), ű helyen pedig û (kalapos) fog allni).

A konvertalo programok kozul nem tudom mit hasznalsz, az iconv mar alapertelmezesben szol, ha nem tud valamilyen karaktert mappelni, a recode megprobalja "lazan" lekepezni (ő-bol o" lesz), de a --strict opcioval o is tud ugyanigy viselkedni, igy nem tudsz informaciot vesziteni.

Az utf8 kodolas meg kicsit kulonbozik a wide stringtol (ez all ket byte-os elemekbol), mint ezt mas is megjegyezte.

A wchar_t típus a mostani C fordítókban 32 bites.

A UNICODE/UTF-8 abszolút nélkülözhetetlen. Nem tudom mennyire közismert, hogy egy XML dokumentum miből áll, karakterekből vagy byteokból? A szabvány szerint karakterekből (ez egy új értelmezés, és persze az sem triviális, hogy mi egy karakter). Namost UNICODE=karakterek összessége.

Amikor egy karakterekből álló dokumentumot ki kell írni egy fájlba, akkor előbb bytesorozatra kell alakítani, mivel a fájlokban byteok vannak. Itt jön be az UTF-8, amit úgy kell értelmezni, mint a (UNICODE) karakterek sorosítását.

Ha a karaktersorozatot wchar_t elemek egymásutánrakásával sorosítanánk, akkor azzal meggyűlne az OS-ek baja, mivel tele volna 0 byteokkal. Az UTF-8 sorosítás nagy előnye, hogy nincs a belsejében 0 byte, ezért az OS-ek el tudják fogadni parancsként, fájl névként, stb. Ezért terjedt el a közelmúltban az UTF-8.

Tehát ucs-4 mostani értelmezés szerint a widechar? Már javában is? Nem okoz ez inkompatibilitást a korábbi értelmezéssel szemben? utf-8 vs. utf-32 összehasonlításnál azért mindegyiknek van előnye és hátránya is, az utf-8 azon kívül, hogy helytakarékos, a karakterkezdő byte is könnyen felismerhető, és valóban nem használja a reprezentációban a 0 byte-ot. Viszont a vele való stringműveletek nehézkesek, mi van, ha egy nagy pufferben tárolt karakterek számát akarod meghatározni, vagy mondjuk az 500. karaktertől akarod kivágni? Ha jól sejtem, végig kell olvasni a stringet az elejétől kezdve, nem pedig egy egyszerű pointerművelet. Szóval míg diszken tárolni vagy hálózaton (sms-ben :) átvinni unicode stringet biztosan érdemesebb utf-8-ban, addig lehet, hogy adott esetben érdemesebb egy programban utf-32/ucs-4-et használni a gyorsabb műveletek érdekében. A memória úgyis olcsó :)

UTF-8 jelentése: Unicode *Transfer* Format, 8 bit

Vagyis átviteli formátum! Gondolj rá úgy, mint egy archív fájlra. Pl. egy tar.gz-nél is ki kell az egészet csomagolnod és a kapott tar fájlt végolvasnod ahhoz, hogy megmond mekkora a benne lévő fájlok összmérete. Ugyanígy, ha egy gz-vel tömörített fájl 500. bájtját akarod, akkor ki kell csomagolnod az 500. bájtig!

1. nem tudom miket használsz, de nem találkoztam még az általad említett problémákkal, pedig üzemeltem be fájlszerert acl+utf8-cal windows + linux környezetben. Ahol lehet utf-8-at használok, még weboldalakon is és eddig nem volt semmi gond (pedig komoly szakmai háttérrel rendelkező ember is mondta, hogy mekkorát szívtak vele), kde-ben csont nélkül megy mindenféle kódlapkonverzió és vannak jól működő konverziós library-k (pl. az OOo valamint a KDE által használt). Ezek ellenére elhiszem, hogy neked akadnak gondjaid.
2. Az utf-8 8 bites, a 16 bites b*szást utf-16-nak hívják, de ezek csak a unicode-os szöveg átviteléhez használt kódolási módszerek. Memóriában általában csak 16 bitesen csomagolják ki, mert csak ennyire van tényleg szükség, de valójában egy unicode karaktert 32 bitesen kell értelmezni (elég nagy memóriapazarlás lenne ;-).
3. hivatalosan a unicode-os szövegek kezelésének különböző szintjei vannak attól függően, hogy mennyire kezeled. A legegyszerűbb esetben csak értelmezed a karaktereket és megjeleníted, a legbonyolultabb esetben a vezérlőkaraktereket is helyesen kell kezelni (pl. keresésnél, a kurzor pozíciónálásánál, stb. a left-to-right, right-to-left írásmódokat is teljesen figyelembe kell venned, a kompozit karaktereket értelmezni kell, stb.)
4. a CJK ideographs (Kina, Japán, Korea) csak 27ezer jel! De ha minden mást (arab, thai, stb.) írásokat is figyelembe veszel, akkor már kevés a 64K is. A 256 viszont kevés a csak latin eredetű írásjelekhez, már csak emiatt 16 bit kéne (vagy annak idején nem a 8 bites megoldásnak kellett volna elterjednie)