Går det att ställa FM så att den skapar UTF8 istället för UTF16 i"exportera fält"?

Tråden skapades och har fått 11 svar. Det senaste inlägget skrevs .
1
  • Medlem
  • Stockholm
  • 2009-09-09 13:39

Hejsan,
Går det att ställa om FileMaker så att den spottar ut UTF8 i Stället för UTF16?

Som det är nu så skapar MANUS-funktionen "exportera fält" i manushanteraren en UTF16-fil. ( i båda plattformarna) Något som t ex webbläsare inte gillar.

Har Tittat på Troj, det löser problemet - men då tillkommer massor av extra kod och krångel och "onödiga" kostnader i flera skikt som också hamnar utanför "standard".

Det vore bättre om det finns ett sätta at ställa in FM - så att den skapar UTF-8 direkt när man använder manusfunktionen "Exportera fältinnehåll"... t ex med Terminal eller dylikt...Är det nå'n som vet eller kan?

Frågan avser både PC och MAC (ska funka i båda plattformarna).

Det löjliga är att "exportfunktionerna" av poster ger möjlighet att välja flera olika format - men den vägen fungerar i övrigt inte för mitt syfte = att lyfta över skapad text direkt från ett fält till ett nytt, skapat .txt eller .html -dokument.

/ Tacksam för svar - man vet aldrig kanske det finns en bra lösning som gör att man kan behålla namnet / 2lazy

Senast redigerat 2009-09-09 14:45

Tja, här kanske?

Fast det är väl för export av poster? Exportera *fältinnehåll* tillåter inte den kontrollen.

Har problem med detta också - jag exporterar ut en egensnickrad XML fil som Excel (Windows) sväljer utan vidare, men SCalc i OpenOffice fixar inte UTF16 och klarar inte av att öppna filen utan vidare.

/CX

Ledsen, men ibland orkar man inte läsa noga, meningen är för svår att hitta.

Exportera fältinnehåll är till för att exportera filer i containerfält, är det inte? Så har man importerat pdf-filer i ett fält, eller word-dokument, är det aktuellt att göra exportera fältinnehåll.

I det här fallet verkar 2Lazy vilja skapa webbsidor, som är exporterade från FileMaker.

Då skall man göra som jag skrev, men istället för att peka på tidigare trådar i ämnet, så är arbetsgången i scriptet att:

Ha ett variabelfält som är webbsidans "start". I den lägger man in <HTML> och även vilken encoding man kör med.

Ha ett variabelfält som är webbsidans "slut".

Ha ett variabelfält som är webbsidans "mitten". Det fyller man på genom att loopa igenom de poster som skall exporteras.

Sedan sätter man ihop början, mitten och slutet i samma variabelfält, mittenfältet.

Man visar sedan en post (visa alla, uteslut, visa endast uteslutna. Detta ger endast en post).

Sedan exporterar man endast ett fält (mittenfältet). Så får man en fin webbsida, med rätt encoding och rätt innehåll, rätt namn, rätt plats.

Vill man läsa mera om detta så finns det hastigt och slarvigt beskrivet i inlägg 14 i denna tråd:

http://www.99.se/filemaker/243619-moejligt-med-hemsida.html

Mera om att webbpublicera FileMaker i denna tråd: http://www.99.se/filemaker/262072-publicera-filemaker-pa-naetet.html (det finns många många fler).

  • Medlem
  • Stockholm
  • 2009-09-10 11:57

Tack TAZ - men dina förslag är bra, men det blir en omväg

Som det är nu så har jag en mycket komplicerad process, som automatiskt skapar flera sammankopplade html-sidor (med java+html+xml +ajax) beroende av en rad olika variabler, tabeller och bockade förhållanden. Allt detta sker genom en process med Manushanterarens PGM, där man t ex kan utvidga antal "träd och grenar" oändligt eller flytta/byta plats på information.

Har problem att få ut "ren text" från exportera poster-funktionen, den som blir bäst är TAB, men kräver/motiverar manuellt arbete med att städa i koden (alla radbrytningar försvinner).
(Exportera postfunktionen använder jag ibland för att exportera ren kod - som delinnehåll till STATISKA sidor jag bygger manuellt.)

Ska titta på en lösning, enligt ditt förslag, genom att skapa minst 4 nya tabeller, (det går åt en tbl- per dokument) som skapar en post per respektive fält från nuvarande tabell, och sen exportera detta med "exportera poster", som alternativ. Eller så får man välja en tabell med flera fält, som exporterafuntionen väljer ut i 4 olika varianter - det är nog smartare.

Den enda kod som inte behöver konverteras på detta sätt i så fall är ju den tidigare som exporterar containerfälten. Kanske ska jag bygga om mina manus så att skapar-processen går direkt till dessa "nya extra" tabeller.

Har vant mig vid Troj - som har vettiga funktioner, kan bl annat skapa nya mappar i systemet, vilket jag ser kommer öka användarvänligheten i det jag bygger. Men det är lite "pest eller kolera" eftersom alla användare sen måste köpa Troj ( och installera den) i sina datorer.

Den mest framkomliga vägen är, trots allt, att exportera fältinnehåll - direkt till fil, eftersom den ger full kontroll på innehåll och utseende.

Därför undrar jag fortfarande om det inte går att sätta upp UTF-8 som default genom att "hacka" i koden för FM - det skulle bli tusen gånger enklare, sedan.

Quark Xpress hade ett fel i utskriftsfunktionerna, när man skulle skapa pdf via denna. Detta har jag en lösning på som jag kör via "terminal" - pgm-et.

Det skulle vara JÄTTE-smutt om det går att göra något liknande med FM, eller hacka den en gång för alla....

/2Lazy

Senast redigerat 2009-09-10 13:40

Mitt förslag var alltså inte att skapa fyra nya tabeller! Inte heller att ha en post per fält. Då missförstod du mig rejält.

I mina ögon verkar det som om du går över ån efter vatten och har hittat på ett sätt att lösa ett problem du haft där du inte förstått vilka andra möjligheter som finns att lösa samma problem. Du verkar även sätta upp tekniska förutsättningar som dessutom omöjliggör vettigare lösningar och därmed har du startat en ny tråd där du ber om att någon skall "hacka FileMaker" för att få den att göra det onödigt krångliga du tror är enda vägen att gå.

Tanken att faktiskt använda Troi (med i) File Plugin eller File Fire som är en annan plugin som gör samma sak eller låta FileMaker använda sig av Applescript, eller låta FileMaker prata med MySQL eller med ett CMS eller skicka terminalkommandon direkt som skapar din fil eller låta filemaker exportera vadsomhelst och man rättar till det efteråt med applescript/terminalen, eller bevakade mappar, eller x eller y eller z (det finns ett gäng lösningar som alla är bättre än att "hacka filemaker") verkar inte förekomma i din värld så....

http://en.wikipedia.org/wiki/Workaround

Men då jag inte förstår vad du sysslar med och inte kan utläsa detta från dina inlägg, så avbryter jag här och gör något annat istället. Jag önskar dig lycka till.

  • Medlem
  • Stockholm
  • 2009-09-30 21:12

Det blev Troi - både bra och dålig lösning

Troi löser alla problemen ypperligt - på bekostnad av nackdelen för kunden att behöva köpa och installera den. (och för framtida andra kunder också.)

En ytterligare funktion som gjorde att vi fastnade för Troi var möjligheten att säkerhetskopiera de mappar vi sen låter FM ersätta.

Troi ökade och utvidgade däremot uppdraget.

Vår lösning (variablernas värden skapar resultatet) innebär att kunden skapar sina egna hemsidor (respektive rätt sida styrs av FM) genom ett enda knapptryck. Den kan publicera och underhålla 1000-tals produkter, just nu på 5 huvudrubriker med "just nu" 43 subrubriker... som sen integreras med övriga statiska sidor.

Alla sidor med vår design, CSS 2.1 - standard och grafisk anpassade till kundens Corporate, och helt utan fel i w3 - kontroller och med en visningshastighet som slår en servers- eftersom vi utnyttjar HTML traditional. (som går att öka ytterligare via enkelt javascript "BODY-onLoad")
Det är svårigheten med standardmallar som håller oss borta från Jomla och Drupal där det också saknas ansvarighet för buggar mm.

Genom att vi utnyttja importfunktionerna - så motsvarar en timmes Databasarbete därmed ca 2-3 dagars överföring via traditionella cms-verktyg, så där har vi överträffat målet.

Det man undrar över nu - är väl hur stor en FM-fil kan bli utan att man man slår huvudet i taket - vi är redan uppe i flera hundra Mb. Förmodligen är gränsen större än vad som är rimligt att hantera...

Tack TAZ - dina råd är bra, och just tack vare ett av dina tidigare inlägg så hittade vi Troi.;)
/2Lazy

Kul att du hittade en fungerande lösning.

Teknisk specifikation för FileMaker finns i detta inlägg:
http://www.99.se/filemaker/252620-begraensningar-i-filemaker.html

Hej

Behövde också få ut UTF-8 för några veckor sedan genom att exportera fältinnehåll. Då till en XML-fil. Kom på en lösning med att använda en XSLT-formatmall i samband det och använda den vanliga exportmetoden i stället. Man uppnår samma funktionalitet som exportera fältinnehåll som exportera endast en post. I headern på XSLT:n kan man definiera vad som skall komma ut; i mitt fall:

<xsl:output method="text" version="1.0" encoding="UTF-8" omit-xml-declaration="yes" indent="no"/>

Fungerar riktigt bra.

  • Oregistrerad
  • 2009-11-04 22:11

Ska du göra det många ggr?

Om det är en engångsföretelse så kan du importera filen i exempelvis Coda och konvertera den till UTF-8 och spara, sen importera den dit du vill.

  • Medlem
  • 2009-11-05 09:34

PHP Shellscript/applescript är oxå en ide

Jag kör FM 5.5 och brukar göra följande när inte FM kan göra det jag vill;

Ett script i filemaker som triggar ett applescript och sedan ett shellscript som gör det jag vill få gjort. Enklast är att lägga shellscriptet i Library/webServer/Documents/ för att inte få problem med rättigheter.

Använder det bland annat till;
FTP:ande
Kod128 generering
Automatiskt byte av skrivare

Liten skiss på hur shellscriptet skulle kunna se ut (Glöm inte att göra den executable)
$argv[1] ger filnamnet som du skriver direkt efter shellscriptsanropet (kolla äpplescriptet nedan)

#!/usr/bin/php
<?php

#  Läs textfil($argv[1])
# Låt iconv konvertera texten
# Spara textfil

?>
do shell script "Library/WebServer/Documents/convert.php  utf16text.txt"

Det borde lösa dina problem samt ge dig möjllighet att skapa foldrar m.m. utan att ha bekymmer med eventuella licenser

1
Bevaka tråden