cffile and UTF-8

Ok, I just sent them to you.

Paul,

You said here:

"don't use either "

I think that the party I am sending this file to is just opening the file in Notepad ++ and when he sees it says ANSI there he requests a different file. This file is supposed to be processed in their servers but I haven't got any output from the processing software just the feedback from this guy that administers the servers.

This turned out to be a big project in time terms for me.

Thanks a lot!

apocalipsis19 wrote:
> The file should just be UTF-8. That would solve my problem.

again, can i see a zipped up version before & after uploading?

Thanks Paul!

The file should just be UTF-8. That would solve my problem.


I am just opening the file in those text editors to see the encoding of the file.

Mack wrote:
> I found this java bug that is related to the problem. It's about reading
> UTF-8 files with BOM but if it's not transparent on read I doubt it's
> tranparent on write:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4508058

and sun marked that "bug" as "Closed, Will Not Fix". sun's not going to fix
something that it considers not "broken" (there are also "bugs" related to java
not compiling source with a BOM as well) or that will create backwards
compatibility problems--a BOM is optional for utf-8 (and pretty much useless in
utf-8 anyway) but required for utf-16 which java handles ok (if i remember rightly).

and just an FYI, sun usually gives i18n bugs short shrift. some locale resource
bugs (and i mean real bugs like stuff where the get currency/numeric formatting
dead wrong) have been around for >5 years.

apocalipsis19 wrote:
> Well,
>
> I have done further research on this issue and all of my code is correct. The
> problem is the underlying JVM. It does nor properly support adding the Byte
> Order Mark to a UTF-8 file. Some people suggest adding the file through Java
> code inside the cfscript tags.
>
> I will look into deeper into this and I continue to appreciate any ideas you
> guys give me!

I found this java bug that is related to the problem. It's about reading
UTF-8 files with BOM but if it's not transparent on read I doubt it's
tranparent on write:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4508058

--
Mack

apocalipsis19 wrote:
> I have done further research on this issue and all of my code is correct. The
> problem is the underlying JVM. It does nor properly support adding the Byte
> Order Mark to a UTF-8 file. Some people suggest adding the file through Java

a BOM is *optional* for utf-8 by definition (and if you read the definition
you'll see why it's also pretty much un-needed). is the app on the other end
expecting a BOM?

> code inside the cfscript tags.

if your research is correct about the JVM & BOM writing (i think not, it's
optional so the app should handle writing it to a new file), then it's six of
one, half dozen of the other.


what is the app on the other end expecting *exactly*? can you put up the before
& after data (zipped up to preserve encoding)?

Well,

I have done further research on this issue and all of my code is correct. The problem is the underlying JVM. It does nor properly support adding the Byte Order Mark to a UTF-8 file. Some people suggest adding the file through Java code inside the cfscript tags.

I will look into deeper into this and I continue to appreciate any ideas you guys give me!

Thanks!

Ysais.

apocalipsis19 wrote:
> My problem still persists.

I think you have only 2 steps CFFILE and CFFTP. I'd check after each
step if the file is *really* UTF-8 reducing the problem in half.

--
Mack

My problem still persists.