Svarsfiler i Disbyt

[penguinfriend]

Disbyt-basen har varit med så länge, så den första teckenuppsättningen i basen var ASCII-7. I dagsläget är teckenuppsättningen ANSI-8.

Med ASCII-7 menas ASCII (hoppas jag)
Med ANSI-8 menar du säkert ISO/IEC 8859-1 som också kan kallas Windows code page. ANSI-8 finns inte deklarerat

Filer som tas emot checkas för olika teckenformat: ASCII, ANSI, MAC, UTF8 mm men konverteras till ANSI. Det innebär att vi inte tar höjd för alla teckenvarianter som finns i UTF8. Å andra sidan har fokus på Disbyt alltid varit svenskt material, så en total internationalisering har inte varit aktuellt.



Att konvertera teckenformat i själva Disbyt-basen till UTF8 kräver mycket arbete med att kolla koden. Delar av koden har mer 25 år på nacken. Det är ingen högprioriterad fråga i dagsläget.

När det gäller teckenformat på resultatfilerna i Disbyt, så är jag ganska säker på att de som skickar in material med MAC-teckenkodning får tillbaka resultatet i samma format. Jag trodde nog att det också gällde de som använder olika PC-teckenkodningar, men jag får kolla det framöver när jag är tillbaka i Sverige.

Med hälsning från Stillwater, Minnesota
/Olof C

Min Gedcomfil har följande infi i headern

2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR UTF-8
1 LANG Swedish

men när jag får mina svarsfiler ser det ut som följer: (utdrag från A****.TXT)
Först så varnar den att det är en binär fil och sedan ser det ut:

Resultat av DISBYT-s<F6>kning med s<F6>kfil f<F6>r medlem 49812 utf<F6>rd 2017-09-24

Niv<E5> 3 - Efternamn och ort <E4>r identiska. <C5>rtalen <F6>verlappande.
Niv<E5> 4 - Hela namnet och orten <E4>r identiska. <C5>rtalen <F6>verlappande.
Niv<E5> 5 - Hela namnet, orten och ett <E5>rtal <E4>r identiska.
Niv<E5> 6 - Hela namnet, orten och b<E5>da <E5>rtalen <E4>r identiska.
Niv<E5> 7 - Hela namnet, orten och ett <E5>rtal <E4>r identiska. Sl<E4>ktingar finns med tr<E4>ffar.
Niv<E5> 8 - Hela namnet, orten och b<E5>da <E5>rtalen <E4>r identiska. Sl<E4>ktingar finns med tr<E4>ffar.

F<F6>r- och efternamn kan vara normerade j<E4>mf<F6>rt med medlemmens egna uppgifter.

dvs den ger ISO/IEC 8859-1 fastän infilen var skriven i UTF-8.

Du skrev också att databasen är skriven i 8 bits men jag bryr mig inte om vad den har för internformat utan vad den ger som utfil. Eftersom teckenuppsättning är jobbigt så
vill jag bara ha utf8 i mina datorer.

Låt detta vara sista ordet i denna tråd.

[DanielBerglund]

men när jag får mina svarsfiler ser det ut som följer: (utdrag från A****.TXT)
Först så varnar den att det är en binär fil och sedan ser det ut:

Vem är "den" som varnar för att det inte är en textfil? Vilket program använder du för att öppna textfiler?

[penguinfriend]

Det är inget progran utan OS (Linux)

Använder 'less' som tool

[DanielBerglund]

Jo, men givetvis finns det program även i Linux, och ett av dem är det du använder för att öppna textfiler. Exempelvis vim, less, more, emacs, nano, ... Så min fråga är helt enkelt vilken texteditor/motsvarande som visar meddelandet att svarsfilen inte är en textfil.

(För din information har föreningen runt 8 servrar som kör Linux så lite kunskap finns det.)

[Ulf A]

En ny version av Disbyt beta-testas för närvarande. I den är all text konverterad till UTF8. Som Olof påpekar är data i Disbyt från olika teckenkoder som använts under 25 års tid. Det har varit ett omfattande och komplicerat arbete att justera teckenkoden till en enhetlig standard. Inte nog med att olika bidrag kommer från olika datorer och länder över tiden. På samma rad kan olika teckentabeller förekomma som konsekvens av att bidraget bearbetats efter leveransen. Det är inte alltid som man kan urskilja vilken teckentabell som använts vid "kontrollen". Det finns heller ingen smart väg att konvertera från ursprung till UTF8. Det mesta kommer dock att visas i UTF8 men det finns säkert rader som inte funkar med den konverterare som gör jobbet. De svarsfiler som omnämns genereras i den nuvarande miljön för kontroll av bidragen och den kommer att användas ett tag till.
/Ulf A (konverterar Disbyt data till ny SQL-databas)

[tommypeters]

Är sökfunktionen i nya versionen förbättrad så den klarar den relativt vanliga varianten (tyvärr...) att man har en namnvariant inom parentes i stället för som mer brukligt (antar jag) en AKA-tag (Also Known As).
När "min" Lisa Christina Johannisdotter i böckerna ibland kallas Stina så kanns det enkelt och tydligt att ha hennes namn skrivet som Lisa Christina (Stina) Johannisdotter. Liknande för emigranter som byter efternamn, då finns det "minst använda" inom parentes.

Problemet är att om jag söker efter Lisa Christina Johannisdotter i Disbyt så hittas inte mina poster för min mormors farfars mor. Jag måste söka efter Lisa Christina (Stina) Johannisdotter för att de ska komma med (och då kommer ju inge poster från andra personer, utan (Stina), med i resultatet.

Det kan ju inte vara så att ett namn inom parentes ska vara tvingande att ha med i sökningen för att posterna ska hittas.

Att det har blivit namn inom parentes ibland är inte bara för synligheten, många program hanterar inte AKA, som väl är ett "Event" utan datum...

[Ulf A]

Förnamn och efternamn rensas på ()[] och enstaka fristående tecken ex. "f". Namnen normaliseras och resultatet läggs i ett sökfält för namn. Ditt exempel "Lisa Christina (Stina)" blir då "lisa kristina stina". Det blir träff på alla namnen enligt normaliseringen t.ex Christina som normaliserats till kristina, just nu åtta varianter christin, christina, chrestina osv. Det finns några som skrivit in förnamn "(H)Anna" och troligen avsett att detta skall vara hanna eller anna. Just nu görs ej denna tolkning utan resultatet blir hanna, dvs ( och ) tas bort. Sökfältet finns bara i bakgrunden och de inskrivna förnamnen och efternamnen visas i oförändrat skick.
Sedan måste söksträngen skrivas in så att det blir träff även på "stina". Flera metoder testas just nu för att få fram ett bra och flexibelt "namnsök".