- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
We're trying to allow our users to use filenames named in their native languages. It seems that Fortran doesn't allow it, at least not in a way we can figure out. ENCODING='UTF-8' seems to apply to the file's contents and not the filename itself. We are using a standard Windows File Dialog to capture the filename and sending it to Fortran to open/read/write/close.
this is a sample filename (copied from the "I can eat glass" page - http://www.columbia.edu/kermit/utf8.html):
this is a sample filename (copied from the "I can eat glass" page - http://www.columbia.edu/kermit/utf8.html):
wchar_t* fn2 = L"c:\\\\.c";
CONVERTME(fn2);
Fortran code:
Subroutine ConvertMe(fileName)
INCLUDE 'for_iosdef.for'
!DEC$ ATTRIBUTES STDCALL,ALIAS:'_CONVERTME@4' :: ConvertMe
INTEGER i;
integer*2 fileName(260)
Open(file = fileName,unit=12,err=900,status='unknown',ENCODING='UTF-8',iostat=ios)
Write(12,*,iostat=ios) ' I am Fortran. I rule the world '
Close(12)
return
Any ideas? We're desparate; this is on our critical path for an upcoming release...
Ссылка скопирована
7 Ответы
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
I don't know whether Fortran can implement unicode, but one fairly easy workaround would be to use the Win32 API functions, CreateFile(), ReadFile(), WriteFile() which can be called directly from IVF and are superfunctional (ie much better than the originals) replacements for native Fortran file i/o; in fact, your C shell could open the file and simply pass its handle back to the Fortran. The main difference is that a file is opened to a Win32 handle which is not interchangeable with a Fortran unit number, so you would have to implement the change to handle-driven functions throughout the file i/o, at least for that section of your program; also, read/writes are direct byte dumps, so formatting has to be done separately (but may no longer be necessary). I have previously posted a module illustrating use of Win32 file i/o from IVF.
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
I thought that Fortran I/O didn't mix with Win32 file handling functions, especially when you have FORM='BINARY', RECL=2048, ACCESS='DIRECT'.
I'll go back and search for your code; I'll be very happy if I can use a READ(IOUNIT,REC=4,ERR=9000) with a Win32 handle...
I'll go back and search for your code; I'll be very happy if I can use a READ(IOUNIT,REC=4,ERR=9000) with a Win32 handle...
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
The Fortran standard specifies that the FILE= specifier is a "scalar default character expression". While the standard allows for alternate character kinds, it is not required that they be supported. As you note, ENCODING is for the file contents only.
Fortran I/O always uses Win32 routines. But you should look at the USEROPEN specifier to OPEN which allows you to insert a routine to handle the actual file opening.
Fortran I/O always uses Win32 routines. But you should look at the USEROPEN specifier to OPEN which allows you to insert a routine to handle the actual file opening.
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
Correct; a Fortran i/o unit is not the same as a Win32 file handle, so you cannot intermix Fortran READ and WRITEs with Win32 API calls (as explicitly noted in my posting). Your READ statements would need to be replaced with something like this:
[bash]IF (.NOT.ReadFile (ihandl, & ! file handle loc_pointer, & ! address of data nbytes, & ! byte count to read LOC(nact), & ! actual bytes read NULL_OVERLAPPED)) THEN GO TO 9000 END IF [/bash]
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
With USEROPEN you may not have to do that. You'll have to have the filename in a module variable or some other place the routine can get it.
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
USEROPEN with a MODULE that contains the integer(2) path seems to work fine. I didn't see an equivelent USEROPEN function for INQUIRE, though. Any suggestions?
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
There isn't anything similar for INQUIRE. Perhaps you could keep your own table of filename/unit-number pairs, do a lookup first and then do INQUIRE by unit. Ugly, I know.

Ответить
Параметры темы
- Подписка на RSS-канал
- Отметить тему как новую
- Отметить тему как прочитанную
- Выполнить отслеживание данной Тема для текущего пользователя
- Закладка
- Подписаться
- Страница в формате печати