Vanlig tekst - Plain text
cati en xterm vinduI databehandling er ren tekst et løst begrep for data (f.eks. Filinnhold) som bare representerer tegn i lesbart materiale, men ikke dets grafiske fremstilling eller andre objekter ( flytende tall , bilder osv.). Det kan også inneholde et begrenset antall "mellomrom" -tegn som påvirker enkel ordning av tekst, for eksempel mellomrom, linjeskift eller tabuleringstegn (selv om fanetegn kan "bety" mange forskjellige ting, så det er neppe "vanlige"). Vanlig tekst er forskjellig fra formatert tekst , der stilinformasjon er inkludert; fra strukturert tekst, der strukturelle deler av dokumentet som avsnitt, seksjoner og lignende identifiseres; og fra binære filer der noen deler må tolkes som binære objekter (kodede heltall, reelle tall, bilder, etc.).
Begrepet brukes noen ganger ganske løst, for å bety filer som bare inneholder "lesbart" innhold (eller bare filer uten noe som høyttaleren ikke foretrekker). For eksempel kan det utelukke enhver indikasjon på fonter eller layout (for eksempel markup, markdown eller til og med faner); tegn som krøllete sitater, mellomrom som ikke bryter, myke bindestreker, em-streker og/eller ligaturer; eller andre ting.
I prinsippet kan ren tekst være i hvilken som helst koding , men noen ganger brukes begrepet for å antyde ASCII . Etter hvert som Unicode- baserte kodinger som UTF-8 og UTF-16 blir mer vanlige, kan bruken bli mindre.
Vanlig tekst brukes også noen ganger bare for å ekskludere "binære" filer: de der i det minste noen deler av filen ikke kan tolkes riktig via tegnkodingen som gjelder. For eksempel er en fil eller streng som består av "hei" (i hvilken som helst koding), etterfulgt av 4 byte som uttrykker et binært heltall som ikke bare er et eller flere tegn, en binær fil, ikke ren tekst av selv den løseste vanlige bruk. Sagt på en annen måte, sette en ren tekst fil til en tegnkoding som bruker helt andre tall for å representere tegn endrer ikke mening (så lenge du vet hva koding er i bruk), men for binære filer slik konvertering gjør endre betydningen minst noen deler av filen.
Vanlig tekst og rik tekst
I følge The Unicode Standard:
- " Vanlig tekst er en ren sekvens av tegnkoder; ren, ikke-kodet tekst er derfor en sekvens av Unicode-tegnkoder.
- I kontrast er stylet tekst , også kjent som rik tekst , enhver tekstrepresentasjon som inneholder ren tekst pluss tilleggsinformasjon som språkidentifikator, skriftstørrelse, farge, hypertekstkoblinger og så videre.
SGML, RTF, HTML, XML og TEX er eksempler på rik tekst som er fullstendig representert som ren tekststrøm, og sprenger ren tekstdata med sekvenser av tegn som representerer de ytterligere datastrukturer. "
I henhold til andre definisjoner regnes imidlertid filer som inneholder markup eller andre metadata generelt som ren tekst, så lenge markeringen også er i direkte lesbar form (som i HTML , XML , og så videre). Dermed blir representasjoner som SGML , RTF , HTML , XML , wiki markup og TeX , samt nesten alle programmeringsspråk kildekodefiler, betraktet som ren tekst. Det bestemte innholdet er irrelevant for om en fil er ren tekst. For eksempel kan en SVG -fil uttrykke tegninger eller til og med bitmappet grafikk, men er fortsatt ren tekst.
Bruken av ren tekst i stedet for binære filer gjør det mulig for filer å overleve mye bedre "i naturen", delvis ved å gjøre dem i stor grad immun mot datamaskinarkitektur inkompatibilitet. For eksempel kan alle problemene med Endianness unngås (med kodinger som UCS-2 i stedet for UTF-8, betyr endianness, men jevnt for hver karakter, i stedet for potensielt ukjente undersett av den).
Bruk
Hensikten med å bruke vanlig tekst i dag er først og fremst uavhengighet fra programmer som krever sin helt egen spesielle koding eller formatering eller filformat . Vanlige tekstfiler kan åpnes, leses og redigeres med allestedsnærværende tekstredigerere og verktøy.
Et kommandolinjegrensesnitt lar folk gi kommandoer i ren tekst og få et svar, også vanligvis i ren tekst.
Mange andre dataprogrammer er også i stand til å behandle eller lage ren tekst, for eksempel utallige programmer i DOS , Windows , klassisk Mac OS og Unix og dets slektninger; så vel som nettlesere (noen få nettlesere som Lynx og linjemodusleseren produserer bare ren tekst for visning) og andre e-tekstlesere .
Vanlige tekstfiler er nesten universelle i programmering; en kildekodefil som inneholder instruksjoner på et programmeringsspråk, er nesten alltid en ren tekstfil. Vanlig tekst brukes også ofte til konfigurasjonsfiler , som leses for lagrede innstillinger ved oppstart av et program.
Vanlig tekst brukes til mye e-post .
En kommentar , en " .txt " -fil eller en TXT -post inneholder vanligvis bare ren tekst (uten formatering) beregnet for mennesker å lese.
Det beste formatet for å lagre kunnskap vedvarende er ren tekst, snarere enn et binært format .
Koding
Tegnkoder
Før begynnelsen av 1960-tallet ble datamaskiner hovedsakelig brukt til tallknusing i stedet for tekst, og minnet var ekstremt dyrt. Datamaskiner tildelte ofte bare 6 biter for hvert tegn, og tillot bare 64 tegn-tildeling av koder for AZ, az og 0-9 ville bare etterlate to koder: ikke i nærheten av nok. De fleste datamaskiner valgte ikke å støtte små bokstaver. Dermed tidlige tekst prosjekter som Roberto Busa 's Index thomisticus , det Brown Corpus , og andre måtte ty til konvensjoner som taste stjerne foregående bokstaver faktisk ment å være store bokstaver.
Fred Brooks fra IBM argumenterte sterkt for å gå til 8-bits byte, fordi en gang vil folk kanskje behandle tekst; og vant. Selv om IBM brukte EBCDIC , ble mest tekst fra da av kodet i ASCII , ved bruk av verdier fra 0 til 31 for (ikke-utskrift) kontrolltegn , og verdier fra 32 til 127 for grafiske tegn som bokstaver, sifre og tegnsetting. De fleste maskiner lagret tegn i 8 biter i stedet for 7, ignorerte den gjenværende biten eller brukte den som en kontrollsum .
Nesten allestedsnærværende av ASCII var til stor hjelp, men klarte ikke å ta opp internasjonale og språklige bekymringer. Dollarsymbolet ("$") var ikke like nyttig i England, og aksenttegnene som ble brukt på spansk, fransk, tysk, portugisisk og mange andre språk var helt utilgjengelige i ASCII (for ikke å snakke om tegn som ble brukt på gresk, russisk, og de fleste østlige språk). Mange individer, selskaper og land definerte ekstra tegn etter behov - ofte tilordnet kontrolltegn eller ved å bruke verdier i området fra 128 til 255. Bruk av verdier over 128 er i konflikt med å bruke den 8. biten som en kontrollsum, men bruk av kontrollsummen ble gradvis død. .
Disse tilleggstegnene ble kodet annerledes i forskjellige land, noe som gjorde tekster umulige å dekode uten å finne ut opphavsmannens regler. For eksempel kan en nettleser vise ¬A i stedet for ` hvis den prøvde å tolke ett tegnsett som et annet. Den internasjonale organisasjonen for standardisering ( ISO ) utviklet etter hvert flere kodesider under ISO 8859 , for å imøtekomme forskjellige språk. Det første av disse ( ISO 8859-1 ) er også kjent som "Latin-1", og dekker behovene til de fleste (ikke alle) europeiske språk som bruker latinbaserte tegn (det var ikke nok plass til å dekke dem alle) . ISO 2022 ga deretter konvensjoner for "bytte" mellom forskjellige tegnsett i mellomfilen. Mange andre organisasjoner utviklet variasjoner på disse, og i mange år brukte Windows og Macintosh -datamaskiner inkompatible varianter.
Tekstkodingssituasjonen ble mer og mer kompleks, noe som førte til innsats fra ISO og Unicode Consortium for å utvikle en samlet, enhetlig tegnkoding som kunne dekke alle kjente (eller i alle fall alle kjente) språk. Etter litt konflikt ble disse innsatsene samlet. Unicode åpner for øyeblikket for 1.114.112 kodeverdier og tildeler koder som dekker nesten alle moderne tekstskrivesystemer, så vel som mange historiske, og for mange ikke-språklige tegn som skriverens dingbats , matematiske symboler, etc.
Tekst regnes som ren tekst uavhengig av kodingen. For å forstå eller behandle det på riktig måte må mottakeren vite (eller kunne finne ut) hvilken koding som ble brukt; Imidlertid trenger de ikke å vite noe om datamaskinarkitekturen som ble brukt, eller om de binære strukturene som er definert av hvilket program (hvis noen) som opprettet dataene.
Den kanskje vanligste måten å eksplisitt angi spesifikk koding av ren tekst er med en MIME -type . For e -post og HTTP er standard MIME -type " tekst/ren " - ren tekst uten merking. En annen MIME-type som ofte brukes i både e-post og HTTP er " text/html ; charset = UTF-8"-ren tekst representert ved bruk av UTF-8-tegnkodingen med HTML-markering. En annen vanlig MIME-type er "application/json"-ren tekst representert ved bruk av UTF-8-tegnkodingen med JSON- markering.
Når et dokument mottas uten noen eksplisitt indikasjon på tegnkodingen, bruker noen applikasjoner tegnsettdeteksjon for å prøve å gjette hvilken koding som ble brukt.
Kontrollkoder
ASCII reserverer de første 32 kodene (tall 0–31 desimal) for kontrolltegn kjent som "C0 -settet": koder som opprinnelig var ment ikke å representere utskrivbar informasjon, men heller for å kontrollere enheter (for eksempel skrivere ) som bruker ASCII, eller å gi metainformasjon om datastrømmer som de som er lagret på magnetbånd. De inkluderer vanlige tegn som den nye linjen og fanen .
I 8-bits tegnsett som Latin-1 og de andre ISO 8859- settene, er de første 32 tegnene i "øvre halvdel" (128 til 159) også kontrollkoder, kjent som "C1-settet". De brukes sjelden direkte; når de dukker opp i dokumenter som tilsynelatende er i en ISO 8859-koding, refererer kodeposisjonene generelt i stedet til tegnene på den posisjonen i en proprietær, systemspesifikk koding, for eksempel Windows-1252 eller Mac OS Roman , som bruker kodene å i stedet gi flere grafiske tegn.
Unicode definerer flere kontrolltegn, inkludert toveis tekstoverstyringstegn (brukes til eksplisitt å markere høyre-til-venstre-skriving inne i venstre-til-høyre-skriving og omvendt) og variasjonsvelgere for å velge alternative former for CJK-ideografer , emoji og andre karakterer.