Przemyslaw Czerpak escribió: > On Tue, 03 Feb 2009, Miguel Angel Marchuet wrote: > > Hi Miguel,
>> the offset 1Dh at DBF/foxpro header tables has ( Language driver ) as >> follow: >> (Foxpro) Code page: These values follow the DOS / Windows Code Page values. >> Value Description Code page >> 01h DOS USA code page 437 >> 02h DOS Multilingual code page 850 >> 03h Windows ANSI code page 1252 >> 04h Standard Macintosh >> 64h EE MS-DOS code page 852 >> 65h Nordic MS-DOS code page 865 >> 66h Russian MS-DOS code page 866 >> 67h Icelandic MS-DOS >> 68h Kamenicky (Czech) MS-DOS >> 69h Mazovia (Polish) MS-DOS >> 6Ah Greek MS-DOS (437G) >> 6Bh Turkish MS-DOS >> 96h Russian Macintosh >> 97h Eastern European Macintosh >> 98h Greek Macintosh >> C8h Windows EE code page 1250 >> C9h Russian Windows >> CAh Turkish Windows >> CBh Greek Windows this is full table supporte for old foxpro not vfp ( see below for vfp) >> I purpose to save this information at DBF, and use this collation >> at dbfCompare, to sort properly the tables. >> We can add too other code pages that are created at harbour. > > The above list does not cover collation orders well, f.e.: > 64h EE MS-DOS code page 852 > Informs only about used CP but we still do not know we should > sort using: CS852, HR852, HU852, PL852, RO852, SK852, SL852, ... > Only in few cases the FoxPro CP ID determinate exact CP with > collation order, f.e.: > 69h Mazovia (Polish) MS-DOS > which is PLMAZ so at beginning you have something what cannot > work well. Of course we can try to hard code our own CP IDs > but IMHO first we should clean our own CODEPAGE subsystem > because the final version may be different then the current > one and such mapping cannot be longer supported. It will be > very serious compatibility problem because we will have old > IDs in existing DBFs. > Adding the above modification is about 30 minute of work. > Updating it to new CP may take days if it's possible at all. > The only implementation which we can add now should be only > for strict VFP compatibility (it should check DBF signature > for 0x3[01]) and should not make any modifications in our CP > code so it should keep the translation table (ourCP<->fpCP) > in own structures. I think it can be added as separate GT > which inherits from DBF* ones (f.e. VFPCDX) so it's not > necessary to touch existing RDD code. this codes are for old foxpro dbf not for current vfp > BTW does anyone have full list of above FoxPro CP identifiers? CPDBF([nWorkArea | cTableAlias]) -> Returns the code page with which an open table has been marked. This are all codepages supported by vfp: Code page Platform Code page identifier 437 U.S. MS-DOS x01 620 * Mazovia (Polish) MS-DOS x69 737 * Greek MS-DOS (437G) x6A 850 International MS-DOS x02 852 Eastern European MS-DOS x64 857 Turkish MS-DOS x6B 861 Icelandic MS-DOS x67 865 Nordic MS-DOS x66 866 Russian MS-DOS x65 874 Thai Windows x7C 895 * Kamenicky (Czech) MS-DOS x68 932 Japanese Windows x7B 936 Chinese (PRC, Singapore) Windows x7A 949 Korean Windows x79 950 Chinese (Hong Kong SAR, Taiwan) Windows x78 1250 Eastern European Windows xC8 1251 Russian Windows xC9 1252 Windows ANSI x03 1253 Greek Windows xCB 1254 Turkish Windows xCA 1255 Hebrew Windows x7D 1256 Arabic Windows x7E 10000 Standard Macintosh x04 10006 Greek Macintosh x98 10007 * Russian Macintosh x96 10029 Macintosh EE x97 * Not detected when you include CODEPAGE=AUTO in your configuration file. http://msdn.microsoft.com/en-us/library/8t45x02s(VS.71).aspx > > ps. I've seen that you added BlobExport() and BlobImport() functions > to xHarbour CVS. > They were not missing. Clipper also does not have them. > In Clipper and [x]Harbour all Blob*() functions are only > PP directives defined in blob.ch thks, i found one problem, when users of ourxdbu try to write code using BlobImport, macro evaluator not found this function :(, I think can be good idea to add synonim fo DbFileGet and DbFilePut too as BlobImport, BlobExport and others to help macroevaluator to solve this type of code, of course i can say too users, that BlobImport is not a function. :( What do you think? Best regards, Miguel Angel Marchuet ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
