Japanska språket och datorer

Ett japanskt kana-tangentbord

I förhållande till det japanska språket och datorer uppstår många anpassningsproblem, några unika för japanska och andra gemensamma för språk som har ett mycket stort antal tecken. Antalet tecken som behövs för att skriva på engelska är ganska litet, och därför är det möjligt att använda endast en byte (2 ⁸ =256 möjliga värden) för att koda varje engelskt tecken. Antalet tecken på japanska är dock många fler än 256 och kan alltså inte kodas med en enda byte - japanska kodas alltså med två eller fler byte, i en så kallad "double byte" eller "multi-byte"-kodning. Problem som uppstår relaterar till translitterering och romanisering , teckenkodning och inmatning av japansk text.

Teckenkodningar

Det finns flera standardmetoder för att koda japanska tecken för användning på en dator, inklusive JIS , Shift-JIS , EUC och Unicode . Även om kartläggningen av kana är en enkel sak, har kanji visat sig svårare. Trots ansträngningar har inget av kodningsscheman blivit de facto-standarden, och flera kodningsstandarder användes på 2000-talet. Från och med 2017 har andelen UTF-8- trafik på Internet utökats till över 90 % över hela världen, och endast 1,2 % var för att använda Shift-JIS och EUC. Ändå använder några populära webbplatser inklusive 2channel och kakaku.com fortfarande Shift-JIS.

var de flesta japanska e-postmeddelanden i ISO-2022-JP ("JIS-kodning") och webbsidor i Shift-JIS och mobiltelefoner i Japan använde vanligtvis någon form av Extended Unix-kod . Om ett program misslyckas med att avgöra vilket kodningsschema som används, kan det orsaka mojibake ( 文字化け , "felkonverterade förvrängda/skräptecken", bokstavligen "förvandlade tecken") och därmed oläsbar text på datorer.

Kanji ROM -kort installerat i PC-98 , som lagrade cirka 3000 glyfer, och möjliggjorde en snabb visning. Den hade också ett RAM-minne för att lagra gaiji.

Inbäddade enheter använder fortfarande halvbredds kana

Den första kodningen som blev allmänt använd var JIS X 0201 , som är en enkelbytekodning som endast täcker vanliga 7-bitars ASCII -tecken med halvbredds katakana- tillägg. Detta användes flitigt i system som varken var tillräckligt kraftfulla eller hade lagringsutrymme för att hantera kanji (inklusive gammal inbyggd utrustning som kassaregister) eftersom Kana-Kanji-konvertering krävde en komplicerad process, och utdata i kanji krävde mycket minne och hög upplösning. Detta betyder att endast katakana, inte kanji, stöddes med denna teknik. Vissa inbäddade skärmar har fortfarande denna begränsning.

Utvecklingen av kanji-kodningar var början på splittringen. Shift JIS stöder kanji och utvecklades för att vara helt bakåtkompatibel med JIS X 0201, och är därför i mycket inbyggd elektronisk utrustning. Shift JIS har dock den olyckliga egenskapen att den ofta bryter någon parser (programvara som läser den kodade texten) som inte är specifikt utformad för att hantera den.

Till exempel inkluderar vissa Shift-JIS-tecken ett omvänt snedstreck (0x5C "\") i den andra byten, som används som ett escape-tecken i många programmeringsspråk.

構		わ		な		い
8d	5c	82	ed	82	c8	82	a2

En parser som saknar stöd för Shift JIS kommer att känna igen 0x5C 0x82 som en ogiltig escape-sekvens och ta bort den. Därför orsakar frasen mojibake.

高			墲		ﾈ	い
8d		82	ed	82	c8	82	a2

Detta kan till exempel hända i programmeringsspråket C , när man har Shift-JIS i textsträngar. Det händer inte i HTML eftersom ASCII 0x00–0x3F (som inkluderar ", %, & och några andra använda escape-tecken och strängseparatorer) inte visas som andra byte i Shift-JIS, och omvänt snedstreck är inte ett escape-tecken där. Men det kan hända för JavaScript som kan bäddas in i HTML-sidor.

EUC , å andra sidan, hanteras mycket bättre av parsers som har skrivits för 7-bitars ASCII (och därför används EUC -kodningar på UNIX, där mycket av filhanteringskoden historiskt sett bara skrevs för engelska kodningar). Men EUC är inte bakåtkompatibel med JIS X 0201, den första japanska huvudkodningen. Ytterligare komplikationer uppstår eftersom de ursprungliga Internet-e-poststandarderna endast stöder 7-bitars överföringsprotokoll. Således utvecklades RFC 1468 (" ISO-2022-JP ", ofta helt enkelt kallad JIS-kodning ) för att skicka och ta emot e-post.

Gaiji används i sluten bildtext av japanska TV-sändningar

I teckenuppsättningsstandarder som JIS ingår inte alla obligatoriska tecken, så gaiji ( 外字 "externa tecken") används ibland för att komplettera teckenuppsättningen. Gaiji kan komma i form av externa teckensnittspaket, där normala tecken har ersatts med nya tecken, eller de nya tecknen har lagts till oanvända teckenpositioner. Gaiji är dock inte praktiskt i internetmiljöer eftersom teckensnittsuppsättningen måste överföras med text för att använda gaiji. Som ett resultat av detta skrivs sådana tecken med liknande eller enklare tecken på plats, eller så kan texten behöva kodas med en större teckenuppsättning (som Unicode) som stöder det obligatoriska tecknet.

Unicode var tänkt att lösa alla kodningsproblem över alla språk. UTF -8- kodningen som används för att koda Unicode på webbsidor har inte de nackdelar som Shift-JIS har. Unicode stöds av internationell programvara, och det eliminerar behovet av gaiji. Det finns fortfarande kontroverser, dock. För japanska har kanji-tecken förenats med kinesiska; det vill säga, ett tecken som anses vara detsamma på både japanska och kinesiska ges ett enda nummer, även om utseendet faktiskt är något annorlunda, med det exakta utseendet överlåtet till användningen av ett teckensnitt som är lämpligt för språket. Denna process, kallad Han enande , har orsakat kontroverser. ^{[ citat behövs ]} De tidigare kodningarna i Japan, Taiwan-området , Kina och Korea har bara hanterat ett språk och Unicode borde hantera alla. Hanteringen av Kanji/kinesiska har dock utformats av en kommitté bestående av representanter från alla fyra länder/områden. ^{[ citat behövs ]}

Textinmatning

Skriftlig japanska använder flera olika skript: kanji (kinesiska tecken), 2 uppsättningar kana (fonetiska syllabaries) och romerska bokstäver. Medan kana och romerska bokstäver kan skrivas direkt i en dator, är inmatning av kanji en mer komplicerad process eftersom det finns mycket fler kanji än det finns tangenter på de flesta tangentbord. För att mata in kanji på moderna datorer skrivs läsningen av kanji vanligtvis in först, sedan visar en input method editor (IME), även känd som en front-end-processor, en lista över kandidatkanji som är en fonetisk matchning, och tillåter användaren att välja rätt kanji. Mer avancerade IME fungerar inte med ord utan med fraser, vilket ökar sannolikheten för att få de önskade tecknen som det första alternativet som presenteras. Kanji-avläsningsingångar kan vara antingen via romanisering ( rōmaji nyūryoku, ローマ字入力 ) eller direkt kana-ingång ( kana nyūryoku, かな入力 ). Romaji-inmatning är vanligare på datorer och andra tangentbord i full storlek (även om direktinmatning också stöds i stor utsträckning), medan direkt kana-ingång vanligtvis används på mobiltelefoner och liknande enheter – var och en av de 10 siffrorna (1–9,0) motsvarar till en av de 10 kolumnerna i gojūon -tabellen i kana, och flera tryckningar väljer raden.

Det finns två huvudsystem för romanisering av japanska, kända som Kunrei-shiki och Hepburn ; i praktiken tillåter "tangentbordsromaji" (även känd som wāpuro rōmaji eller "ordbehandlare romaji") i allmänhet en lös kombination av båda. IME-implementationer kan till och med hantera nycklar för bokstäver som inte används i något romaniseringsschema, såsom L , och konvertera dem till den mest lämpliga motsvarigheten. Med kana-inmatning motsvarar varje tangent på tangentbordet direkt en kana. JIS -tangentbordssystemet är den nationella standarden, men det finns alternativ, som tumförskjutningstangentbordet, som ofta används bland professionella maskinskrivare.

Textens riktning

LibreOffice Writer stöder alternativ för nedåtgående text

Japanska kan skrivas i två riktningar . Yokogaki- stilen skriver från vänster till höger, uppifrån och ner, som med engelska. Tategaki- stilen skriver först uppifrån och ner och flyttar sedan från höger till vänster.

För att konkurrera med Ichitaro tillhandahöll Microsoft flera uppdateringar för tidiga japanska versioner av Microsoft Word inklusive stöd för nedåtgående text, som Word 5.0 Power Up Kit och Word 98.

QuarkXPress var den mest populära DTP-mjukvaran i Japan på 1990-talet, även den hade en lång utvecklingscykel. Men på grund av bristande stöd för nedåtgående text överträffades den av Adobe InDesign som hade starkt stöd för nedåtgående text genom flera uppdateringar.

För närvarande ^{[ när? ]} hanteringen av nedåtgående text är ofullständig. HTML har till exempel inget stöd för tategaki och japanska användare måste använda HTML-tabeller för att simulera det. CSS nivå 3 innehåller dock en egenskap " skrivläge " som kan återge tategaki när det ges värdet " vertical-rl " (dvs. uppifrån och ned, höger till vänster). Ordbehandlare och DTP -programvara har mer komplett stöd för det.

Se även

externa länkar