トップ > FAQ(第１) |
|
|
|
FAQ(第１) |
|
|
Unicode版msearchに関する質問集です。FAQ(Frequently Asked Question, よく質問されること)と銘打ってはいますが、 毛流麦花の学習記録と備忘録を兼ねている関係で、質問されそうにない事項が含まれておりますし、当方の勘違いにより誤った記述をしている箇所がある可能性があります。 なおFAQ(第２)にも目を通してください。 なお、penguin-19さんのFAQ集(msearch掲示板で過去にあった事例)も参考にしてください。 |
|
目次インストール・仕様1.対応しているPerlのバージョンは?2.Jcode.pm、Encode::モジュール、nkf等をインストールする必要はありますか?3.対応しているOS, Webサーバーソフトは?4.Apache+mod_perlの環境下で動作するか?5.genindex.cgiやmsearch.cgiを実行しようとすると、"Error:500 Internal Server Error"が発生します。6.Ver. 1.50以前のmsearch(1.33, 1.46など)から移行する際の注意事項は?7.どんなWebサイトであれば本家版から移行するメリットがあるのですか?移行してもメリットのないWebサイトとは?8.msearchを設置したいのですが、プロバイダ(ホスティング)業者から「過負荷のCGIは禁止します」と警告されており、果たして設置して大丈夫なものかどうか心配です。9.制限事項はありますか?10.他の全文検索CGI(namazu, WwwSearch等)と比較した場合のmsearchのメリット, デメリットは?11.対応しているエンコーディングは?12.対応していないエンコーディングは?13.PDFファイルの検索はできますか?PDFファイル内のUnicode文字を検索できますか?14.想定しているブラウザのバージョンは?(検索結果, 検索オプションの表示ができるブラウザのバージョンは?)15.Unicodeに対応していないブラウザでは, 検索結果, 検索オプションの画面はどう表示されるのか?運用1.検索フォームを設置するには?2.検索フォームをSJIS,JIS,EUCのページに設置できますか?検索フォームの<form>タグのaccept-charsetを"euc-jp"にしてはいけませんか?3.検索フォームをUTF-8以外のUnicode形式ページ(UTF-16LE, 16BE, 32LE, 32BE)に設置できますか?4.検索を実行すると、画面が真っ白になって何も表示されません。5.インデックス(default.idx)をローカルで作成しました。FTPソフトでアップロードするときの転送設定は?6.検索結果表示が文字化けするのですが? ヒットするはずのページがヒットしないのですが?7.サーバーでのインデックス作成が行えなくなりました。(作成途中で止まってしまうなど)8.(本家版から移行された方)インデックスが本家版よりも大きくなりました。9.今までヒットしていたページが急にヒットしなくなりました。もしくはヒットしないはずのページがヒットします。10.検索ログ(msearch.log)をエディタで開くと、文字化けします。11.検索結果からUTF-16LE, 16BE, 32LE, 32BEのページを開くと、文字化けします。12.このサイトには私のブラウザではうまく表示されないページがあるのですが?13.Web pageの文字コードをUTF-8に変更したら、見栄え、字体などが変わってしまったようなのですが?14.Webページそのものは文字化けせず表示されるのに、検索結果のサマリー表示が文字化けするページがあるのですが?文字コード1.msearchのファイルを編集するのにWindows付属のメモ帳、ワードパッドは使えますか?2.私のエディタにはUTF-16LE, UTF-16BEという項目がないのですが?3.UTF以前の話, そもそもBE(Big Endian, ビッグ・エンディアン), LE(Little Endian, リトル・エンディアン)って何?4.BOMとは何ですか?5.私のエディタにはUTF-8,UTF-8Nの2種類のUTF-8があるのですが?(xyzzy等)6.私のエディタにはBOMを指定する項目がありません。このエディタで作成したWebページ(UTF-8)を検索対象にしても大丈夫ですか?7.UTF-8ではBOMを付けなくても大丈夫ですか?8.UTF-7、UTF-EBCDICに対応していますか?9.CESU-8に対応していますか?10.ひとくちにUnicodeといっても、UTF-8, 16LE, 16BE, 32LE, 32BEといろいろあるけれども、どれを使えばいいの?11.U+5404という記法の意味は?12.UCS-2とUTF-16とは何が違うの?13.UCS-4とUTF-32とは何が違うの?14.UnicodeとUTF-8, 16LE, 16BE, 32LE, 32BEとの関係(意味の違い)がよくわかりません。15.なぜ誤検索(ミスマッチ)が発生しないのですか?16.なぜmsearchの各ファイルはdefault.cfgを除いてUTF-8形式でなく、EUC形式なのですか? 検索結果画面をUTF-8で出力するのだから、スクリプトもUTF-8化していいように思うのですが?17.なぜ文字コードの判定時にタグを調べるのですか?18.右から左に表記する言語(アラビア語, ヘブライ語など)に対応していますか?19.ISO-8859-12ってないの?20.Windows-Sami-2って何ですか?21.ARMSCII-8って何ですか?22.ASMO-708って何ですか?23.GEOSTD8って何ですか?24.IA5って何ですか?25.TIS-620って何ですか?26.ISO-IR-111, KOI8-R, KOI8-Uって何ですか?27.TCVN, VISCII, VPSって何ですか?28.扱えるUnicode文字の範囲は?基本多言語面(BMP)以外の文字も扱えますか?29.準拠しているUnicodeの仕様は?30.IBM拡張文字(NEC選定IBM拡張文字, NEC特殊文字)を含むファイル(Shift_JIS形式)は扱えますか?31.MacOS(漢字Talk)で作成したファイル(Shift_JIS形式)は扱えますか?32.JIS第3水準, 第4水準文字(JIS X 0213, JIS2000)は扱えますか?33.半角カタカナは扱えますか?34.ISO-2022-JPはどこまで対応していますか?ISO-2022-JP-2は使えますか?35.EUC-JPはどこまで対応していますか?JIS補助漢字は扱えますか?Ultrix, VMS, OpenVMSのDEC漢字(Super DEC漢字, DEC漢字2000)は扱えますか?36.EUC-JP, Shift_JISのファイルでベンダ固有の機種依存文字を含んだファイルは扱えますか?37.①(U+2460), ②(U+2461)などの記号を扱えますか?38.繁体字中国語(Big5)、簡体字中国語(GB2312)、韓国語(EUC-KR)などの文字コードに対応していますか?39.Unicode制御文字に対応していますか?40.Unicode固有の改行文字を使用できますか?41.EBCDIC系のエンコーディングに対応していますか?42.文字鏡フォントに収録されている文字を扱えますか?43.TRONコードに対応していますか?44.住基ネット統一文字コードに対応していますか?45.NEC漢字(NEC内部コード?), FMR漢字, JIPS(JIPSE), KEIS, JEF, MELCOM, HAYAC, IBM標準漢字などに対応していますか?46.K-JIS, U-PRESSなどに対応していますか?47.ISCII系のエンコーディングに対応していますか?48.MacOS系のエンコーディングに対応していますか?49.ペルシア語(イラン)のエンコーディング(ISIRI-2900, 3342など)に対応していますか?50.Unicode全文字を収録したフォントがないのに、なぜ「全Unicode文字(U+0000からU+10FFFFまで)での検索・検索結果表示に対応」と言えるのですか?51.HTMLページ内に文字参照で記述した文字（例：" " "）は検索できますか?52.独自のDTD(Document Type Definition)を使用しており、その中で独自定義の 文字実体参照を使用しています。これらを文字そのもので検索できますか?53.異体字を同じ文字とみなして検索することはできますか? (例えば、邊(U+908A)を辺(U+8FBA)とみなして検索する等)54.ひらがな・カタカナを同一視して検索することはできますか? (例えば、「ねっと」も「ネット」も同一視して検索する等)55.ファイルをUnicode形式(UTF-8)に変換したら、ファイルサイズが大きくなりました。なぜ?56.Unicode文字が多数収録されているフォントを教えてください。57.Unicodeの文字コード表を入手したいのですが?多言語・国際化1.アルメニア語は扱えますか?2.ウルドゥ語は扱えますか?3.クメール語(カンボジア語)は扱えますか?その他1.マッピングテーブル(utfjpmap.txt)を再配布しても大丈夫なのですか?再配布は制限されていると聞いていますが。2.Unicode対応版msearchを制作(改造)するに至った経緯は?インストール・仕様1.対応しているPerlのバージョンは?本家版msearchが動作するPerl(5.004以降)であれば、動作します。 Unicode対応のPerl(5.008等)でも動作します。 2.Jcode.pm、Encode::モジュール、nkf等をインストールする必要はありますか?不要です。Unicode対応を含め必要な機能はすべて配布スクリプトの中に入っています。 配布スクリプト内にコンパイルを必要とするものはなく、 すべてがスクリプトとして動作しますので、 コンパイル・インストールといった作業そのものが不要です。 強いて言うならば、Perl5のモジュールの機能(拡張子が.pm)を使っていませんので、 モジュールそのものが使えないプロバイダ(ホスティング)業者のサーバーでも動作します。 3.対応しているOS, Webサーバーソフトは?OSについては、本家版と同様にUnix系OS(Solaris, FreeBSD, Linuxなど)のみです。 MacintoshのOS Xについては動作したとの報告をいただいています。 Windows2000 Professional+Apache/1.3、Windows2000 Professional+Apache/2.0の環境でも いちおう動作することを確認しています。 (msearch補助ツールの一部の機能が動作しません。 ただしCGIエラーが発生することはありません。) IISでは動作しません。(改造すれば動作するようですが、推奨できません。) 4.Apache+mod_perlの環境下で動作するか?Apache+mod_perlの環境下ではテストしていないのでわかりません。 というか、もともとmod_perlの環境下で動作させること自体を想定していません。 5.genindex.cgiやmsearch.cgiを実行しようとすると、"Error:500 Internal Server Error"が発生します。以下の項目を再確認してください。
6.Ver. 1.50以前のmsearch(1.33, 1.46など)から移行する際の注意事項は?1.2x、1.3xから移行する場合は、特にありません。 1.51では検索結果画面、ヘルプ画面を設定ファイル(default.cfg)で自由にカスタマイズできることに注意してください。 1.4xから移行する場合は、設定ファイル(default.cfg)の扱いに注意が必要です。 まずファイル名がconfig.datからdefault.cfgに変更されています。 さらにフォーマット変数が追加されており、一部のフォーマット変数は名称が変更されています。 インデックスのファイル名もmindex.datからdefault.idxに変更されています。 msearchのホームページ(本家サイト)や msearch導入記を熟読して、 本家版1.50, 1.51に対応できるように設定ファイルを修正してください。 7.どんなWebサイトであれば本家版から移行するメリットがあるのですか?移行してもメリットのないWebサイトとは?移行するメリットがあると思われるWebサイトは、以下のようなサイトです。
上記サイトであれば、インデックスが本家版よりも大きくなるデメリットを差し引いても、メリットがあるものと思われます。 逆に移行してもメリットのないサイトとは、日本語主体で、JIS第一水準・第二水準の文字で事足りているサイトです。 移行してもインデックスが大きくなってサーバーのディスク領域を圧迫するだけで、メリットはありません。 もちろん新しい物好きであれば、これを否定するものではありません。 8.msearchを設置したいのですが、プロバイダ(ホスティング)業者から「過負荷のCGIは禁止します」と警告されており、果たして設置して大丈夫なものかどうか心配です。検索エンジン本体(msearch.cgi)の負荷は本家版msearchとほぼ同等とみなせますので、Unicodeのページに検索フォームを設置し、検索フォームの<form>タグのaccept-charsetをutf-8と指定することを守れば、問題ないものと思われます。 ただしインデックス作成CGI(genindex.cgi)については本家版msearchよりもかなり負荷をかけるので、プロバイダ(ホスティング)業者のサーバーで実行することはお奨めできません。 インデックスはローカル環境のマシンで作成し、サーバーにアップロードするようにしてください。 9.制限事項はありますか?右から左に表記する言語(アラビア語、ペルシア語、ヘブライ語など)においては、 書記方向の制御文字などには対応していません。 合成文字を使う言語(インド圏の諸言語など)にも完全には対応していません。 これらの言語においては、検索対象ファイル内の文字を出現するそのままの順序でインデックス化し、検索できるだけであるとお考えください。 10.他の全文検索CGI(namazu, WwwSearch等)と比較した場合のmsearchのメリット, デメリットは?namazuと比較した場合のメリットには、root権限がないサーバーにもインストールできる(極言するならば、アクセスカウンタ等の カスタムCGI（自作CGI）を設置できるサーバーなら設置可能)、ディスク容量が少なくて済む(KAKASI, ChaSen(茶筌)等の日本語分かち書きソフトウェアが不要)、 検索結果画面のカスタマイズが自由自在、といったことが挙げられます。 デメリットは, 大規模なサイトに向かないことです。msearchが実用的な速度で動作するのは, 小・中規模のWebサイトです。 WwwSearch等のgrep型全文検索CGI(検索実行時に検索対象ファイルをひとつひとつ検索して調べる方式)と比較した場合の メリットには、検索が圧倒的に高速である、ことが挙げられます。grep型はファイル数が少ないうちは充分高速ですが、 ファイル数が多くなるにつれて検索速度は低下していきます。
全文検索CGIについては、下記サイトが参考になります。 11.対応しているエンコーディングは?対応しているエンコーディングを以下に列挙します。 呼称は日本語版Internet Explorer 6 Service Pack 1(on Windows XP Professional)での表記です。(Microsoftコードページの欄に番号の記載のあるもののみ。） Microsoftコードページの欄に番号の記載がなくブラウザ名の記載があるものは、Windowsが対応していないエンコーディングです。記載しているブラウザでは対応しています。 これらのエンコーディングを文書中にタグで指定するようにすれば、 インデックス作成時に文字コードが正しく自動判定されます。 なおUnicodeエンコーディング(UTF-8など)について、UTFの観点からwell-formedであるかどうか （ill-formedでないかどうか、すなわち不正なバイトシーケンスが出現していないかどうか）の 検証は行いません。
12.対応していないエンコーディングは?対応していないエンコーディングを列挙します。 呼称は日本語版Internet Explorer 6 Service Pack 1(on Windows XP Professional)での表記です。(Microsoftコードページの欄に番号の記載のあるもののみ。） Microsoftコードページの欄に番号の記載がなくブラウザ名の記載があるものは、Windowsが対応していないエンコーディングです。記載しているブラウザでは対応しています。
13.PDFファイルの検索はできますか?PDFファイル内のUnicode文字を検索できますか?PDFファイルを直接検索することはできません。 ただし、pdftotxt、PDF2TXT(PDF2HTML)、Xpdfなどでテキスト形式へ変換したものを検索することは可能です。 indexing.plを改造すれば、これらでテキスト形式へ変換したものでインデックスを作成し、 検索結果表示時にリンクをクリックすると、PDFファイルを開くようにすることも可能です。 なお、PDFの仕様書はAdobeの開発者向けサイト(Adobe Solutions Network)から無償でダウンロードできます。 Adobe Solutions Network - Adobe PDF：http://partners.adobe.com/asn/tech/pdf/specifications.jsp 14.想定しているブラウザのバージョンは?(検索結果, 検索オプションの表示ができるブラウザのバージョンは?)推奨はIEは5以降, Netscapeは6以降です。 いちおうIE4.01SP2, NC4.78でも正しく表示されることを確認していますが, あまりおすすめできません。(リンクはテスト画面のキャプチャ画像です。) 15.Unicodeに対応していないブラウザでは, 検索結果, 検索オプションの画面はどう表示されるのか?IE1, IE3, NN2, NN3でテストしてみたので、ご覧ください。(リンクはテスト画面のキャプチャ画像です。) 運用1.検索フォームを設置するには?検索フォームはUnicode形式(UTF-8など)のページに設置してください。(理由は後述。) 以下に例を示します。 <form action="/cgi-bin/msearch.cgi" accept-charset="utf-8"> 検索<br>>> <input type="text" size="40" name="query" value=""> <input type="submit" value="検索"> <a href="/cgi-bin/msearch.cgi">検索オプション</a> <input type="hidden" name="hint" value="ひらがな"> <input type="hidden" name="index" value=""> <input type="hidden" name="config" value=""> </form> <form>タグのaccept-charsetは必ず"utf-8"にしてください。 msearch.cgiへのパス(朱書き箇所)は実際にmsearchをアップロードしたディレクトリを記述してください。 また文字コード判定用のヒント文字列(青文字の箇所)は必ず「ひらがなが連続で4文字以上」(清音, 濁音, 半濁音, 拗音, 促音, 撥音のみ。長音は不可。)にしてください。 2.検索フォームをSJIS,JIS,EUCのページに設置できますか?検索フォームの<form>タグのaccept-charsetを"euc-jp"にしてはいけませんか?以下の問題が発生することがあるので、お奨めできません。
3.検索フォームをUTF-8以外のUnicode形式ページ(UTF-16LE, 16BE, 32LE, 32BE)に設置できますか?問題なく設置できます。ただし、<form>タグのaccept-charsetは"utf-8"にしてください。 UTF-8以外のUnicodeエンコーディングでクエリーを送信するブラウザはないはずです。 これについては、RFC-2718の"2. Guidelines for new URL schemes"内の"2.2.5 Character encoding"をご参照ください。 要旨を述べると「やむを得ない理由がある場合を除き、URLはUTF-8でエンコードすることを推奨します」となります。 4.検索を実行すると、画面が真っ白になって何も表示されません。メモリ不足などの原因でmsearch.cgiが異常終了しています。 メモリ不足に陥る原因は2つあります。 検索フォームをSJIS, JIS, EUCのページに設置していることによるものか, もしくは検索対象ページの中にファイルサイズの大きなページがあることによるものかのいずれかです。 SJIS, JIS, EUCのページに検索フォームを設置すると、フォームから送られてきた非Unicode文字(SJIS, JIS, EUC)のクエリーをUnicodeへ変換する際に多量のメモリを消費し, これに伴ってメモリ不足で異常終了することがあります。(Perl自身がメモリ不足に陥る、もしくはCGIの1プロセスあたりで許容されているメモリ制限に引っかかる等々。) 検索フォームはUnicode(UTF-8など)のページに設置し、 検索フォームの<form>タグのaccept-charsetは"utf-8"にしてください。 検索対象ページの中にファイルサイズの大きなページがある場合にも異常終了することがあります。 当方でテストしてみたところ、1ページあたり200KB弱までは大丈夫でしたが、 500KBのページがあると画面が真っ白になって検索できませんでした。 (この数値はmsearchを実行するサーバーによって変わってきます。) 5.インデックス(default.idx)をローカルで作成しました。FTPソフトでアップロードするときの転送設定は?インデックスはUTF-8形式になっているので、アスキー（テキスト）モードで転送してください。 6.検索結果表示が文字化けするのですが? ヒットするはずのページがヒットしないのですが?インデックス作成時にページの文字コードを誤判定していることが考えられます。 特にUTF-8, Shift_JIS, EUC-JP間で判定を誤っている可能性が高いです。 これを防止するためには、以下のように当該ページを修正してください。 HTMLの場合: <meta>タグで文字コードを指定する。 <meta http-equiv="Content-Type" content="text/html;charset=Shift_JIS"> <meta http-equiv="Content-Type" content="text/html;charset=ISO-2022-JP"> <meta http-equiv="Content-Type" content="text/html;charset=EUC-JP"> <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">XHTML, XMLの場合：XML宣言で文字コードを指定する。 <?xml version="1.0" encoding="Shift_JIS" ?> <?xml version="1.0" encoding="ISO-2022-JP" ?> <?xml version="1.0" encoding="EUC-JP" ?> <?xml version="1.0" encoding="UTF-8" ?> UTF-16LE, 16BE, 32LE, 32BEのページで問題が起こる場合は、下記項目を確認してください。
BOMがないと文字コードを正しく判定できませんし、 アスキー(テキスト)モードで転送すると、ファイルが壊れます。 詳しくは、仕様の「文字コード判定の詳細」をご覧ください。 7.サーバーでのインデックス作成が行えなくなりました。(作成途中で止まってしまうなど)Unicode版msearchはインデックス作成時に本家版よりも多量にメモリを消費し、CPUに負荷がかかります。 このため作成途中に、過負荷防止のためにサーバー側から強制終了させられていることが考えられます。 インデックス化対象ファイルに非Unicodeファイル(SJIS,JIS,EUC)があると、この傾向は顕著になります。 対策として4通り挙げられます。 (1)ディレクトリ単位でインデックスを作り、msearch用インデックス補助ツールで結合する。(インデックスの小分け作成) (2)逐一モードで作成する。この場合デバッグモードにもチェックを入れることを推奨します。 (3)Webページをひとつ残らず全てUnicode化する。かつインデックス作成時に非インデックス対象キーワードを指定しない。 (4)ローカルでインデックスを作成する。 4通りの方法の中で(1)と(2)は併用できます。すなわち逐一モードで作成したインデックスを補助ツールで結合しても問題ありません。 ちなみに当方としては ローカルでのインデックス作成を推奨します。 この方法だと過負荷で他に迷惑をかける心配がありませんし、一度慣れてしまえば圧倒的に楽です。 作り方はローカルサーバーに書いてありますので、参考にしてください。 8.(本家版から移行された方)インデックスが本家版よりも大きくなりました。不具合ではありません。正常です。 Unicode版msearchではインデックスを文字コードEUC-JPではなく、UTF-8で作成しています。 全角文字(漢字、ひらがな等)はEUC-JPでは2バイトで表現されますが、 UTF-8では3バイトで表現されます。ですので日本語主体のホームページであれば、 インデックスはほとんどの場合、大きくなります。 インデックスをUTF-16で作成すれば全角文字を2バイトで表現できますが、 この場合ASCII文字まで2バイトで表現することになり、さらに UTF-16エンコーディングで使用しているコード領域の関係で 正確な検索動作を行うことが難しくなります。 9.今までヒットしていたページが急にヒットしなくなりました。もしくはヒットしないはずのページがヒットします。問題になっているページについて下記事項を入念にチェックしてください。
1.50以降のmsearchはネストしたコメントにも対応するようになり、これに伴いコメントタグの使い方を誤るとインデックスが正しく作成されなくなっています。(1.51でこの現象は解消しています。) ホームページ作成ソフト、HTMLエディタの文法チェック機能に頼らず、自分の目で1行1行上記項目を確認してください。 10.検索ログ(msearch.log)をエディタで開くと、文字化けします。検索ログはUTF-8形式(BOM有)で作成されています。 ログはサーバーからアスキー(テキスト)モードでダウンロードしてください。 文字化けの原因としては、以下のものがあります。
1.については、検索ログを開く際に文字コードをUTF-8と指定して開くようにしてください。 2.については、Unicode固有文字の表示に対応したエディタでログを開くようにしてください。 エディタの中には、Unicodeファイルの読み込み、書き出しには対応しているものの、 内部処理がShift_JISで行われているために、Unicode固有文字の表示ができないものがあります。 さらにUnicodeファイルを表示させる際には、使用するフォントにも注意してください。 Unicode固有文字の表示に対応しているエディタであっても、当該文字がフォントに含まれていなければ、 正しく表示できません。 11.検索結果からUTF-16LE, 16BE, 32LE, 32BEのページを開くと、文字化けします。msearchとは関係のない問題です。ファイル保存時の問題か、転送時に壊れています。 これらのファイルはBOM(Byte Order Mark)有で保存するようにしてください。 またこれらのエンコーディングのファイルをFTPソフトで転送する時は、必ずバイナリーモードで転送してください。 アスキーモードで転送すると、ファイルが壊れます。 それでも改善が見られない場合は、他のブラウザ(Mozilla, Opera, Netscapeなど)を使ってください。 当方の経験では、IE6でUTF-16BE、UTF-32BEで開こうとすると文字化けすることが多いです。特にUT-32BEがひどいです。 MozillaやOperaを使うとかなり改善されます。 12.このサイトには私のブラウザではうまく表示されないページがあるのですが?Unicode版msearch制作時にブラウザのバグと思われる事象にいくつか遭遇しており、それらに 該当する可能性があります。以下に当方がバグではないか?と認識している事象を列挙します。 いずれも日本語版 WindowsXP Professional上で遭遇した事象です。 IE6 SP1
Mozilla 1.5
Opera 7.22
13.Web pageの文字コードをUTF-8に変更したら、見栄え、字体などが変わってしまったようなのですが?別のフォントで表示されるようになったのが原因です。 スタイルシートでfont-familyを指定すれば、解決します。 default.cfgファイルのHTMLを参考にしてください。 さらにUTF-8のWebサイトを数多く閲覧し、スタイルシート(CSSファイル)を研究されることを推奨します。 14.Webページそのものは文字化けせず表示されるのに、検索結果のサマリー表示が文字化けするページがあるのですが?当該Webページの言語を表示するのに必要なフォント名を default.cfgの検索結果HTMLのスタイルシートのfont-familyに追加してください。 フォント名は、IE6であれば ツール -> インターネットオプション -> 全般 -> フォント で調べることができます。 文字コード1.msearchのファイルを編集するのにWindows付属のメモ帳、ワードパッドは使えますか?使えません。EUC文字コードに対応しておらず、さらに改行コードLFにも対応していないためです。 EUC文字コード、Unicode(UTF-8)に対応したテキストエディタを使用してください。 テキストエディタは市販製品のもの、フリーソフトのもの、数多くあります。 市販製品(有償製品)であれば、EmEditor、MIFES、WZ Editorなど、 シェアウェアであれば、秀丸など、 フリーソフトであれば、MKEditor、xyzzy、サクラエディタなどがあります。(いずれもWindows版) Windows用であればVector(Windows用エディタ)、 Macintosh用であればVector(Macintosh用エディタ)で探してみてください。 (どちらもVectorにリンクしています。) なおこれらのエディタとは別に、Unicodeテキストの編集に特化したUnicodeエディタというものも存在します。 Unicodeエディタを使うと、BMP(基本多言語面)以外の文字も扱える, Unicode制御文字を扱える, Unicode文字をUCNs形式(Universal Character Names, 例: ¥u0034), NCRs形式(Numeric Character References, 例：")に 変換できる, などのメリットがあります。 フリーソフトでSC UniPad, BabelPadなどがあります。URLはリンク集をご覧ください。 2.私のエディタにはUTF-16LE, UTF-16BEという項目がないのですが?Windows用のテキストエディタでは、UnicodeはUTF-16LE、Unicode(big endian)はUTF-16BEと同じ意味です。 LEはlittle endian, BEはbig endianの略です。 3.UTF以前の話, そもそもBE(Big Endian, ビッグ・エンディアン), LE(Little Endian, リトル・エンディアン)って何?コンピュータにおいて, 2バイト以上の長さのデータをメモリ上に並べる順序を意味します。 なぜこんなことをいちいち考えるのかというと、メモリの番地は1バイト毎に 与えられるものだからです。たとえCPUが32ビット, 64ビットであろうとも, これは変わりません。 マルチバイト(2バイト以上の長さ)のデータの最上位バイトをメモリの下位番地に置き、 データの最下位バイトまで順番にメモリの上位番地へと並べていく方式をビッグ・エンディアンと呼びます。 これとは逆に, マルチバイトのデータの最下位バイトをメモリの下位番地に置き, データの最上位バイトまで順番にメモリの上位番地へと並べていく方式をリトル・エンディアンと呼びます。 UTFに即した話をすると、例えばUTF-16BEで0x00, 0x20と表現されるデータはUTF-16LEでは0x20, 0x00と表現されます。 UTF-32BEで0x00, 0x02, 0x4F, 0xC8と表現されるデータはUTF-32LEでは0xC8, 0x4F, 0x02, 0x00と表現されます。 ビッグ・エンディアン, リトル・エンディアンの両者を総称してバイト・オーダーと呼ぶこともあります。 ビッグ・エンディアン, リトル・エンディアンの呼称はジョナサン・スウィフト作『ガリバー旅行記』("Gulliver's Travels"by Jonathan Swift)に由来します。 卵の割り方をめぐって、大きい方の端を割る人々(Big Endians)と小さい方の端を割る人々(Little Endians)が対立しており、 その対立がきっかけでリリパット国(Lilliput)とブレフスキュ国(Blefuscu)が争っているという話です。 詳しくは、以下のサイトで第一部の第四章をお読みください。 Jonathan Swift - Gulliver's Travels：http://www.jaffebros.com/lee/gulliver/ 4.BOMとは何ですか?Byte Order Markの略で、Unicodeファイルのエンコーディング(UTF-8, UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE) を識別するために使われるマーカー（識別子）です。 Windows環境では、UTF-8、UTF-16LE, 16BE, 32LE, 32BEのいずれもBOM有が標準です。 なおソフトウェアによっては、BOMを別の名称で呼ぶことがあります。 Unicodeサイン(EmEditorでの呼称)、UTF-8 シグニチャ(Visual Studio .NETでの呼称)、 いずれもBOMのことです。 5.私のエディタにはUTF-8,UTF-8Nの2種類のUTF-8があるのですが?(xyzzy等)この場合、UTF-8NはBOM無のUTF-8,UTF-8はBOM有のUTF-8を意味します。 UTF-8Nの項目がない場合のUTF-8にBOMが付くかどうかはエディタによってまちまちです。 メモ帳はBOM有、MKEditorはBOM無、それ以外のエディタはどうなんだろう? エディタによってはUTF-8Nの項目がなく、ファイルを保存する時の画面で BOMを付けるかどうかを指定できるようになっているものもあります。(秀丸、EmEditorなど) 6.私のエディタにはBOMを指定する項目がありません。このエディタで作成したWebページ(UTF-8)を検索対象にしても大丈夫ですか?UTF-8のWebページ(検索対象になるページ)にはBOMが有っても無くても、問題ありません。 7.UTF-8ではBOMを付けなくても大丈夫ですか?Webページ(検索対象になるページ)にはBOMが有っても無くても、問題ありません。 msearchの設定ファイル(default.cfg)についても、BOMが有っても無くても、問題ありません。 ただし、UTF-16LE, 16BE, 32LE, 32BEでは必ずBOMを付けてください。 (BOMがないと文字コードを自動で正しく判定できません。) 8.UTF-7、UTF-EBCDICに対応していますか?対応していませんし、対応させる予定もありません。 他のエンコーディング形式(UTF-8,UTF-16LE等)に変換してください。 ちなみにUTF-7はRFC-2152で規定されています。 UTF-EBCDICについては、Unicode Technical Reports #16(UTR 16)をご参照ください。(UnicodeコンソーシアムのWebサイトで閲覧できます。) 9.CESU-8に対応していますか?対応していませんし、対応させる予定もありません。 ちなみにCESU-8とは、8-bit Compatibility Encoding Scheme for UTF-16のことで、 Unicode Technical Reports #26(UTR 26)で規定されています。(Unicodeの正式な仕様の一部ではありません。) UTF-16のデータを(バイトオーダーを考慮する必要のない)8bit単位で処理するためのエンコーディングで、 BMP領域の文字はUTF-8と同じようにエンコーディングされます。 補助プレーンの文字については(Unicodeコードポイントではなく)UTF-16のサロゲートペアー(surrogate pair)を 6バイトにエンコーディングする点がUTF-8との違いです。 もともとCESU-8はソフトウェア内部で用いるためのエンコーディングであってWebページなどで使うためのものではないので、 対応する必要性は低いものと考えています。 10.ひとくちにUnicodeといっても、UTF-8, 16LE, 16BE, 32LE, 32BEといろいろあるけれども、どれを使えばいいの?Webページ(HTML)であれば、UTF-8, UTF-16LE が無難でしょう。主流はUTF-8です。UTF-16BEを使わなくとも、UTF-16LEでかまわないでしょう。 UTF-32LE, 32BEは日本語主体の環境で使ってもファイルサイズが大きくなるだけなので、あえて使うだけのメリットを見出せません。 なおどのエンコーディングでも全Unicode文字(U+0000からU+10FFFFまで)を表現できることに注意してください。 ただし、UCS-4全文字(0x00000000から0x7FFFFFFFまで)を表現できるのは、UTF-8, 32LE, 32BEのみです。 UTF-16LE, 16BEでは、UCS-4全文字を表現することはできません。 11.U+5404という記法の意味は?Unicode文字の文字番号を意味します。(正式にはUnicodeコードポイントと呼びます。) 数値は16進数表記で、0x5404等と記述せずにU+5404と記述するのは、Unicodeコードポイントであることを 明示するためです。 12.UCS-2とUTF-16とは何が違うの?まず規定している規格そのものが違います。UCS-2はISOがISO-10646仕様書で規定している文字コード体系です。 (UCSはUniversal Multiple-Octet Coded Character Setの略です。) UTF-16はUnicodeコンソーシアムが規定している文字コード体系です。 (UTFはUnicode(or UCS) Transformation Formatの略です。) 2つは規格としては別物ですが連携が行われており、重複するコード領域では 同じ番号に同じ文字が割り当てられています。 もうひとつの違い、それは表現できる文字数です。UCS-2では、0x0000から0xFFFFまでの 63488文字しか表現できませんが(65536でなく63488である理由は後述)、 UTF-16では、U+0000からU+10FFFFまでの全Unicode文字が 表現できます。16ビット(2バイト)なのに、なぜそんなに多くの文字を表現できるのかというと サロゲートペア(surrogate pair)という仕組みを使って、U+FFFFを超える領域の文字を 4バイトで表現しているためです。 なお、サロゲートのためにU+0000からU+FFFFまでのコードポイントのうち、 2048ポイント(U+D800からU+DFFFまで)は特別な領域として文字が割り当てられていません。 そのため、U+0000からU+10FFFFまでの全文字数は114112文字ではなく、 114112-2048=1112064文字になります。 UCS-2が63488文字しか表現できないのも、同じ理由によります。(65536-2048=63488) UTF-16についてはRFC-2781もご参照ください。 13.UCS-4とUTF-32とは何が違うの?まず規定している規格そのものが違います。UCS-4はISOがISO-10646仕様書で規定している文字コード体系です。 UTF-32はUnicodeコンソーシアムが規定している文字コード体系です。 2つは規格としては別物ですが連携が行われており、重複するコード領域では 同じ番号に同じ文字が割り当てられています。 もうひとつの違い、それは使っているコード範囲です。 UCS-4では0x00000000から0x7FFFFFFFまでの範囲を規定していますが、 UTF-32ではそのごく一部のU+00000000からU+0010FFFFまでしか規定していません。 UTF-32はUCS-4のサブセットと言えます。 UCS-4では0x0010FFFFを超える領域(UTF-32を超える領域)にも文字が割り当てられています。 なお、U+0000からU+FFFFまでのコード領域を基本多言語面(BMP: Basic Multilingual Plane)と呼びます。 14.UnicodeとUTF-8, 16LE, 16BE, 32LE, 32BEとの関係(意味の違い)がよくわかりません。Unicodeは一般には文字コード体系を指し、 UTF-8, 16LE, 16BE, 32LE, 32BEはUnicode文字のエンコーディングを指します。 まず文字コード体系とエンコーディングの意味の違いを知る必要があります。 文字コード体系では各文字に与える文字番号を規定し、 エンコーディングでは、文字番号をコンピューター上でどのように表現するのか(符号化するのか)を規定します。 勘違いしてならないのは、コンピューター上では必ずしも文字番号そのままの数値を扱うのではないということです。 コンピュータ上で扱うのは、文字番号ではなく、エンコーディングされた文字番号です。 例えばUnicodeでU+3042の文字番号(=Unicodeコードポイント)を与えられた文字 "あ" は、 UTF-8では0xE38182、UTF-16LEでは0x4230、UTF-16BEでは0x3042、UTF-32LEでは0x42300000、UTF-32BEでは0x00003042とエンコーディングされます。 この考え方は日本語文字コードでも同じです。 例えばJIS X 0208で0402の区点番号を与えられた文字 "あ" は、Shift_JISでは0x82A0、EUC-JPでは0xA4A2、ISO-2022-JPでは0x2422と エンコーディングされます。 15.なぜ誤検索(ミスマッチ)が発生しないのですか?それはUTF-8エンコーディングで使用しているコード領域に秘密があります。 以下の表はUCS-4全領域の文字をUTF-8でエンコーディングした時のバイトシーケンスを示します。 0x0000から0x0010FFFFまでのUCS-4値は、Unicodeコードポイントと同じです。 各数値は16進数表記です。 （以下の表は説明用に簡略化してあり、実際のUTF-8ではill-formed（不正）として扱われるバイトシーケンスも含まれています。 厳密な意味での（well-formedな）UTF-8で使われるバイトシーケンスはもう少し複雑です。詳しくはUnicode 4.0仕様書の "3.9 Unicode Encoding Forms"をご参照ください。）
各文字の1バイト目で使用しているコード領域はバイト数の異なる他の文字の1バイト目と重なっておらず、 さらに各文字の2バイト目以降とも重なっていません。これはすなわち、検索動作(パターンマッチ動作)を 行う際に文字境界をまたがってマッチする恐れがないことを意味します。 この特徴はUTF-8ならではのもので、UTF-16, UTF-32にはありません。 現行のUnicode 4.0ではU+0000からU+0010FFFFまでのコードポイントしか使っておらず、上表の 1バイト文字から4バイト文字までしか使いませんが、UTF-8自体はUCS-4全領域をエンコーディングできるようになっていますので、 いつの日かU+0010FFFFを超えるコードポイントが規定された日には、それらの領域の文字もmsearchで検索できるようになります。 (ただし、utfjp.plのバージョンアップが必要になります。) なおコード領域が重なっていないことには、他にも以下のメリットがあります。
もっと詳しく知りたい場合は、RFC-2279もしくはRFC-3629 "UTF-8, a transformation format of ISO 10646"をご参照ください。 (RFC-2279はドラフト版、RFC-3629は正式版です。) 16.なぜmsearchの各ファイルはdefault.cfgを除いてUTF-8形式でなく、EUC形式なのですか? 検索結果画面をUTF-8で出力するのだから、スクリプトもUTF-8化していいように思うのですが?これはUTF-8のBOM問題を回避するためです。 UTF-8のBOMは本来なくてもいいものなのですが、どうしたことか BOM有のUTF-8とBOM無のUTF-8が混在してしまっています。 ファイル出力時にBOMを付けるエディタもあれば、付けないエディタもあります。 BOMの有無を選択できればいいのですが、選択できないエディタも存在します。 BOM無のUTF-8であればスクリプトとして実行しても問題ないのですが、 BOM有のUTF-8だと実行時に間違いなくエラー("Error: 500 Internal Server Error")が発生します。 各ファイルをUTF-8化して、注意書きに「必ずBOM無UTF-8出力に対応したエディタを使用してください」と 記載することも考えましたが、ユーザーにUnicodeの知識を要求することは それだけUnicode版msearch導入の敷居を高くすることになり好ましくないと判断し、 default.cfgを除いて、すべてEUC形式を踏襲することにした次第です。 なおdefault.cfgについてはUTF-8形式ですが、BOMについて気にする必要はありません。 BOMは有っても無くても問題ありません。ただし、BOM有りを推奨します。 BOMが有ると、エディタがUTF-8形式であると自動で正しく判定できるからです。 その他のmsearchのファイルを編集するときは、 プログラム内に全角文字を記述できないファイル(msearch.cgiなど)があることに注意してください。 17.なぜ文字コードの判定時にタグを調べるのですか?理由は２つあります。 １番目の理由は, 文字コードを判定する際、UTF-8とShift_JIS, EUC-JP間の見極めが難しいことによります。 これらの文字コードは使用しているコード領域が重なっており、 毛流麦花の力量では簡単・確実な判定方法が思いつきません。 どなたか、タグを調べることなくファイルのバイト並びだけで これらの文字コードを確実に判別できる手法をご存知の方、 ご教示方お願いします。 ２番目の理由は, ISO-8859, CodePageなどの各種エンコーディングに対応するためです。 18.右から左に表記する言語(アラビア語, ヘブライ語など)に対応していますか?対応していますが、制限があります。 これらの言語では、対象ファイル内での書記方向の字句のみが検索可能です。(Webブラウザ上の書記方向とは必ずしも一致しません。) またU+200E(LEFT-TO-RIGHT MARK, Windows-1255では0xFD)とU+200F(RIGHT-TO-LEFT MARK, Windows-1255では0xFE)をはじめとした書記方向や文字合成のための制御文字には対応していません。 対応しているエンコーディングはUnicode(アラビア語もしくはヘブライ語を含む), ASMO-708(アラビア語), ISO-8859-6(アラビア語), ISO-8859-8(ヘブライ語), Windows-1255(ヘブライ語), Windows-1256(アラビア語), DOS-720(アラビア語), DOS-862(ヘブライ語)で、 これらのエンコーディングの文章は、対象ファイル中に出現するそのままの順序でインデックス化されます。 ISO-8859で対応しているエンコーディングは、ISO-8859-6(Arabic)とISO-8859-8(Hebrew Visual)のみです。 書記方向を文章途中で切り替えるエンコーディング(Hebrew Logical, ISO-8859-6-I, ISO-8859-6-E, ISO-8859-8-I, ISO-8859-8-E)には 対応していません。詳しくは、RFC-1345, RFC-1556をご参照ください。 19.ISO-8859-12ってないの?手元の資料では"reserved for ISCII Indian"となっています。事実上は欠番なのでしょうか? 20.Windows-Sami-2って何ですか?北欧言語版のWin9X(95/98/98SE/Me)で使われているエンコーディングです。省略してwinsami2と表記することもあります。 ノルウェーの会社が開発したOperaは対応しています。 北欧に対して強い思い入れのある毛流麦花といたましては、Windows-Sami-2への対応を外すわけにはまいりません。(笑) 北欧言語向けのエンコーディングとしてはこれ以外に ISO-8859-10 (Latin6) があります。 参考：http://www.geocrawler.com/archives/3/113/2002/9/0/9681414/ 変換表：http://www.hum.uit.no/a/trond/ws2t.html 文字コード表：http://www.hum.uit.no/a/trond/ws2code.gif 解説(ノルウェー語)：http://www.hum.uit.no/a/trond/smi-kodetabell.html 21.ARMSCII-8って何ですか?アルメニア語で使われているエンコーディングです。詳しくは下記サイトをご参照ください。 なお,"Armenian Eternity Sign"と"Armenian Section Sign"には対応していません。 アルメニア語ではこれ以外にARMSCII-7, ARMSCII-8A, ARMSCII-16のエンコーディングがありますが、これらには対応していません。 文字コード表：http://pre98.elections.am/Software/ 解説：http://www.freenet.am/armscii/ http://www.armeniadiaspora.com/conference2002/preconf/vahram_m/ArmSCII.html 22.ASMO-708って何ですか?アラビア語圏で使われているエンコーディングです。ISO-8859-6と同等です。RFC-1345をご参照ください。 23.GEOSTD8って何ですか?グルジア語で使われているエンコーディングです。IETF(The Internet Engineering Task Force)のドラフト文書("draft-giasher-geostd8-01.txt")で規定されています。 24.IA5って何ですか?IA5とは、International Alphabet No.5の略で、情報交換用の符号体系の一種で、ITU-T勧告T.50にて規定されています。 ("International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) - Information technology - 7-bit coded character set for information interchange") ISO-646でも規定されているらしいですが、当方では確認していません。(ECMA-6 にも記述があります。) x-IA5、x-IA5-German、x-IA5-Norwegian、x-IA5-Swedishのいずれのエンコーディングにも対応しています。 IA5では、0x00から0x7Fまでの文字を規定しています。 各々(x-IA5、x-IA5-German、x-IA5-Norwegian、x-IA5-Swedish)が 0x23, 0x24, 0x40, 0x5B, 0x5C, 0x5D, 0x5E, 0x60, 0x7B, 0x7C, 0x7D, 0x7Eに独自の文字を割り当てています。 x-IA5はIRV(International Reference Version)と呼ぶこともあります。 前述コード領域の文字を規定していない素のIA5もあります。 普段からおなじみのASCIIは、IA5の米国バージョンのことです。 テストページの一覧にIA5のテストページを設置してありますので、興味のある方は お試しください。 なお日本語版WindowsXPでは、IA5のコードページ変換テーブルがデフォルトでは有効にならないので、 コントロールパネル -> 地域と言語のオプション -> 詳細設定 -> コードページ変換テーブル にてチェックマークを入れる必要があります。 Windows2000であれば、 コントロールパネル -> 地域のオプション -> 全般 -> システムの言語設定 -> 詳細 にてチェックマークを入れます。 25.TIS-620って何ですか?タイ語で使われているエンコーディングです。0xA0(NO-BREAK SPACE)がないことを除けば、ISO-8859-11と同等です。 26.ISO-IR-111, KOI8-R, KOI8-Uって何ですか?ロシア・ウクライナなどのキリル言語圏で使われているエンコーディングです。 ISO-IR-111はRFC-1345, KOI8-RはRFC-1489, KOI8-UはRFC-2319で規定されています。 詳しくは下記サイトをご参照ください。 KOI8-R - Russian Net Character Set：http://koi8.pp.ru/ 27.TCVN, VISCII, VPSって何ですか?ベトナム語圏で使われているエンコーディングです。 TCVNはTCVN 5712:1993のことで, VSCII-1とも呼ばれます。(VSCIIはVietnam Standard Code for Information Interchangeの略。) この他にもVSCII-2, VSCII-3があります。 VISCIIは上述VSCIIとは別物で、RFC-1456で規定されています。 VPSはVietnamese Professionals Societyが規定したエンコーディングで、VNCIIとも呼ばれます。 Vietnamese Unicode FAQs：http://vietunicode.sourceforge.net/ Mozilla Vietnamese Enabling Project：http://www.vnet.org/vanlangsj/mozilla/ Vietnamese Professionals Society：http://www.vps.org/ Standards：http://homepages.cwi.nl/~dik/english/codes/stand.html 28.扱えるUnicode文字の範囲は?基本多言語面(BMP)以外の文字も扱えますか?全Unicode文字(U+0000からU+10FFFFまで)での検索・検索結果表示に対応しています。 すなわち、BMP以外の文字にも対応しています。 ただし実際に文字を表示できるかどうかは、フォントにその文字が収録されているかに依存します。 （すべてのUnicode文字がフォントに収録されているとは限りません。） 29.準拠しているUnicodeの仕様は?Unicode 4.0です。UTF-16のサロゲートペア(surrogate pair)、UTF-8, 16LE, 16BE, 32LE, 32BE等のエンコーディングに対応しています。 30.IBM拡張文字(NEC選定IBM拡張文字, NEC特殊文字)を含むファイル(Shift_JIS形式)は扱えますか?Unicode形式に変換すれば、そのままの字体で問題なく扱えます。 IBM拡張文字(NEC選定IBM拡張文字, NEC特殊文字)はすべてUnicodeに収録されています。 31.MacOS(漢字Talk)で作成したファイル(Shift_JIS形式)は扱えますか?漢字Talk1, 漢字Talk2, 漢字Talk6, 漢字Talk7, MacOS 8.0については, システム外字を含まないファイルであれば問題なく扱えるはずです。 (漢字Talk6, 漢字Talk7, MacOS 8.0のシステム外字は, NEC PC-9800シリーズ互換の外字(NEC特殊文字)とApple独自の外字が混在しているらしいです。) MacOS 8.x系(8.1以降), 9.x系については、システム外字を含んだファイルであってもUnicode形式に変換すれば扱えるはずです。 MacOS(8.1以降)のシステム外字はUnicodeに収録されています。(もしかしたら、Unicodeに収録されていない外字があるかもしれません。これについて当方では確認していません。) MacOS X以降については, システム外字がWindows互換になったので, システム外字を含んだファイルであってもUnicode形式に変換すれば問題なく扱えるはずです。 32.JIS第3水準, 第4水準文字(JIS X 0213, JIS2000)は扱えますか?JIS第3水準, 第4水準文字のうち、Unicode(U+0000からU+10FFFFまで)に収録されている文字はUnicode文字として扱えます。 ただしUnicode外の文字(ISO10646のUCS-4では規定されているもののUnicode領域を超えている文字)は扱えません。 33.半角カタカナは扱えますか?Unicode形式のページに半角カタカナを含めることそのものは問題ありません。 ただ半角カタカナはインデックス作成時、検索時共にすべて全角カタカナとして扱われますし、 一般にWebでは半角カタカナがあるだけで嫌がられる傾向があるので、使用はお奨めいたしません。 34.ISO-2022-JPはどこまで対応していますか?ISO-2022-JP-2は使えますか?ISO-2022-JPについては、半角カタカナを用いたページ、SO/SIを用いたページのいずれにも対応しています。 ISO-2022-JP-1には対応していますが、ISO-2022-JP-2には対応していません。 ちなみにISO-2022-JPとは、JIS X 0201(ASCII), JIS X 0208(JIS漢字)を使うエンコーディングで、 ISO-2022-JP-1はISO-2022-JPにJIS X 0212(JIS補助漢字)を追加したもの、 ISO-2022-JP-2はISO-2022-JP-1にGB2312-80(中国), KS X 1001(韓国), ISO-8859-1の一部, ISO-8859-7の一部を追加したものです。 なぜISO-2022-JP-2に対応していないのかというと、ISO-2022-JPのページはいったんEUC-JPに変換したうえで Unicode(UTF-8)に変換するからです。(JIS補助漢字はEUC-JPに変換できるが、それ以外の中国, 韓国, ISO-8859の文字はEUC-JPに変換できない。) もっともISO-2022-JP-2のページであっても、中国, 韓国, ISO-8859の文字を使っていないページであれば、 ISO-2022-JP-1と同等ですので問題なくインデックス化, 検索できます。 それとISO-2022-JP-1(ISO-2022-JP-2)のページは、正しく表示できないブラウザがあることに注意してください。 当方で試してみたところ、IE6は未対応らしいです。Mozillaでは表示できました。 35.EUC-JPはどこまで対応していますか?JIS補助漢字は扱えますか?Ultrix, VMS, OpenVMSのDEC漢字(Super DEC漢字, DEC漢字2000)は扱えますか?EUC-JPについては、JIS補助漢字(JIS X 0212)を含んだページにも対応しています。 ただしJIS補助漢字を含むEUC-JPのページは、正しく表示できないブラウザがあることに注意してください。 当方で試してみたところ、IE6は未対応らしいです。Mozillaでは表示できました。 DEC漢字の半角カタカナ, DEC漢字, Super DEC漢字, DEC漢字2000のユーザ定義領域以外はEUC-JPと互換性があるとのことなので、 問題なく扱えるはずです。ただし当方にOpenVMSの環境がないため、確認はしていません。 ちなみにDEC漢字(Super DEC漢字, DEC漢字2000)は日本語版のUltrix, OpenVMS等で使われている漢字コード体系です。 UltrixとはDEC版のUNIXです。 OpenVMSはDEC製の メインフレームVAXシリーズ/Alphaシリーズ/Itaniumシリーズなどで使われています。 DEC漢字2000はAlphaシリーズ以外では使えないようです。 OpenVMS：http://www.hp.com/jp/openvms/ 36.EUC-JP, Shift_JISのファイルでベンダ固有の機種依存文字を含んだファイルは扱えますか?ベンダ固有の機種依存文字を含んだファイルはあらかじめUnicode形式に変換した上でご利用ください。 msearchで使用しているEUC-JP(Shift_JIS)からUnicodeへの変換表(マッピングテーブル)は ベンダ固有の機種依存文字を考慮していません。 37.①(U+2460), ②(U+2461)などの記号を扱えますか?記号についてはUnicodeに収録されているものについてはUnicode文字として扱うことで 問題なく扱えます。ただし、Unicodeに収録されていないものもあることに注意してください。 38.繁体字中国語(Big5)、簡体字中国語(GB2312)、韓国語(EUC-KR)などの文字コードに対応していますか?対応していませんし、対応させる予定もありません。 日本語文字コード(SJIS,JIS,EUC)で扱えない文字を含むファイルは すべてUnicode形式に変換してください。 なぜ対応させないのかというと、これらの文字コードからUnicodeへの変換には巨大なマッピングテーブル(Perlのハッシュ)が必要になり、 メモリを大量に要することになるからです。日本語文字コードからUnicodeへの変換でもメモリを大量に消費しているのに、 さらにメモリを要するようなものを付加してしまうと、トラブルを引き起こすだけで実際には使えない機能に陥りかねません。 これらの考えに基づき、中国語, 韓国語などのDBCS(Double Byte Character Set)系の文字コードへの対応は見送っています。 これらの言語でmsearchを使いたい場合は、すべてUnicodeに変換してくださいというのが毛流麦花の見解です。 39.Unicode制御文字に対応していますか?U+2028(LINE SEPARATOR), U+2029(PARAGRAPH SEPARATOR)には対応していますが、それ以外の制御文字には対応していません。 本msearchは単にUnicodeでインデックスを作成して検索できるだけのものであり、制御文字を解釈する機能は備えていません。 40.Unicode固有の改行文字を使用できますか?使用できます。対応しているのはU+2028(LINE SEPARATOR), U+2029(PARAGRAPH SEPARATOR)の2つです。 41.EBCDIC系のエンコーディングに対応していますか?対応していませんし、対応させる予定もありません。 理由は、必要性が低いと考えているためです。 ちなみにEBCDIC("えびしでぃっく"と読みます。)とはExtended Binary Coded Decimal Interchange Code の略で、 主にメインフレーム(汎用機)やオフコンで使われている, IBM社が策定した8bit系の文字コード体系です。 これにカタカナを追加したものを特に区別してEBCDIK(Extended Binary Coded Decimal Interchange Kana Code)と表記することがあります。 いずれもASCIIとの互換性はまったくありません。 本題ですが、そもそもIEのEBCDIC対応は、WebサーバーがAS/400(現在はiSeries)などの汎用機で、 クライアントにEBCDICのままでページを送信してくることを想定してのものと考えています。 しかもこれはインターネットというよりもイントラネット向けの機能でしょう!? さらに前提条件として、WebサーバーがContent-typeを出力するときに EBCDICのエンコーディングを出力する必要があります。 (例："Content-type: text/html;charset=ibm037") このContent-typeの出力は、EBCDICではなくASCIIで行います。 もっとも汎用機WebサーバーであってもASCII系エンコーディングへの変換機能は持っているらしいので、 絶対にEBCDICで出力しなければならないわけではないらしいです。 話がそれましたが、必要性が低いと考えているのは、 果たして汎用機Webサーバーでmsearchを走らせることがあるのだろうかと疑問に感じているからです。 msearchは制限事項の多いプロバイダ(ホスティング)業者のPCベースのWebサーバーで走らせるためのものであり、 汎用機Webサーバーであれば、当然全文検索程度の機能は 最初から装備されているでしょうから、msearchの出番がありません。 もっともAS/400用Perlはあるらしいので、試してみる価値はあるかもしれません。 もしも試された方がおられましたら、ぜひともご一報ください。とても興味があります。 もうひとつの理由として、EBCDICに対応したフリーのテキストエディタを見つけられなかったからということがあります。 なぜないのでしょう?あったら欲しいです。(シェアウエアにVEDITがありますが、フリーソフトがあればなお嬉しいのです。) テストページの一覧にEBCDICのページも設置してありますので、興味のある方は お試しください。ただしIE+Windows2000/XP以降限定で、かつEBCDIC系のコードページ変換テーブルが 有効になっている必要があります。(これ以外のパソコン環境では思いっきり文字化けします。) EBCDICのページを開く前に、コードページ変換テーブルを有効にしてください。 EBCDIC系だけでなく、IA5系, T.61など全部のコードページ変換テーブルを有効にすることを推奨します。 WindowsXPであれば、 コントロールパネル -> 地域と言語のオプション -> 詳細設定 -> コードページ変換テーブル にてチェックマークを入れる必要があります。 Windows2000であれば、 コントロールパネル -> 地域のオプション -> 全般 -> システムの言語設定 -> 詳細 にてチェックマークを入れます。 テキストファイル変換WIN ：http://www.vector.co.jp/soft/other/as400/se239954.html EBCDICとShift_JIS間で相互に文字コードの相互変換をするツールです！これは役立ちます。 上記ソフトの作者様のWeb：http://hobby400.hp.infoseek.co.jp/ ASCIIからEBCDICへの変換：http://poison.jp/~isome/EbConv.html AS/400：http://www.as400-net.com/ iSeries Information Center：http://as400bks.rochester.ibm.com/iseries/v5r2/ic2924/info/nls/rbagsnlsreferenceinformation.htm ASCIIとEBCDICの対比表：http://www.egrannie.com/cheatsheets/asciiebcdic.html ASCII and EBCDIC：http://www.dynamoo.com/technical/ebcdic.htm C VM-ESA Programming Guide IBM：http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CBCVPG00/7.2.3.1 VEDIT EBCDICにも対応したテキストエディタ：http://www.vedit.com/ 42.文字鏡フォントに収録されている文字を扱えますか?Unicodeに収録されている文字(UnicodeテキストもしくはUnicodeタグとして貼り付けられる文字)であれば 扱えるはずです。（当方では確認していません。） 文字鏡には諸橋轍次著『大漢和辞典』（大修館書店刊）に収録された見出し漢字約5万字が収録されており、 対応フォントやツールを使うことで、入力や表示ができます。 43.TRONコードに対応していますか?TRONコードそのものには対応していません。あくまでもUnicodeへの対応のみです。 TRONコードとは、超漢字などのTRON仕様OSで使われている文字コードです。 TRONコードでは最大で150万字弱の文字を扱うことができます。(現在の実装は17万字弱) フォント・トレーサビリティ・システム(TRON Font Tracability System)を使うことで、TRONコードにしか収録されていない文字も 他のOSで容易に外字として扱うことができます。 ucodeを用いることで外字表(外字変換表・外字フォントセット)も一括管理できるシステムであるとのことです。 ちなみにucodeとは、ユビキタスIDセンターによって管理される、モノに付与されるID番号のことらしいです。
TRON文字収録センター：http://www2.tron.org/ 44.住基ネット統一文字コードに対応していますか?対応していません。というか、対応させる必要性そのものが皆無であるはずです。 住基ネット統一文字コードとは、住民基本台帳ネットワークで使われている文字コードのことです。 住民基本台帳ネットワークシステム：http://www.soumu.go.jp/c-gyousei/daityo/ 45.NEC漢字(NEC内部コード?), FMR漢字, JIPS(JIPSE), KEIS, JEF, MELCOM, HAYAC, IBM標準漢字などに対応していますか?EBCDIC(EBCDIK)はともかく、オフコン、メインフレーム(汎用機)系の エンコーディングには対応していませんし、対応させる予定もありません。 そもそも対応させる必要性は皆無のはずです。 ちなみに NEC漢字はNEC製の一部のパソコン, ワープロ文豪シリーズの一部の機種, FMR漢字は富士通製のFMRなどのパソコン, ワープロOASYSシリーズの一部の機種, JIPS(JIPSE)はNEC製のACOSなどのメインフレーム, KEIS(KEIS78, KEIS83, KEISはKanji processing Extended Information Systemの略)は日立製のメインフレームなど, JEF(JEF9, JEF12, JEFはJapanese processing Extended Featureの略)は富士通製のFACOMなどのメインフレーム, オフコンなど, MELCOMは三菱電機製のMELCOMなどのメインフレーム、ミニコンなど, HAYACはシャープ製のオフコンHAYACシリーズで 使われている(使われていた)漢字コード体系のことらしいです。 46.K-JIS, U-PRESSなどに対応していますか?記事配信用、DTP系のエンコーディングには対応していませんし、対応させる予定もありません。 対応させる必要性は皆無のはずです。 ちなみに K-JISは共同通信社が加盟社や新聞社への記事配信用に開発した文字コード体系です。 U-PRESSは共同通信社がK-JISの後継として開発して文字コード体系で, UCSをベースとしています。 UCSベースなのはいいのですが、詳細な仕様が不明（Private Use Areaを使っている?）で、とても気になります。
共同通信社 U-PRESS：http://www-6.ibm.com/jp/software/tivoli/casestudies/kyodo.html 47.ISCII系のエンコーディングに対応していますか?ISCII系のエンコーディングはIE6が対応していることもありぜひとも対応したいのですが、 現時点では対応させる予定はありません。 これは合成文字があって作業がやっかいになるためです。 適当なマッピングテーブルを見つけられなかったからということもあります。 話はそれますが、インド圏では多くの言語が使われていて各々別個のエンコーディングが使われており、 興味がつきません。アッサム語、ベンガル語、グジャラート語、カンナダ語、マラヤーラム語、オリヤー語、パンジャブ語、 タミール語、テルグ語などなどいろいろです。 ちなみにISCIIとはインド圏で使われているエンコーディングのことで、 Indian Script Code for Information Interchangeの略です。 IS 13194:1991で規定されています。(ISはIndian Standardの略。ISCII-91と呼ばれることもある。) この仕様書はCDAC(Centre for Development of Advanced Computing)のサイトからダウンロードできます。 Department of Information Technology：http://tdil.mit.gov.in/ CDAC：http://www.cdacindia.com/ 48.MacOS系のエンコーディングに対応していますか?現時点では対応させる予定はありません。 それほど必要性を感じないためです。 FreeBSDベースのMacOS Xには興味があります。 基本的にISO-8859系, Windowsコードページ系, 各国の国家標準のエンコーディングに対応していれば事足りると考えますが、 如何でしょうか? 49.ペルシア語(イラン)のエンコーディング(ISIRI-2900, 3342など)に対応していますか?対応していませんし、対応させる予定もありません。 ペルシア語(イラン)でmsearchを使いたい場合は、Unicodeに変換してください。 なぜ対応させないのかというと、主要なブラウザ(IE, Mozilla, Opera)がこれらのエンコーディングに対応していないためです。 もっともペルシア語専用のブラウザであれば対応しているのかもしれませんが。(Alis Technologies社のTango Browser(Tango Creator)という製品が対応している(していた)らしいです。真否のほどは未確認。) The FarsiWeb Project：http://www.farsiweb.info/ 50.Unicode全文字を収録したフォントがないのに、なぜ「全Unicode文字(U+0000からU+10FFFFまで)での検索・検索結果表示に対応」と言えるのですか?以下の手順でテストを行い、全Unicode文字での検索・検索結果表示への対応を謳っています。
51.HTMLページ内に文字参照で記述した文字（例：" " "）は検索できますか?数値文字参照(Numeric Character References(NCRs), 例：" ")、 文字実体参照(Character entity references, 例：")はインデックス作成時に 文字そのものに置換され、検索時には参照している文字そのもので検索できます。 ただしUCNs(Universal Character Names, 例：¥u0022)は置換対象外です。 置換対象になるのは、HTML, XHTML, XMLファイル(文字コードは問いません)内に含まれる 上記文字参照です。ただし、< >は置換されません。 これは、本家版との互換性確保(兼 CrossSiteScripting対策)のためです。 なお16進数表記の場合, &#Xnn; &#xnn;のいずれの形式であっても置換されます。 52.独自のDTD(Document Type Definition)を使用しており、その中で独自定義の 文字実体参照を使用しています。これらを文字そのもので検索できますか?可能です。utfjpent.txtに文字実体参照名とUnicodeコードポイント(文字番号)を記述してください。 ただし、XMLの一般実体(実体名で任意の長さの文字列を参照する記法)には対応していません。 53.異体字を同じ文字とみなして検索することはできますか? (例えば、邊(U+908A)を辺(U+8FBA)とみなして検索する等)準備中です。 54.ひらがな・カタカナを同一視して検索することはできますか? (例えば、「ねっと」も「ネット」も同一視して検索する等)準備中です。 55.ファイルをUnicode形式(UTF-8)に変換したら、ファイルサイズが大きくなりました。なぜ?日本語文字コード(SJIS, JIS, EUC)では漢字・ひらがなは2バイトで表現されますが、UTF-8では3バイトで 表現されます。これが原因で日本語主体のHPの場合、UTF-8に変換するとサイズが大きくなります。 別のUnicode形式(UTF-16LE, UTF-16BE)で保存すると、UTF-8よりもサイズが小さくなることもあります。 56.Unicode文字が多数収録されているフォントを教えてください。Windowsであれば、Arial Unicode MSフォント(Office 2000以降)があります。(ファイルサイズが22MB弱もある。) Arial Unicode MSフォントの解説：http://support.microsoft.com/support/kb/articles/q287/2/47.asp OfficeXPにはもっと多くの文字を含んだフォントがあるらしいです。 http://www.microsoft.com/japan/office/ork/three/inte03.asp以下のサイトでも調べてみてください。 http://www.alanwood.net/unicode/57.Unicodeの文字コード表を入手したいのですが?UnicodeコンソーシアムのホームページからPDF形式で入手できます。 多言語・国際化1.アルメニア語は扱えますか?アルメニア語については、ARMSCII-8エンコーディングに対応しているのでその点は問題ないのですが、 実際の運用上は問題点があります。 まずアルメニア語のWebサイトでは、タグで文字コードをx-user-definedと指定し、アルメニア語専用のフォントをインストール して表示させているのがほとんどのように思われます。もしもタグで文字コードをARMSCII-8と指定すればインデックス作成時に 文字コードを自動で判定できるようになりますが、こうしてしまうとIEで正しく表示されなくなり、 Mozilla等でしか表示できなくなってしまいます。 ではどうするかとなりますが、迷わずにUnicode(UTF-8)に変換してください。こうすれば、正しく表示されるようになります。 ただし問題点があります。Unicodeに収録されていないアルメニア語固有文字があるのです。 "Armenian Eternity Sign"と"Armenian Section Sign"です。 これについては、フォントの埋め込み(Font Embedding)で対処するしかないように思われます。 ただしこうしてしまうと、IEでしか意図した通りに表示できなくなる点に注意してください。(IE以外では代替フォントで表示することになります。)
解説：
Microsoft Typography: 上記サイトからWEFT(Web Embedding Fonts Tool)をダウンロードできます。このツールを使って埋め込み用フォントを作成すれば対処できるはずです。 (ただしアルメニア語専用フォントを準備し、かつそのフォントが埋め込み(Embedding)を許可している必要があります。) OfficeXPにはアルメニア語用のフォントがあるらしいです。 http://www.microsoft.com/japan/office/ork/three/inte03.asp2.ウルドゥ語は扱えますか?ウルドゥ語は右から左へ表記する言語なので、その点について気にしなければ扱えます。 なおWebページにおいて、ウルドゥ語のセクションはスタイルシートを用いて"font-family: Tahoma"を指定する必要があります。 こうしないと一部の文字が正しく表示されません。(もしかしたら他のfont-familyでも大丈夫かもしれませんが、これについては調査していません。) 3.クメール語(カンボジア語)は扱えますか?クメール語(カンボジア語)のWebサイトでは、クメール語(カンボジア語)専用フォントを用いて表示させている例がほとんどらしいです。 こういったページは当然ですが、msearchでは扱えません。 これについては、フォントの埋め込みで対処するしかないように思われます。 クメール語(カンボジア語)の文字そのものはUnicodeに収録されているのですが、Windowsで標準的なフォントに グリフが収録されていないため、こうなってしまいます。 埋め込み方法はアルメニア語の項をご参照ください。 なお、UTF-8でクメール語を表示させているサイトを発見したので、以下に記します。
KHMERCIVL.COM: http://www.khmercivil.com/ その他1.マッピングテーブル(utfjpmap.txt)を再配布しても大丈夫なのですか?再配布は制限されていると聞いていますが。問題ありません。Unicode, Inc.のCopyright Policyが改訂されており、再配布が行えるようになっています。 念のため、法的な問題がないことをUnicode, Inc.に問い合わせ、確認してあります。 Unicode, Inc.に感謝です。 2.Unicode対応版msearchを制作(改造)するに至った経緯は?検索エンジン内部を調べていて、「エンジン本体そのままで内部エンコードをUTF-8に変更しても動作するのではないか?」と 考えたのがきっかけです。そもそも検索エンジン内部に首をつっこんだのは、「北欧」で検索すると文字化けが発生するという事象に遭遇したためです。 関連する本家掲示板へのリンクを記します。
北欧で文字化け(問題)
北欧で文字化け(解決)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
