Hi all

I've been developing a database that allows my database to update certain pages of a website with information on my database however I'm having trouble exporting it in utf 8. In normal circumstances I wouldn't mind going through the pages and re-encoding them in Notepad++ but when it comes to several pages, I need an automated solution. Can anyone provide a preferably free way to do this.

Thanks

Ineva.

You need to tell use what you're doing that you can't export as utf-8. Because it is one of the Export options. Perhaps you are actually trying to Export Field Contents instead, which is always utf-16.

A solution is to use the regular Export, with only 1 record found, just that one field. One method to do this without disrupting the found set is to create a New Window, Show All Records, Omit Record, Show omitted only, Export, Close window.

ok since more detail is required here goes..I have 2 tables

Table_IMPORT_HTML

Fields - HTML_CODE_LINE

Table_EDIT_HTML

Fields - HTML_CODE

there are more fields but they arent required here.

to import a html document I do the following

Delete all records in Table_IMPORT_HTML

Import HTML file which imports each line of the HTML doument as a new record

I then copy all records in Table_IMPORT_HTML and paste them in Table_EDIT_HTML::HTML_CODE

---

edits are made to the field

---

then I export field contents, which as you said only exports as utf 16

Fenton I tried what you said but when you export like that it forces it all into a HTML table

What do you mean by "it forces it into a HTML table"?

Oh see my code from filemaker

Well, it could be just because your computer thinks it is an html file, and supplies a table (for some reason). I'd advise you to open it with a text editor, ie., something other than a web browser. Are you giving it an extension of ".htm"? It is probably fine; Internet Explorer is rendering it how it thinks fit.

I believe this is a product of exporting as HTML table. Which of course makes no sense, because if the field contains HTML code, exporting it to a HTML table will result in HTML code in a table - exactly as shown.

Exporting from FM would naturally escape out all necessary HTML entities to appropriately display the field information. Imagine what would happen if someone exported 200 records with 10 fields and one of those fields in on of those records had: - the whole structure would collapse.

Specifically, the entities that are escaped in this case are: < and >.

Your preferably free way of doing this would be opening it up in Notepad++ and replacing all occurances of &lt ; with < and &gt ; with > ... that or just copy and paste the field content.

I can't really see what it is you're trying to achieve though.

Comment has made the point. You want to Export (a single field) as tab-separated text (with an extension of ".htm". You do not want to Export as HTML. Sounds kind of the same, but is not the same. HTML leads a double life.

true, but now encoding with tab separated files leads to strange characters which 'can' be eliminated by eliminating the carriage returns in the filemaker field. Doing this however makes the html code almost unreadable since it looses its structure. Is it possible to say insert a utf-8 carriage return at the end of each line while eliminating the filemaker carriage returns?

Edited October 21, 200718 yr by Guest

... Why do you care if your html is readable?

Yes, that character is ASCII character 11 (Vertical Tab, I think). I don't have that problem on my Mac, as I can write the file directly via command line, which translates the character to a return.

Here's another possibility. Export XML, with this XSL stylesheet. It is written for only 1 record, 1 field. Otherwise you'd have to add more.

<?xml version="1.0" encoding="utf-8"?>



xmlns:fm="http://www.filemaker.com/fmpxmlresult" exclude-result-prefixes="fm" >

	

	

		

	

quite simple really genx, My database will be editing html files that have sections of code that are specifically edited by myself where other parts have to be edited by other people..this arrangement cannot be changed and since it is out of my control I am trying to develop a solution similar to the way that dreamweaver handles templates to insert and edit the section of code I am responsible for.

- Fenton I keep getting errors for that xsl code, I dont know much about xml

ERROR:(in regards to the code you gave)

Fatal error at line 0 column 0 .... could not find primary document entity

How odd,

Fair enough though. I'd help but i'm fairly useless when it comes to XSL, good luck anyway.

Well, Filemaker is not Dreamweaver. Unless you export as XML with a XSL stylesheet, the only way you're going to get proper carriage returns between lines is by making each line a separate record.

I could understand keeping the actual DATA for the site in a database, then exporting new pages (via XML/XSL directly to HTML) as the data is updated. But using Filemaker for maintaining the actual HTML code seems like a poor choice.

I don't know why you're getting the error. Here is an example file(s). Line endings (of the xsl) are Unix, 'cause that's what I use; should work on either platform.

HTML_Export_1_field.zip

Thats what I was looking for Fenton..I was copy/pasting the xsl data into the field upon prompt which was probably the problem...

Re:Comment...I don't like it either but as I've said its out of my hands.

Thanks all...

You can use Export Field Contents, which is a fine and simple function to make includes on php webpages.

As mentioned, the files that are made are in utf16 format, with a Byte Order Mark at the beginning.

You must find your solution not within Filemaker but within your webpage to cope with the utf16 problem

http://www.moddular.org/log/utf16-to-utf8

Here is a beautiful utf16 to utf8 translation function (php). Extend it a bit so that it gets the include file to translate, but also puts the file back as utf8. When it gets the file a second time, and finds no utf16 Byte Order Mark, it concludes it is utf8 and will pass it through without translation. But you have to adapt the php for that. Not too difficult.

Happy including

Harry

Fenton--Thanks! this solved a problem for me too.

FYI...there were 2 characters missing from the first element in the previous post. I think the forum engine stripped this out so here's the xsl without the 'code' formatting...

<?xml version="1.0" encoding="utf-8"?>

Edited March 11, 201015 yr by Guest