diff options
Diffstat (limited to 'gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/NOTES')
| -rw-r--r-- | gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/NOTES | 392 |
1 files changed, 0 insertions, 392 deletions
diff --git a/gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/NOTES b/gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/NOTES deleted file mode 100644 index 8f630e23..00000000 --- a/gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/NOTES +++ /dev/null @@ -1,392 +0,0 @@ -Q: Why does libiconv support encoding XXX? Why does libiconv not support - encoding ZZZ? - -A: libiconv, as an internationalization library, supports those character - sets and encodings which are in wide-spread use in at least one territory - of the world. - - Hint1: On http://www.w3c.org/International/O-charset-lang.html you find a - page "Languages, countries, and the charsets typically used for them". - From this table, we can conclude that the following are in active use: - - ISO-8859-1, CP1252 Afrikaans, Albanian, Basque, Catalan, Danish, Dutch, - English, Faroese, Finnish, French, Galician, German, - Icelandic, Irish, Italian, Norwegian, Portuguese, - Scottish, Spanish, Swedish - ISO-8859-2 Croatian, Czech, Hungarian, Polish, Romanian, Slovak, - Slovenian - ISO-8859-3 Esperanto, Maltese - ISO-8859-5 Bulgarian, Byelorussian, Macedonian, Russian, - Serbian, Ukrainian - ISO-8859-6 Arabic - ISO-8859-7 Greek - ISO-8859-8 Hebrew - ISO-8859-9, CP1254 Turkish - ISO-8859-10 Inuit, Lapp - ISO-8859-13 Latvian, Lithuanian - ISO-8859-15 Estonian - KOI8-R Russian - SHIFT_JIS Japanese - ISO-2022-JP Japanese - EUC-JP Japanese - - Ordered by frequency on the web (1997): - ISO-8859-1, CP1252 96% - SHIFT_JIS 1.6% - ISO-2022-JP 1.2% - EUC-JP 0.4% - CP1250 0.3% - CP1251 0.2% - CP850 0.1% - MACINTOSH 0.1% - ISO-8859-5 0.1% - ISO-8859-2 0.0% - - Hint2: The character sets mentioned in the XFree86 4.0 locale.alias file. - - ISO-8859-1 Afrikaans, Basque, Breton, Catalan, Danish, Dutch, - English, Estonian, Faroese, Finnish, French, - Galician, German, Greenlandic, Icelandic, - Indonesian, Irish, Italian, Lithuanian, Norwegian, - Occitan, Portuguese, Scottish, Spanish, Swedish, - Walloon, Welsh - ISO-8859-2 Albanian, Croatian, Czech, Hungarian, Polish, - Romanian, Serbian, Slovak, Slovenian - ISO-8859-3 Esperanto - ISO-8859-4 Estonian, Latvian, Lithuanian - ISO-8859-5 Bulgarian, Byelorussian, Macedonian, Russian, - Serbian, Ukrainian - ISO-8859-6 Arabic - ISO-8859-7 Greek - ISO-8859-8 Hebrew - ISO-8859-9 Turkish - ISO-8859-14 Breton, Irish, Scottish, Welsh - ISO-8859-15 Basque, Breton, Catalan, Danish, Dutch, Estonian, - Faroese, Finnish, French, Galician, German, - Greenlandic, Icelandic, Irish, Italian, Lithuanian, - Norwegian, Occitan, Portuguese, Scottish, Spanish, - Swedish, Walloon, Welsh - KOI8-R Russian - KOI8-U Russian, Ukrainian - EUC-JP (alias eucJP) Japanese - ISO-2022-JP (alias JIS7) Japanese - SHIFT_JIS (alias SJIS) Japanese - U90 Japanese - S90 Japanese - EUC-CN (alias eucCN) Chinese - EUC-TW (alias eucTW) Chinese - BIG5 Chinese - EUC-KR (alias eucKR) Korean - ARMSCII-8 Armenian - GEORGIAN-ACADEMY Georgian - GEORGIAN-PS Georgian - TIS-620 (alias TACTIS) Thai - MULELAO-1 Laothian - IBM-CP1133 Laothian - VISCII Vietnamese - TCVN Vietnamese - NUNACOM-8 Inuktitut - - Hint3: The character sets supported by Netscape Communicator 4. - - Where is this documented? For the complete picture, I had to use - "strings netscape" and then a lot of guesswork. For a quick take, - look at the "View - Character set" menu of Netscape Communicator 4.6: - - ISO-8859-{1,2,5,7,9,15} - WINDOWS-{1250,1251,1253} - KOI8-R Cyrillic - CP866 Cyrillic - Autodetect Japanese (EUC-JP, ISO-2022-JP, ISO-2022-JP-2, SJIS) - EUC-JP Japanese - SHIFT_JIS Japanese - GB2312 Chinese - BIG5 Chinese - EUC-TW Chinese - Autodetect Korean (EUC-KR, ISO-2022-KR, but not JOHAB) - - UTF-8 - UTF-7 - - Hint4: The character sets supported by Microsoft Internet Explorer 4. - - ISO-8859-{1,2,3,4,5,6,7,8,9} - WINDOWS-{1250,1251,1252,1253,1254,1255,1256,1257} - KOI8-R Cyrillic - KOI8-RU Ukrainian - ASMO-708 Arabic - EUC-JP Japanese - ISO-2022-JP Japanese - SHIFT_JIS Japanese - GB2312 Chinese - HZ-GB-2312 Chinese - BIG5 Chinese - EUC-KR Korean - ISO-2022-KR Korean - WINDOWS-874 Thai - WINDOWS-1258 Vietnamese - - UTF-8 - UTF-7 - UNICODE actually UNICODE-LITTLE - UNICODEFEFF actually UNICODE-BIG - - and various DOS character sets: DOS-720, DOS-862, IBM852, CP866. - - We take the union of all these four sets. The result is: - - European and Semitic languages - * ASCII. - We implement this because it is occasionally useful to know or to - check whether some text is entirely ASCII (i.e. if the conversion - ISO-8859-x -> UTF-8 is trivial). - * ISO-8859-{1,2,3,4,5,6,7,8,9,10} - We implement this because they are widely used. Except ISO-8859-4 - which appears to have been superseded by ISO-8859-13 in the baltic - countries. But it's an ISO standard anyway. - * ISO-8859-13 - We implement this because it's a standard in Lithuania and Latvia. - * ISO-8859-14 - We implement this because it's an ISO standard. - * ISO-8859-15 - We implement this because it's increasingly used in Europe, because - of the Euro symbol. - * ISO-8859-16 - We implement this because it's an ISO standard. - * KOI8-R, KOI8-U - We implement this because it appears to be the predominant encoding - on Unix in Russia and Ukraine, respectively. - * KOI8-RU - We implement this because MSIE4 supports it. - * KOI8-T - We implement this because it is the locale encoding in glibc's Tajik - locale. - * CP{1250,1251,1252,1253,1254,1255,1256,1257} - We implement these because they are the predominant Windows encodings - in Europe. - * CP850 - We implement this because it is mentioned as occurring in the web - in the aforementioned statistics. - * CP862 - We implement this because Ron Aaron says it is sometimes used in web - pages and emails. - * CP866 - We implement this because Netscape Communicator does. - * Mac{Roman,CentralEurope,Croatian,Romania,Cyrillic,Greek,Turkish} and - Mac{Hebrew,Arabic} - We implement these because the Sun JDK does, and because Mac users - don't deserve to be punished. - * Macintosh - We implement this because it is mentioned as occurring in the web - in the aforementioned statistics. - Japanese - * EUC-JP, SHIFT_JIS, ISO-2022-JP - We implement these because they are widely used. EUC-JP and SHIFT_JIS - are more used for files, whereas ISO-2022-JP is recommended for email. - * CP932 - We implement this because it is the Microsoft variant of SHIFT_JIS, - used on Windows. - * ISO-2022-JP-2 - We implement this because it's the common way to represent mails which - make use of JIS X 0212 characters. - * ISO-2022-JP-1 - We implement this because it's in the RFCs, but I don't think it is - really used. - * U90, S90 - We DON'T implement this because I have no informations about what it - is or who uses it. - Simplified Chinese - * EUC-CN = GB2312 - We implement this because it is the widely used representation - of simplified Chinese. - * GBK - We implement this because it appears to be used on Solaris and Windows. - * GB18030 - We implement this because it is an official requirement in the - People's Republic of China. - * ISO-2022-CN - We implement this because it is in the RFCs, but I have no idea - whether it is really used. - * ISO-2022-CN-EXT - We implement this because it's in the RFCs, but I don't think it is - really used. - * HZ = HZ-GB-2312 - We implement this because the RFCs recommend it for Usenet postings, - and because MSIE4 supports it. - Traditional Chinese - * EUC-TW - We implement it because it appears to be used on Unix. - * BIG5 - We implement it because it is the de-facto standard for traditional - Chinese. - * CP950 - We implement this because it is the Microsoft variant of BIG5, used - on Windows. - * BIG5+ - We DON'T implement this because it doesn't appear to be in wide use. - Only the CWEX fonts use this encoding. Furthermore, the conversion - tables in the big5p package are not coherent: If you convert directly, - you get different results than when you convert via GBK. - * BIG5-HKSCS - We implement it because it is the de-facto standard for traditional - Chinese in Hongkong. - Korean - * EUC-KR - We implement these because they appear to be the widely used - representations for Korean. - * CP949 - We implement this because it is the Microsoft variant of EUC-KR, used - on Windows. - * ISO-2022-KR - We implement it because it is in the RFCs and because MSIE4 supports - it, but I have no idea whether it's really used. - * JOHAB - We implement this because it is apparently used on Windows as a locale - encoding (codepage 1361). - * ISO-646-KR - We DON'T implement this because although an old ASCII variant, its - glyph for 0x7E is not clear: RFC 1345 and unicode.org's JOHAB.TXT - say it's a tilde, but Ken Lunde's "CJKV information processing" says - it's an overline. And it is not ISO-IR registered. - Armenian - * ARMSCII-8 - We implement it because XFree86 supports it. - Georgian - * Georgian-Academy, Georgian-PS - We implement these because they appear to be both used for Georgian; - Xfree86 supports them. - Thai - * TIS-620 - We implement this because it seems to be standard for Thai. - * CP874 - We implement this because MSIE4 supports it. - * MacThai - We implement this because the Sun JDK does, and because Mac users - don't deserve to be punished. - Laotian - * MuleLao-1, CP1133 - We implement these because XFree86 supports them. I have no idea which - one is used more widely. - Vietnamese - * VISCII, TCVN - We implement these because XFree86 supports them. - * CP1258 - We implement this because MSIE4 supports it. - Other languages - * NUNACOM-8 (Inuktitut) - We DON'T implement this because it isn't part of Unicode yet, and - therefore doesn't convert to anything except itself. - Platform specifics - * HP-ROMAN8, NEXTSTEP - We implement these because they were the native character set on HPs - and NeXTs for a long time, and libiconv is intended to be usable on - these old machines. - Full Unicode - * UTF-8, UCS-2, UCS-4 - We implement these. Obviously. - * UCS-2BE, UCS-2LE, UCS-4BE, UCS-4LE - We implement these because they are the preferred internal - representation of strings in Unicode aware applications. These are - non-ambiguous names, known to glibc. (glibc doesn't have - UCS-2-INTERNAL and UCS-4-INTERNAL.) - * UTF-16, UTF-16BE, UTF-16LE - We implement these, because UTF-16 is still the favourite encoding of - the president of the Unicode Consortium (for political reasons), and - because they appear in RFC 2781. - * UTF-32, UTF-32BE, UTF-32LE - We implement these because they are part of Unicode 3.1. - * UTF-7 - We implement this because it is essential functionality for mail - applications. - * C99 - We implement it because it's used for C and C++ programs and because - it's a nice encoding for debugging. - * JAVA - We implement it because it's used for Java programs and because it's - a nice encoding for debugging. - * UNICODE (big endian), UNICODEFEFF (little endian) - We DON'T implement these because they are stupid and not standardized. - Full Unicode, in terms of `uint16_t' or `uint32_t' - (with machine dependent endianness and alignment) - * UCS-2-INTERNAL, UCS-4-INTERNAL - We implement these because they are the preferred internal - representation of strings in Unicode aware applications. - -Q: Support encodings mentioned in RFC 1345 ? -A: No, they are not in use any more. Supporting ISO-646 variants is pointless - since ISO-8859-* have been adopted. - -Q: Support EBCDIC ? -A: No! - -Q: How do I add a new character set? -A: 1. Explain the "why" in this file, above. - 2. You need to have a conversion table from/to Unicode. Transform it into - the format used by the mapping tables found on ftp.unicode.org: each line - contains the character code, in hex, with 0x prefix, then whitespace, - then the Unicode code point, in hex, 4 hex digits, with 0x prefix. '#' - counts as a comment delimiter until end of line. - Please also send your table to Mark Leisher <mleisher@crl.nmsu.edu> so he - can include it in his collection. - 3. If it's an 8-bit character set, use the '8bit_tab_to_h' program in the - tools directory to generate the C code for the conversion. You may tweak - the resulting C code if you are not satisfied with its quality, but this - is rarely needed. - If it's a two-dimensional character set (with rows and columns), use the - 'cjk_tab_to_h' program in the tools directory to generate the C code for - the conversion. You will need to modify the main() function to recognize - the new character set name, with the proper dimensions, but that shouldn't - be too hard. This yields the CCS. The CES you have to write by hand. - 4. Store the resulting C code file in the lib directory. Add a #include - directive to converters.h, and add an entry to the encodings.def file. - 5. Compile the package, and test your new encoding using a program like - iconv(1) or clisp(1). - 6. Augment the testsuite: Add a line to each of tests/Makefile.in, - tests/Makefile.msvc and tests/Makefile.os2. For a stateless encoding, - create the complete table as a TXT file. For a stateful encoding, - provide a text snippet encoded using your new encoding and its UTF-8 - equivalent. - 7. Update the README and man/iconv_open.3, to mention the new encoding. - Add a note in the NEWS file. - -Q: What about bidirectional text? Should it be tagged or reversed when - converting from ISO-8859-8 or ISO-8859-6 to Unicode? Qt appears to do - this, see qt-2.0.1/src/tools/qrtlcodec.cpp. -A: After reading RFC 1556: I don't think so. Support for ISO-8859-8-I and - ISO-8859-E remains to be implemented. - On the other hand, a page on www.w3c.org says that ISO-8859-8 in *email* - is visually encoded, ISO-8859-8 in *HTML* is logically encoded, i.e. - the same as ISO-8859-8-I. I'm confused. - -Other character sets not implemented: -"MNEMONIC" = "csMnemonic" -"MNEM" = "csMnem" -"ISO-10646-UCS-Basic" = "csUnicodeASCII" -"ISO-10646-Unicode-Latin1" = "csUnicodeLatin1" = "ISO-10646" -"ISO-10646-J-1" -"UNICODE-1-1" = "csUnicode11" -"csWindows31Latin5" - -Other aliases not implemented (and not implemented in glibc-2.1 either): - From MSIE4: - ISO-8859-1: alias ISO8859-1 - ISO-8859-2: alias ISO8859-2 - KSC_5601: alias KS_C_5601 - UTF-8: aliases UNICODE-1-1-UTF-8 UNICODE-2-0-UTF-8 - - -Q: How can I integrate libiconv into my package? -A: Just copy the entire libiconv package into a subdirectory of your package. - At configuration time, call libiconv's configure script with the - appropriate --srcdir option and maybe --enable-static or --disable-shared. - Then "cd libiconv && make && make install-lib libdir=... includedir=...". - 'install-lib' is a special (not GNU standardized) target which installs - only the include file - in $(includedir) - and the library - in $(libdir) - - and does not use other directory variables. After "installing" libiconv - in your package's build directory, building of your package can proceed. - -Q: Why is the testsuite so big? -A: Because some of the tests are very comprehensive. - If you don't feel like using the testsuite, you can simply remove the - tests/ directory. - |