回避とは？

法律回避（ほうりつかいひ）とは、本来適用されるべき国又は地域の法律の適用を回避し、自己に有利な国又は地域の適用を企図する行為をいい、同様の行為に関するフランスの用語に従い法律詐欺 (fraude a la loi) ということもある。
私法上の法律回避は、国際私法における準拠法指定の前提となる連結点を故意に変更することにより行われる。例としては、契約締結の方式に関する法律の適用を回避するために他国で契約する形態などがあるが、歴史上多く見られたのは、婚姻や離婚を容易に行うための法律回避行為である。
婚姻における法律回避は、多くの場合、婚姻の成立要件が当事者にとって厳しい場合に、婚姻挙行地を成立要件が緩やかな地域に意図的に変更することにより行われる。
歴史的に著名な例としては、19世紀前半に多く見られたグレトナ・グリーン婚 (Gretna Green marriage) が挙げられる。かつてイングランドでは、婚姻成立要件として父母の同意やイギリス国教会の牧師の前における儀式などが必要とされていた時期があった。これに対し、隣地のスコットランドでは、当事者の合意のみで成立するとされていた。このため、イングランドに居住するカップルが結婚について父母の同意を得られない場合や儀式の費用を捻出することができない場合に、イングランドからスコットランドに入ってすぐの場所にあるグレトナ・グリーン村の鍛冶屋で結婚式を挙げた上で、スコットランド法による婚姻証明書を取得する方法が行われた。当時のイングランドの国際私法では、婚姻の実質的成立要件と方式の準拠法は一括して婚姻挙行地法とされており（現在では、実質的成立要件については婚姻当事者の婚姻前の住所地法）、このような法律回避による婚姻もイングランドでは有効とされた。
もっとも、その後、宗教婚とは別に民事婚が可能になったこと、婚姻の挙行には一定期間の居住を要する立法がされたこと、スコットランドにおける法改正などにより、典型的なグレトナ・グリーン婚は行われなくなる。
離婚における法律回避の多くは、離婚が禁止されていたり著しく制限されている国の法律の適用を回避するために、帰化をしたり住所を変更することにより行われる。
歴史的に著名な例であり、かつ、法律回避の問題が初めてクローズアップされた例として、フランス破毀院のボッフルモン公爵夫人事件 (L'affaire de la princesse de Bauffremont) 判決（1878年）がある。これは、フランス人であるボッフルモン公爵と結婚したベルギー人女性（婚姻によりフランス国籍を取得）が、当時のフランス法では離婚が禁止されており離婚に代わる別居の制度しか認められていなかったため、フランスの裁判所で別居の判決を得た後、ドイツに帰化し、同国で別居を離婚へ転換させる判決を得て、ルーマニア人である別の男性と再婚した事件である。ボッフルモン公爵は離婚等の無効を訴え、フランス破毀院は離婚及び再婚を法律回避によるものであるとして無効と判断した。
日本においては、法律回避を無効とする見解もないわけではないが、一般的には有効であると解されている。もっとも、法律回避行為の結果が内国の公序に反する場合は、当事者が適用を意図した法律の適用を排除される可能性はある（法の適用に関する通則法42条（旧法例33条））。
タックス・ヘイヴン (tax haven) とは、租税が全く課されないか、税率が著しく低い国又は地域のことをいう。タックス・ヘイヴンとされる国はいわゆる小国が多く、特にリヒテンシュタインは自然人の数より法人の数の方が多いと言われている。
タックス・ヘイヴンの利用による課税回避の方法としては、内国の会社がタックス・ヘイヴンに子会社を作り、取引はその子会社を通して行い、取引による利益を子会社に留保し内国の親会社に利益を配当しない扱いをすることにより、内国による法人税の課税を回避する方法が採られる。
このような問題の回避のため各国で税法上の対処を行っている（タックスヘイヴン対策税制）。日本においては、日本の居住者や日本法人による株式の所有や出資金額が合わせて50パーセントを超える外国法人のうち、本店又は主たる事務所の所在する国又は地域における所得に対して課される税の負担が著しく低い法人につき一定の要件を満たしたものについて、その留保した利益のうち、問題となる外国法人に5パーセント以上の出資をしている日本の居住者や日本法人の出資割合に対応する部分を、内国居住者や日本法人の所得に算入する扱いをしている（租税特別措置法40条の4?40条の6、66条の6から66条の9）。
国際法上、船舶は一つの船籍を持ち、船籍を有する国家に登録されるところ、船舶と船籍との間には「真正な関係」が存在しなければならないとされている。また、国家は自国の船舶につき、安全や技術、船舶内の労働などに関して有効に管轄権を行使し規制を行わなければならない（以上の点につき、公海に関する条約5条、海洋法に関する国際連合条約91条、94条）。
ところが、船舶と船籍との関係や船舶に対する上記の行政上の規制を緩やかにすることにより、自国に船舶の登録を誘致している国家が存在する。そのような国家に船籍を設定する船舶を便宜置籍船といい、税法などの行政上の規制を回避するために、便宜船籍が利用されることがある。特に、パナマの場合、便宜置籍船の船籍国であると同時に上記のタックス・ヘイヴンでもあるため、パナマ法に基づく法人を設立し、当該法人を船舶の所有者にする方法により、課税の回避が行われることが多い。
会社を設立する際、実際に主たる営業をする国又は地域で会社を設立することをせず、別の国又は地域で会社を設立する場合がある（上記のタックス・ヘイヴンの利用もその一形態）。
著名な例としては、アメリカ合衆国において、実際にはデラウェア州以外の州で主たる営業をすることを目的とする会社であるにもかかわらず、デラウェア州の会社法に基づき設立する例が挙げられ、ニューヨーク証券取引所に上場している株式会社の約45パーセントがデラウェア州法に基づく会社である。このような現象が起きる理由として、デラウェア州は他の州と比較して会社の設立が容易であること、法人税など州に支払う費用などが安価であること、会社法の法文や判例が緻密であり会社を巡る法律関係に関する予測が建てやすいことなどがあると言われている。
日本の平成17年改正前商法の下においては、日本に本店を設け又は日本で営業をすることを主たる目的とする会社が日本以外の国の法律に基づき設立された場合（擬似外国会社）であっても、日本法に基づき設立される会社と同一の規定に従うことを要するとされていた（商法旧会社編第482条、有限会社法第76条））。この規定の解釈として、設立から清算結了まで日本の会社と同一の規制に服すべきとする趣旨（日本国内では会社の法人格が認められない結果、権利能力なき社団として扱われる）か、設立に関する規定を除いて日本の会社と同一の規制に服すべきとする趣旨（日本国内でも会社として認められるが、日本法により規律される）かにつき見解が分かれるところ、判例は前者の見解を採用している。なお、2006年5月に施行された会社法（平成17年法律第86号）の下においては、擬似外国会社は「日本において取引を継続してすることができない」とされているが（会社法第821条第1項）、これに違反し取引をした場合、取引をした者は擬似外国会社と連帯して相手方に対して債務を弁済する責任を負う（会社法第821条第2項）が、法人格自体は否定されない扱いとなる。

[ 39] 法律回避 - Wikipedia
[引用サイト]　 http://ja.wikipedia.org/wiki/%E6%B3%95%E5%BE%8B%E5%9B%9E%E9%81%BF

注：指定したページ "Wikipedia‐ノート:曖昧さ回避" は存在しません。正しいページを指定してください。
この文書はウィキペディア日本語版の公式な方針です。多くの利用者に支持されており、すべての利用者が従うべきだと考えられています。必要に応じて編集することは可能ですが、その変更はコミュニティーの合意を反映している必要があります。大きな変更を加える場合は、先にノートページで提案してください。
ウィキペディアにおいて、内容が異なるトピック（主題）なのに適切な記事名が同じになってしまうときに、それらを判別しやすくすることを曖昧さ回避と呼びます。このページでは「曖昧さ回避」に関する説明をします。
ウィキペディアでは、リンクを簡単に作ることができるのが特徴の一つです。編集ウィンドウで、（[[スピード]]のように）リンクしたい名称を半角の大括弧（角括弧、ブラケット）で囲むと、（スピードのように）リンクが貼られます。でも、このリンク先は速度について説明しているのでしょうか？ それともトランプゲームの一種の「スピード」なのか、音楽グループの「SPEED」なのか、アメリカ映画の『スピード』なのかはっきりしません。リンク先に期待していたものと全く異なることが書かれていれば、読者はがっかりするかもしれません。
曖昧さ回避は、「フリーウェア」（無料ソフト）と「フリーソフトウェア」（変更、再配布等が自由なソフト）のように、類似した名前で異なる内容のページが作られている項目と混同してはいけません。あくまでも“同じ名前で”異なる内容のものに対して行うものです。
6.6 索引以外の普通のページから曖昧さ回避ページへリンクする場合には、曖昧さ回避のページにリンクしていることを明示する
曖昧さ回避は、異なる内容なのに、同じ記事名になるトピックに関して、読者が調べたいものを探す案内板のようなものです。 ですから、読者が迷う恐れがない場合には、曖昧さ回避にするべきではありません。曖昧さ回避がどれだけ必要かどうかは、読者がその言葉でその項目を探す可能性が大きいかどうか、また読者が探しているページへの誘導が簡単かどうかを総合的に判断してください。 曖昧さ回避を導入する前にWikipedia:記事名の付け方も参照してください。別の項目名がより適切ならば、そちらを使うべきです。
存在しない項目を載せるかどうかは慎重に行うべきです。その項目名で呼ばれるものをすべてを載せる必要はありませんし、執筆される見込みが薄い項目や、現存するものでも削除されそうな項目にリンクする必要はありません。例えば、歌の題名はたくさんありますが、個々の歌がすべて執筆されているわけではないので、まだ記事の書かれていない歌の題名を載せる必要はありません。そのような項目は既存の項目（バンド名、アルバムなど）へ加筆してください。
近い将来執筆される可能性がある主題については曖昧さ回避のページに記述しておいて構いません。しかし、作られるとすぐにWikipedia:削除依頼に提示されるようなものについては、記述すべきではありません。また、辞書を作成するウィクショナリーなどの姉妹プロジェクトにしか記事がない項目へは載せる必要はありません。 英字2文字や3文字程度の略語で呼ばれる事柄については、項目名をあらかじめ日本語化しておくか、正式名称にしておくべきでしょう。そして、略語のページは正式な記事名へのリダイレクトページにするか、他の意味の略語にもなっているなら、曖昧さ回避のページとしましょう。
曖昧さ回避などの理由で括弧を利用する場合には、「項目名 (分野)」のように、項目名の後に「半角のスペース」ひとつ入れて、半角の括弧の中に分野名を記述してください。[[項目名 (分野)|]]と入力すると自動的に[[項目名 (分野)|項目名]]へと変換されます。
1つのページに見出しを使って分けておく方法です。政体、ホンダ・ビートが例としてあげられます。この方法はそれぞれのトピックの文章量がそれほど多くない場合に向いています。
この方法で作成されたページは、曖昧さ回避ページの一種ですが、曖昧さ回避表示である{{Aimai}}は置きません。将来、それぞれの節が大きくなれば、独立した記事にします。
「項目名 (分野)」のように、それぞれの言葉に分野名を付記した項目名で独立した記事にします。分野名を付記しない項目名のページは、独立させた「項目名 (分野)」の記事へのリンクの一覧を載せる曖昧さ回避ページにします。よく参照される項目とそれ以外との項目とであまり差があると考えられない場合に向いています。 曖昧さ回避ページした記事には{{Aimai}}の記述をして曖昧さ回避ページであることを表示してください。他の項目からのリンクする場合はこの曖昧さ回避ページにはリンクせずに、独立させた「項目名 (分野)」へ直接リンクさせてください。
その「項目名」で最も参照されるトピックにその名前を割り当て、それ以外のものを「項目名 (分野)」にします。これはさらに、曖昧さ回避ページを別に作らないものと、曖昧さ回避ページを別に作るものに分かれます。
代表的なトピック（主題）を「項目名」に書き、それ以外のトピックを「項目名 (分野)」として、ページの先頭部分にリストアップするものです。代表的なものに山手線があったことから山手線方式と呼ばれます。このようなぺージには{{Aimai}}を付けないでください。
代表的なトピックへのリンクはそのままにしておきます。それ以外の項目へのリンクは、適切なページに直接行くように、作り替えてください。書式としては、線で区切ったり（狭い意味での山手線方式）、先頭部に四角で囲った中に記述したり等と様々な形があります。線で区切る方法は本文ときれいに分かれてすっきりしますが、読者に曖昧さ回避の言葉の定義と本文冒頭の定義を2回読ませることになってしまいます。代表的なトピックの定義を先に書く方法は、この点でよりスマートですが、画像や表がある場合にはレイアウト上読みにくくなりがちです。その状況に応じて、読者にとって読みやすい方法を選ぶようにしてください。
この項目では代表的なトピックの説明について記述しています。別ページの説明については別ページをご覧ください。
{{Otheruseslist|代表的なトピックの説明|別ページ1の説明|別ページ1|別ページ2の説明|別ページ2}}
別ページ1の説明については別ページ1をご覧ください。*別ページ2の説明については別ページ2をご覧ください。
代表的なトピックを「項目名」に書き、そのページの先頭に「項目名 (曖昧さ回避)」へのリンクを作ります。「項目名 (曖昧さ回避)」に他の意味のリンクを付け加えるものです。例えば、果物・植物のモモはモモに執筆し、それ以外の「モモ」と呼ばれる項目（小説の『モモ』、料理の「モモ」等）はリンク先であるモモ (曖昧さ回避)に載せます。そして、「項目名 (曖昧さ回避)」のページには、{{Aimai}}の記述をして曖昧さ回避ページであることを表示してください。元の「項目名」のページには{{Aimai}}を付けないでください。
代表的なトピックへのリンクはそのままにしておきます。それ以外の項目へのリンクは、適切なページに直接行くように、作り替えてください。
曖昧さ回避は、全ての場合について良いものというのは存在しません。曖昧さ回避すべき事柄同士の関係によって最適な方法が変わるでしょう。状況に応じて柔軟に対応してください。
あまり文章量がない場合や、別々の項目にすべきか同一の項目にすべきか迷っている場合には、「1ページに共存する方法」を選択するべきでしょう。ウィキペディアで採用しているライセンスであるGFDLとウィキペディアのシステムとの兼ね合いで、後から統合するよりは、後から分割する方が履歴の保存が簡単だからです。しかし、次元の2005年2月17日 (木) 16:28 の版のように読みにくくなることもあります。
地名などで複数のトピック間で優先順位をつけにくい場合や、どれを代表的なトピックにすべきか参加者間で対立がある場合には、「平等な曖昧さ回避」を使用するべきでしょう。この方法は「リンク元」機能を使って、曖昧さ回避のページへのリンクを除去しやすいという利点があります。しかし、王の2004年6月5日 (土) 06:55 の版のように、細切れで項目が作られやすく、項目間相互の関連性が見えにくくなって読者の理解を妨げる可能性もあります。
代表的なトピックとそうでないトピックとが明確な場合には、「代表的なトピックを中心とする曖昧さ回避」を選択すべきでしょう。この方法は、最もリンクが集中するページへのリンクに特に修正をする必要がないため、読者が探していたものと異なるページへのリンクを少なくする利点があります。また、平等な曖昧さ回避と比較して、説明の細分化が起こりにくい傾向があります。同じ名前をもつトピックの数が少ないときには、曖昧さ回避ページを作らずに別トピックへのリンクはページの先頭に記載し、トピックが3〜4個以上になったときに曖昧さ回避ページを独立させるべきでしょう。
どの方法を使用するにしても、曖昧さ回避のページは読者に調べたい項目を選択させるものであるということを忘れないようにしてください。他の項目を提示するリストや「項目名 (曖昧さ回避)」へのリンクはページの先頭または第1段落の直後につけるべきです。
曖昧さ回避に載せていた名前と同等に使用される別名や正式名称がある場合には、それを使う方が望ましいでしょう。例えば、プログラミング言語のCならばC言語を、お金という意味の「金」ならば貨幣を項目名にしましょう。
他に適切な別名がない場合には、「項目名 (分野)」のように、項目名の後に半角括弧で分野や分類を表す語を付け加えます。例えば、プログラミング言語の一つである「ひまわり」ならば、ひまわり (プログラミング言語)のようにします。
例外的に、修飾語を伴った項目名を使用できます。項目名に修飾語を使う場合には、括弧を使わないようにしてください。修飾語を伴うものと分野名を用いたものとの両方が使える場合には、どちらを使っても構いません。片方を執筆し、もう片方をリダイレクトにすることが普通です。また、複雑な名前よりも単純な名前の方が望ましいでしょう。例えば「憲法の改正についての議論」よりも「憲法改正論議」のほうが、ふさわしいでしょう。
曖昧さ回避のための括弧内に「コンテクスト」（文章的記述）を使用するような特別な状況とは、架空の登場人物のように、その「コンテクスト」が創作物である場合です。しかし、架空の登場人物についてのわずかな記事の項目を多数作ることは、ウィキペディアでは認められていません（Wikipedia:素晴らしい記事を書くには#フィクションを明確に区別）。もしも、曖昧さ回避をする際に、一般的な用語にするか、コンテクストを付け加えたものにするか迷ったときには、単純な方を選択してください。例えば、「神話上の人物」よりは「神話」を選んでください。
括弧内の語句についても、記事名に準じた基準で決めるべきです。詳細は、Wikipedia:記事名の付け方やWikipedia‐ノート:記事名の付け方を参照してください。
曖昧さ回避ページであることを読者に知らせるために、次のような注意書きを曖昧さ回避ページの下部に記述します。これは{{Aimai}}で入れることができます。
このページは曖昧さ回避のためのページです。一つの言葉や名前が二つ以上の意味や物に用いられている場合の水先案内のために、異なる用法を一覧にしてあります。お探しの用語に一番近い記事を選んで下さい。このページへリンクしているページを見つけたら、リンクを適切な項目に張り替えて下さい。
山手線（やまのてせん）とは、東日本旅客鉄道の鉄道路線、または同線を含む線路を環状に運転する列車のことを指す。
山手線（やまのてせん）とは、東日本旅客鉄道の鉄道路線、または同線を含む線路を環状に運転する列車のことを指す。 ……（説明が続く）……
山手線（やまのてせん）とは、東日本旅客鉄道の鉄道路線、または同線を含む線路を環状に運転する列車のことを指す。
ここでは東京の山手線について説明しています。それ以外の山手線については[[山手線 (曖昧さ回避)]]を参照してください。
山手線（やまのてせん）とは、東日本旅客鉄道の鉄道路線、または同線を含む線路を環状に運転する列車のことを指す。 ……（説明が続く）……
ウィキペディアは辞書ではありませんし、「連想ゲーム」を意図したものではありません。曖昧さ回避ページは読みたいページを判別することが目的ですから、単なる定義のリストにしたり、語源や発音を書いたりして辞書のようにしてはいけません。曖昧さ回避のためのページは必要なときのみ作成してください。
独立した記事が書かれていないトピックの定義を詳しく書く必要はありません。なお、リンク先に詳しい説明がある場合には、リンク先のトピックと同一の説明でなくても構いません。 また、誤記を項目名としたリダイレクトページから、曖昧さ回避のページへ転送しないようにしてください。
ただし、「県」や「市」など省略されて呼ばれることが多いものは、曖昧さ回避をしてもかまいません（この例では、「神奈川県」、「神奈川区」、「神奈川町」など）。また、略して呼ばれることの多いものや、姓あるいは名だけで呼ばれることが非常に多い人物などは、曖昧さ回避ページに載せても構いません（例えば、ガリレオ・ガリレイをガリレオの曖昧さ回避に、アイスクリーム、アイスコーヒーをアイスの曖昧さ回避に）。
曖昧さ回避ページへリンクする必要はほとんどありません。記事が存在するトピックなら、直接そこにリンクし、存在しない記事なら、最小限の説明がある曖昧さ回避のページにわざわざリンクせずに、そのページにその内容を記述しましょう。 ただ、曖昧さ回避ページにある複数の言葉がリダイレクト先になる言葉であれば、その曖昧さ回避ページをリダイレクト先にしてください。
曖昧さ回避ページを作る前に「リンク元」をクリックして、リンクしている全てのページを確認してください。そして、リンク元を修正すべきか、しなくても問題ないかを確認してください。しばしば、曖昧さ回避のページの作成やページ名の変更をしたのに、リンク元の修正を忘れがちです。これは、読者にとって不都合となり、修正前よりも悪い状態になります。
作業途中で反対が出たり、編集合戦になったりしてしまわないように、リンクの修正が大規模になりそうなときには、事前にノートなどで提案し、他の利用者の同意を得ましょう。
[編集] 索引以外の普通のページから曖昧さ回避ページへリンクする場合には、曖昧さ回避のページにリンクしていることを明示する
パイプ（|）などで本来のページ名を変えるために（例：金（入力：[[金 (曖昧さ回避)|金]]））と記述しないで、金 (曖昧さ回避)（入力：[[金 (曖昧さ回避)]]）のように、直接、曖昧さ回避ページの項目名を指定してください。平等な曖昧さ回避を採用している「項目名」へリダイレクトする場合には「項目名 (曖昧さ回避)」という内部リンクを作り、そこから「項目名」へとリダイレクトします。
言語間リンクを純粋な曖昧さ回避ページにリンクしないようにしてください。例外は、同様の曖昧さ回避のページが他の言語版にもあるときのみです。この場合は、単一の用法にリンクせずに曖昧さ回避ページへリンクしてください。
記事名が「項目名 (分野A)」という形式の場合、「項目名」、「項目名 (分野B)」、「項目名 (曖昧さ回避)」などへの案内を含むOtheruses テンプレートは原則貼る必要がありません。これらの記事への内部リンクを記事内に記載する場合は関連項目の節におくなど記事本文中への記載を検討してください。
Category:曖昧さ回避 - {{Aimai}}が貼られた完全なリストです。しかし、7,000件を超えるとサーバの負荷が大きくなります。

[ 40] Wikipedia:曖昧さ回避 - Wikipedia
[引用サイト]　 http://ja.wikipedia.org/wiki/Wikipedia:%E6%9B%96%E6%98%A7%E3%81%95%E5%9B%9E%E9%81%BF

前回「第27回 トランザクションの一貫性を保証するロック」は、トランザクションの4つの分離レベルの説明をしました。今回は、この分離レベルを実現するデータベースサーバのロック機構に触れてみましょう。実際にどのような仕組みでデータベースサーバがロック制御を行っているかを理解することで、トランザクション機能を利用した際に起こりやすい問題点を、あらかじめ予測できるようになると思います。
今回は、初めに、ロックの状態を取得するシステムストアドプロシージャ「sp_lock」の定義を若干拡張した「sp_lock_detail」ストアドプロシージャを作成しましょう。
ロックの状態を調べるために、SQL Server Enterprise Managerを利用する方法をこれまでの連載で紹介してきました。ただし、ロックの状態を確認するには、毎回「現在の利用状況」で「最新の状態に更新」を実施する必要があり、手間が掛かります。
これを回避するための便宜策として、sp_lockというシステムストアドプロシージャを利用する方法がありますが、データベース名とテーブル名がIDで表示されるため、判別がしにくいという欠点があります。
この判別のしにくさを回避するため、sp_lockシステムストアドプロシージャを拡張してみましょう。クエリアナライザより次のSQL文を実行して、sp_lock_detailストアドプロシージャを作成してみましょう。
うまくsp_lock_detailストアドプロシージャが作成できたかを確認するため、クエリアナライザからsp_lock_detailを実行してみましょう。
例題1で作成したストアドプロシージャの定義は、SQL Serverにおけるsp_lockの定義をほぼそのまま利用しています。このストアドプロシージャは、Server
Process IDをパラメータに取る場合と取らない場合で大きく2つのブロックに分かれています。前半の10行目から34行目はパラメータを取る場合、40行目から62行目はパラメータを取らない場合です。それぞれのブロックの中は、masterデータベースのsyslockinfoというロックを管理しているシステムテーブルの情報を基に、いくつかのキーワードをspt_valuesというシステムテーブルを基にルックアップしています。非常に単純なストアドプロシージャです。
利用上1点だけ注意しなくてはならないのが、上記の例題2の実行結果はロックオブジェクトが2行返されたはずですが、実際にロックが掛かっているのは1行目のみです。試しに、次の例題3を実行するとsyslockinfoテーブルには1行しか入っていないことが分かります。
これは、masterデータベースのFK_Orders_Employeesに対してSQLの実行中に自動的にロックが掛かるためです。この行のみは無視するようにしてください。
では、本題に入りましょう。まず、SELECT文において、ロックのタイプを強制的に変更するオプションを使用して、どの範囲にロックが掛かるかを確認していきましょう。では次の例題4を実行してみましょう。
画面5 SELECTのデフォルトの状態のロック（画面をクリックすると拡大表示します）
クエリアナライザの結果ウィンドウには2つの結果セットが順に表示されています。スクロールバーで下の方をたどるとsp_lock_detailの結果を参照することが可能です。ここで確認していただきたいのは、sp_lock_detailの結果の1行目です（2行目は無視しましょう）。Northwindデータベースに対して、Modeが「S」と表示されています。これは、共有ロックを意味します。ロックのモードの記号の意味は、下記のとおりです。
共有ロックを意味します。ほかのトランザクションは、共有ロックが掛かっているオブジェクトの読み込みはできますが、更新はできません
排他ロックを意味します。ほかのトランザクションは、読み取りも更新もできません
更新ロックを意味します。更新ロックを掛けた後、実際に更新を行うまでは共有ロックになり、更新を行った後は排他ロックに変換されます。後で説明するデッドロックの防止に役立ちます
インテント共有は、このロックが掛かっているオブジェクトよりも下位の階層の一部で、共有ロックが掛かっていることを示します。例えば、テーブルに対するインテントロックが掛かっている場合は、ページや行などの単位でロックが掛かっていることを示します。ほかのトランザクションがテーブルロックなどを掛けようとしたときに、１つ１つのオブジェクトがロック状態かどうかを確認する必要がなくなるため、パフォーマンスが向上します
インテント共有と同様、下位の階層の一部に対して排他ロックが掛かっていることを示します
インテント共有のオプションで、下位の階層の一部に対して更新を掛ける予定があることを示します
また、Type列には「DB」と表示されており、共有ロックがデータベースに対して掛けられていることが分かります。Type列に表示されるほかのタイプは、下記のとおりです。
インデックス内のキーの範囲。直列化可能トランザクションで行ロックを行う場合に使用
FROM句で指定するテーブルに「WITH句」を利用しロックオプションを指定します。今回は、WITH (HOLDLOCK)というオプションを指定して、Customersテーブルに対してHOLDLOCKを掛ける指定をしました。HOLDLOCKは、前回解説したSERIALIZABLEトランザクション分離レベルと同様な効果を発揮します。
SERIALIZABLEトランザクション分離レベルは一番分離レベルが高いトランザクションタイプで、ほかの同じオブジェクトを利用するトランザクションが並行して実行されるのを防止します。このため、HOLDLOCKにおけるロックがSELECT文に対して指定されると、トランザクションが完了するまで指定されたオブジェクトのロックが持続します。
上記の例題4においては、Customersテーブルのインテント共有ロック、6つのキーにおけるレンジ共有ロックが掛けられていることが分かります。HOLDLOCKのほかに指定可能なトランザクション分離レベルと共通のロックオプションは、以下のとおりです。
ステートメントにだけ適用される、ロックを無視するオプションです。指定したテーブルには、共有ロックを掛けず、ほかのトランザクションが排他ロックを掛けている場合も関係なく読み込みを実行します。
よって、コミットされていないトランザクションを読み込んだり、読み取りの途中でページがロールバックされたりする可能性があります。つまり、ダーティリードが可能なモードです
ロックをすぐに解除するのではなく、トランザクションの完了時まで保持するロックオプションです。HOLDLOCKとSERIALIZABLEは同じです
次に、ロックを掛ける範囲を指定してみましょう。次の例題では、テーブルに対してHOLDLOCKを指定してみます。
画面7 SELECTのテーブルレベルHOLDLOCKオプションのロック（画面をクリックすると拡大表示します）
先ほどの例題5においては、Customersテーブルに対してはインテント共有ロックのみが掛けられていましたが、今度は、Customersテーブルに対して共有ロックが掛けられていることが分かります。Customersテーブルに対しては、ほかのトランザクションから排他ロックが掛けられなるので、更新できない状態となります。
例題6においては、WITH(TABLOCK, HOLDLOCK)というWITH句をCustomersテーブルに対して付与しました。TABLOCKというオプションが、テーブルに対するロックを指定することを意味します。ロックの範囲を指定するオプションと、ロックのタイプを指定するオプションは、上記のWITH句のように複数指定することが可能です。
ロックされた行をスキップします。SELECT ステートメントにだけ適用可能です
テーブルの読み出しの間、共有ロックの代わりに更新ロックを使用します。更新ロックは、データを読んだ後、トランザクションが終了するまでの間、ほかのユーザーがデータを参照することは可能ですが、更新することはできません。通常の更新系のトランザクションの場合は排他ロックが掛けられるため、ほかのトランザクションからは読み取ることもできなくなります（NOLOCKの場合以外）。参照ロックと排他ロックを上手に使い分けることで、同時実行性能を上げることが可能なオプションです
例題5や例題6のWITH（．．．）の部分を上記のオプションに変更すれば、いろいろなロックオプションの動作を検証することが可能です。ぜひ試してみてください。
さて、先ほど「Customersテーブルに共有ロックがされていると、ほかのトランザクションは排他ロックが掛けられない」という話をしましたが、ほかのロックの場合はどのようになるのでしょうか。次のマトリクスがすべてのパターンです。横列がすでに掛けられているモード、縦列がこれから掛けようとするモードです。
テーブルや行に対してインテント共有が設定されている場合は、排他ロックを取得することはできませんが、ほかのロックの取得は可能です。同様に、共有ロックが設定されている場合は、インテントを含む排他系のロックの取得ができません。更新ロックが掛けられている場合には、共有系のロックのみ取得することが可能です。インテント排他の場合は、インテント共有のみ取得が可能です。排他ロックが掛かっている場合は、いかなるロックも取得ができません。
ロック制御において、もう1つ考えておかなくてはならないのが、デッドロックです。デッドロックとは、2つのトランザクションが互いのロックを取り合う、という状況です。例えば、顧客マスタメンテナンスのトランザクションが、顧客マスタと会社マスタをこの順番で同時に更新しようとします。
一方、受注システムのトランザクションも、同じ会社マスタと顧客マスタをこの順番で更新しようとします。通常、これらが同時に実行されることはないため問題になりませんが、たまたま、この2つのトランザクションが同時に実行を開始すると、次のような状況に陥ります。
顧客マスタメンテナンストランザクションは、会社マスタをロックしようとするが、受注システムトランザクションによってロックされているため、ロックが解除されるまで待つ。
受注システムトランザクションは、顧客マスタをロックしようとするが、顧客マスタメンテナンストランザクションによりロックされているため、ロックが解除されるまで待つ。
この状態になると、上記のステップ3と4で、それぞれ相手のトランザクションが終了するのを待ち合うため、いつになってもトランザクションが終了しません。これを、デッドロックの状態と呼びます。データベースサーバにとっては、これは致命的で回避不能な状態であるため、データベースサーバはデッドロックを検知して、自動的にロールバック、もしくはリトライをするための仕組みを持っています。
SQL Serverは、一定時間ロック解除を待っているトランザクションを検知し、デッドロックに陥っていないか否かをチェックする方法で、デッドロックを回避します。ただし、デッドロックは上記の例のように、同じオブジェクトを違う順番でロックを掛ける場合に発生します。このため、可能な限り設計時点でオブジェクトに対してロックを掛ける順番を決めておくことで、デッドロックは容易に回避が可能となります。
約3年間にわたる長期・不定期の連載となってしまいましたが、ようやくSQLを一通りカバーすることができました。今回にて、本連載は終了させていただきます。ご愛読、本当にありがとうございました。データストアの世界は、今後、よりXMLとの親和性が高くなり、オブジェクトのストアが容易になる方向性にあると思います。
そして、SQLもまた、XQueryというXML対応のクエリに時代の方向性は向かっています。これはこれで、非常に面白い時代になってきたものだと、胸に期待を踊らせています。
ただし、オブジェクト指向が当たり前になったいまの時代になって初めて分かることは、根底に流れているものは同じだということです。そして、RDBMSとデータ指向という考え方が、どれだけ人間の感覚とマッチしていたかということを、痛切に感じます。単なるSQLという1つの言語としてとらえるのではなく、その根底に流れているものを、少しでも感じていただけたとしたら非常に光栄です。
5分で絶対に分かるSIP （2007/11/16）インターネットで電話をかけるためには、発信や着信、応答、切断といった制御が必要です。その手順を取り決めたシグナリングプロトコルの1つ、SIPを5分で理解しましょう
携帯メールポータビリティは開国を迫る黒船となるか （2007/10/31） 丹後から日本のケータイにもの申す。TANGOメールは携帯電話ネットワークのオープン化への第一歩となるか？
「はてな」を作り出す人的ネットワークの仕組みとは （2007/8/24） 次々とWeb2.0的サービスをリリースするはてな。拡大する組織の中で行われているコミュニケーションのかたちとは？
＠IT ネットワーク用語辞典 （2007/8/22）ネットワーク管理者のための用語集です。「LAN」や「IPアドレス」といった基本中の基本から、「HTTP」などのプロトコル、「ping」などのコマンドまで、幅広く解説します
エンジニアとしての力量を数値で測った経験は？ITSSレベルを無料で判定、12月25日（火）まで
ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン

[ 41] ＠IT：SQL Serverで「デッドロック」を回避する
[引用サイト]　 http://www.atmarkit.co.jp/fnetwork/rensai/sql28/sql1.html

漢字やひらがななど、数多くの文字を持つ日本において、文字化けはいまだに避けて通れない問題だ。XMLでは、こうした文字化けを防止するための仕組みが備わっているが、それでもなお完全に封じ込めることはできていない。その理由について解説しよう。
XMLは、安全かつ安定した情報交換の手段として利用できることを目的にした、よく考えられたメタ言語である。XMLより以前のSGMLなどと比較して、格段の進歩が見られる。たとえばSGMLでは、SGML文書を記述するためにどんな文字コード系を使用するか、標準的な規定が何もなかった。そのため、あるSGML文書が、ほかのシステムで正常に読めるかどうか、何の保証もなかったと言ってよい。これに対して、XMLでは文字コード系に関しても明確なルールを導入することで、交換性を保証するようになっている。これは、不特定多数の利用者が相互に情報を交換する時代には不可欠な条件といえる。
ところが、このような進歩にも関わらず、XMLを用いた情報交換には文字化けの危険が存在するのである。今回は、XMLが従来の情報交換言語に対して、いかに文字化けを防止するために進化したのか。そして、それにも関わらずどんな危険が存在するのか。それを回避するにはどうしたらよいかを解説する。
パソコン業界で文字化け現象なるものが最初に大きな問題として認識されたのは、1983年の「JIS X 0208」改正の後のことだと思われる。これは筆者も直接体験したことがある。当時人気の高かったNEC製のパソコンと、やはり当時人気の高かったエプソン製のプリンタを接続したときに、画面上に表示されている文字が印刷できない、あるいは、違う文字が印刷されてしまうという現象に遭遇した。この現象そのものは、エプソン製プリンタに、NEC製プリンタをエミュレートするROMカートリッジオプションを入れることで収まった。だが、なぜ、こんな問題が起きたのだろうか？
JIS X 0208というJIS規格は、第1水準、第2水準と呼ばれる主要な日本語文字を規定する規格だが、1983年の改正において、いくつかの文字の追加と、既存の文字表内の文字の位置の交換が行われている。この結果、1983年以降の規格に準拠した製品と、それ以前の規格に準拠した製品では、同じコードが同じ文字を指し示していない状況が発生した。上記の例では、パソコン本体は1978年規格、プリンタは1983年規格のそれぞれ準拠したために、文字化けが生じていたのである。
もう1つ、ここで発生した文字化けには、機種依存文字という問題も含まれる。パソコン本体で表示できるのに、印刷はできない文字が発生したというのは、パソコン本体にメーカー独自に定義した文字が含まれているのに、別メーカー製のプリンタにはそれが含まれていなかったという事実によるものだ。
この時点で、機種依存文字が文字化けを引き起こす、という問題はそれほど重要なことだとは思われていなかった。要するに、プリンタに、パソコン本体と同じメーカーのプリンタをエミュレートするオプションを追加すれば解消されるのである。幸運というべきか、不幸というべきか、この当時の日本人は、パソコンをネットワークするという発想を知らず、モデムすらパソコンショップでは販売されていなかったのである。そのため、パソコンとプリンタは1対1で接続され、ネットワーク経由で他のパソコンから受け取ったデータを打ち出すこともなかった。そのため、自分の使っているパソコンとプリンタの仕様さえ一致させれば、それで問題は解決できたのである。
ところが、ある出来事をきっかけに、これらの文字化け問題は再び燃え上がる。それは、通信回線に関する規制緩和によって起こった。いわゆるパソコン通信ブームである。パソコン通信によって不特定多数の利用者がメッセージを交換するようになると、否応なしに、「我々は同じ文字を共有していない」という事実を痛感させられることになる。この結果として、パソコン通信では、交換性に問題のある文字を使わないというマナーが確立されていく。
パソコン通信で噴出した文字化け問題はこれだけではない。まず、日本には、多くの互換性のない文字コード系が存在するという事実が明らかになった。要するにメーカごと、OSごとに互いに互換性のない文字コード系を使用しているということである。それぞれ、JIS
X 0208という共通の文字集合を使っているにも関わらず、具体的なビットの並べ方のルールに互換性がなかったのである。これまでパソコンをネットワークするという発想がなかった日本では、当然の成り行きといえば、その通りであった。もし、文字コード系に互換性がないパソコン間で通信を行うと、まったく意味不明のでたらめな文字列が受信されてしまうことになる。しかし、ネットワークするという甘い蜜を知ってしまった利用者は、もう後戻りはできない。パソコン通信用の通信ソフトでは、何種類もの文字コード系を切り替えて利用可能にするのが一般的であり、サービス提供側が複数の文字コード系を選択可能とすることもあった。
以下は実際に、秀丸エディタで「わざと」文字コード系の選択を誤ってファイルを読み込んでみた。互換性のないシステム間で何も工夫せず情報交換を行うと、こういう事態が起きるという一例である。
このような文字化けが起きる根本的な理由は、特定メーカー内で閉じた技術体系を利用して、不特定多数の通信を行おうとしているためだと言える。しかし、インターネットブーム以後、ネットワークが社会基盤として位置づけられている今、特定メーカーの製品でしか機能しないようなハードやソフトは、時代にそぐわない。
この問題に対処する1つの「正義」は、「世の中で使用されている文字コード系はすべて利用可能とすべき」というものだ。しかしながら、このような正義が現実のソフトウェアとして結実しているとは言い難い。実際に、どんな文字コード系でも読み書きできるソフトウェアなど、限りなく皆無に近い状況と言える。そのようなソフトウェアは開発するためにとてつもなく多くの工数を必要とし、その上、利用者にも高度な使いこなしの技術を要求する。文字コード系の範囲を日本だけでなく世界に広げるなら、本当に正しく処理できているかをチェックするために、全世界で使われる言語を理解している人材を揃える必要もあるが、これは現実的とは言えない。
現実的な解決策は、すべての文字コード系を利用可能にすることではなく、世界で1つしか存在しない標準コード系に統一していくことである。この方法は、すべての利用者が使用する文字コード系を変更することになり、一見現実的ではないように見える。しかし、すべての文字コード系を理解するようにすべてのソフトウェアを変更することに比べると、はるかに手間やコストは小さくて済むのである。この目的のために作られた文字コード系を、「Unicode」という。UnicodeはUnicodeコンソーシアムという私的な団体が作っているものだが、これと同等のものを国際標準団体であるISOとIECが規格化したものがあり、これを「ISO/IEC-10646」という。これは日本においては、「JIS
Unicodeの成立を受けて、近年の最新標準の多くは、Unicodeを採用している。たとえば、プログラミング言語のJavaやWindows
NT/CEのような新しい世代のOSなどがUnicodeを扱うことを前提に設計されている。これらは、Unicode以外の文字コード系はすべて一度Unicodeに変換した上で扱うという方針を取っており、入口と出口を除けば内部はすべてUnicodeで処理される。XMLも、まさにこのような流れの中に位置する技術であり、これらと同様に、Unicodeを前提に設計されている。
まず最初に特筆すべきことは、Unicodeの採用と、そのサポートの義務化である。人は皆、メーカーも利用者もこれまでの慣習の継続を無意識に望むものである。そのため、いくらUnicodeに統一しようと言ったところで、現実には「総論賛成各論反対」ということに陥りやすい。そこで、情報交換用の標準規格の現場でも、きちんとポリシーを持って取りかからねば、なかなかUnicodeの利用を認めるところまでは行けても、Unicodeのサポートを義務とするところまでは行けない。
もちろん、XMLがUnicodeを義務としたことに、反発がないわけではない。しかし、XMLが一種のすがすがしさを持つのは、一切の特例を認めなかった点である。米国を中心に世界の標準とも言えるUS-ASCIIコードすら、XMLでは標準の一部として認められていない。US-ASCIIが認められていない以上、それよりも国際的利用頻度の低い各国のコード系が、標準と認めろとは言い出せない雰囲気がある。これにより、米国にだけ有利ということはない、国際的に平等な情報交換用のメタ言語に、XMLはなることができたのである。
より具体的に言えば、XMLを処理するソフトウェアは、Unicodeの情報交換用のフォーマットである「UTF-8」と「UTF-16」を必ずサポートしなければならないと決められている。その結果、UTF-8とUTF-16のどちらかを使用すれば、文字コード系の食い違いによる文字化けを起こさずに処理できるのである。この偉大な一歩によって、UTF-8とUTF-16のどちらかを採用することができれば、ほとんどの難しい問題と別れを告げることができるのである。どんなXMLソフトウェアでも、この2つは出力でき、そして、入力もできるのである。いちいち、相手がどんなソフトを使っているか確認する必要もない。唯一の懸念事項は、UTF-8とUTF-16を取り違えて処理することによる文字化けである。しかし、このような間違いは、テキストの先頭にBOM（Byte
Order Mark）と呼ばれる印を付けることで判断ミスを自動チェックすることができる。また、万一間違った場合でも、この2つは大きく異なるため、一部の文字は正しく読めるというような事態は起こらず全ての文字が化ける。そのため、間違ったことに気付かずに作業を進めると言うことは、少なくとも人間が目で見てチェックするとしたら、あり得ない事態と言える。
さて、「すべてUTF-8またはUTF-16を使用すれば」という前提は、まだUnicode時代への過渡期にある現在では実行するのが辛いという現実もある。既存のソフトのうち、Unicodeに対応していないものも多い。使い慣れたテキストエディタでXML文書を作成しようと思ったけれど、UTF-8にもUTF-16にも対応していない、というケースもあるだろう。こういったさまざまな事情に対応するため、XMLではUnicode以外の文字コード系（例えばシフトJISや日本語EUC）の使用も認めている。ただし、これは「認めている」のであって、「保証」しているわけではない。保証されるのはUTF-8かUTF-16だけである。つまり、世の中にあるXMLアプリケーションソフトの中には、UTF-8とUTF-16以外の文字コード系を処理するものがあってもよいが、すべてのXMLアプリケーションソフトが、これ以外の文字コード系を扱う義務はないということである。そのため、UTF-8とUTF-16以外の文字コード系でXML文書を扱いたい場合は、あらかじめ使いたいXMLアプリケーションソフトが、その文字コード系をサポートするかどうかを確認をする必要がある。もちろん、確認がとれない場合は、使うべきではない。
ここで問題になるのは、いったいどんな文字コード系でXML文書を書いたのか、それを判定する方法である。これが簡単な手段で判定できないと、文字化けの悪夢が容易に再来してしまう。HTTPを用いた通信（URL/URIで「http:」で始まるもの）では、本来、本文に先立って送信されるhttpヘッダーと呼ばれる箇所で、文字コード系を明示するのが正しいやり方である。この話題は、W3Cの
XMLワーキンググループのメンバーである村田真氏や、国際化の専門家である慶 應大学のMartin J. Durst氏などによる労作である「charsetパラメタの勧め:
HTMLにおける文字符号化スキームの明示方法」で詳述されている。しかし、HTTPを使わない場合、例えばローカルのハードディスク上でXML文書を扱う場合などは、この方法は使えない。そこで、XML文書の最初の1行に記述できるXML宣言の中に、文字コード系の名前を記述するという方法を採ることができる。
たとえば、シフトJISで記述されていることを明示して文字化けを回避するには、以下のように記述する。
encoding=の後に書かれたものが、文字コード系の名前である。シフトJISはShift_JISと記述する。日本語EUCはEUC-JPと記述する。名前をくくる記号は、ダブルクオート（"）でもシングルクオート（'）でも、どちらを使っても構わない。
SETSという文書に登録されているものか、あるいは、「x-」の2文字で始まる名前に限られる。IANAに登録されている名前は、基本的に、それをサポートしたXMLアプリケーションソフト間では情報交換に利用できると考えてよいだろう。「x-」の2文字で始まる名前は、誰でも自由に名前を付けることができるが、交換性はまったく期待できない。その上、それをサポートしたXMLアプリケーションもほとんど存在しない。「x-」の2文字で始まる名前は、よほど特殊な状況でもなければ出番がないと思って間違いないだろう。
このような方法で、Unicode以外の文字コード系を使用する場合に注意すべき点が2つある。1つは、XML宣言で「encoding=」を記述する方法は、何らかの形でUS-ASCIIコードと互換性のある文字コード系に限られるということである。つまり、まずXML宣言を構文解析できねば、名前を取り出すことができないため、XML宣言はUS-ASCIIコードと仮定されて、チェックされるのである。たとえばシフトJISは、半角英数文字の範囲に関しては、一部記号を除き、US-ASCIIコードと互換性があるので、このチェックを通る。しかし、US-ASCIIから遙かにかけ離れた文字コード系（たとえば、IBMのEBCDICなど）は、このチェックを通らないかもしれない。
もう1つの注意点は、XMLが、XMLの仕様の中で利用可能な文字の範囲をUnicodeで規定している点である。この定義の結果として、どんな文字コード系を使った場合でも、文字の妥当性のチェックは、Unicodeのコード値を前提に行われねばならないことになる。このことは、裏を返せば、Unicodeに収録されていない文字は、どう逆立ちをしても、XML文書中に記述できないということを示す。現実的なXMLアプリケーションソフトの実装から考えても、Unicodeに収録されていない文字を処理するのは困難である。なぜなら、XMLアプリケーションソフトは、どんな文字コード系でXML文書を受け取った場合でも、一度Unicodeに変換してから処理するのが一般的である。そのため、Unicodeに変換できない文字があると、それは処理対象とすることができない。このような状況から、XMLで使用できるUnicode以外の文字コード系は、Unicodeに変換できる（つまりすべての文字がUnicodeに収録されている）ことが条件となる。この条件を満たさないものとして、2000年10月現在としては、いわゆる第3水準、第4水準と呼ばれる「JIS
X 0213」が存在する。JIS X 0213に収録されている文字の中で、Unicodeにない文字は、現在Unicodeに収録すべく作業中であると言われている。この作業が完了し、公式にUnicodeに収録されて、Unicode上の文字コードが確定すれば、JIS
JIS X 0213に関しては、事前にこのような問題が起きることが明らかであったにも関わらず、強行的にJIS規格とされたことが悔やまれる。現時点でXMLとJIS
X 0213は両方を同時に採用することはできない点に、XML利用者は十分に注意されたい。もし、どうしてもJIS規格でなければならない、という状況であるようなら、JIS
ここまで見てきたように、XMLではUnicode登場以前に知られている文字化け問題に関しては、ほぼ完璧に対策を打っていることが分かる。ところが、XMLは完全に文字化け問題から解放されていないことが判明したのである。
TR X 0015:1999 XML 日本語プロファイルに述べられている。要するに、Unicodeの登場以前には存在していなかった新しいタイプの文字化け現象が出現したということである。そして、Unicodeをシステムの内部処理にのみ使用し、情報交換に使用しない間には顕在化しなかった問題とも言える。そういう意味で、XMLが初めて問題を明らかにしたものだと言える。
この問題の性質を理解するには、Unicodeという文字集合の作成方法を知る必要がある。Unicodeは、全世界の文字コード系を集めて、それに収録された文字をすべてリストアップして整理して作られた。この方法なら、Unicodeの元になったすべての文字コード系にあったすべての文字は、Unicodeに収録されていることが保証される。ところが、である。確かに、足りない文字はないのだが、よく似た文字が複数収録されていて、区別を付けにくい、という状況が起こってしまったのだ。たとえば、横棒の記号の一種であるダッシュ（-）だけでも、何種類も微妙に異なるバリエーションが収録されているのである。さらに困ったことに、どの文字が元の規格のどの文字に対応するか、明確な情報が残っていないのである。漢字に関しては幸いなことに、いろいろ騒動があったため、Unicodeの規格書に元規格との関係が記されているのだが、それ以外の文字に関しては、そのような情報が存在していないのである。
この結果として、主に記号類に関して、元規格とUnicodeの間で、どの文字とどの文字が対応するのか、人によって解釈が違うという現象が起きてしまった。そして、その解釈の違いが解消されないまま、それぞれのメーカーはUnicodeを自社ソフトに組み込む作業に着手した。従来からある資産を活用するために、従来型の文字コード系とUnicodeの間で文字コード変換を必要とするので、当然、変換ルールを記述した変換テーブルというものが作成される。ところが、変換ルールが人によって解釈が違うため、できあがった変換テーブルはメーカーごとに中身に相違があるという事態が生じてしまったのである（具体的な相違点を知りたい方は、筆者の調査結果が公開されているので参照願いたい）。
このような状況は、XMLにもストレートに反映されている。変換テーブルが何種類もあるということは、XMLアプリケーションソフトが使用する変換テーブルも一定していないということだ。つまり、シフトJISのような従来型の文字コード系でXML文書を書いた場合、使用するXMLアプリケーションソフトの種類によって、処理結果が異なる可能性があると言うことだ。
例えば、XMLパーサのような同じ機能を持ったソフトウェアが複数ある場合、本来なら同じXML文書を入力すれば、同じ出力が出てくることが期待される。ところが、上記のような状況があるため、同じXML文書を入力しても、結果として出てくる文字列の文字コードが食い違っている、という可能性がある。
このような状況は、検索機能などでは致命的な問題を引き起こす。また、電子署名など、厳密な一致が得られなければならない分野では、使い物にならないことになる。
これを回避する方法は、いくつか考えられる。たとえば変換テーブルの統一ができれば、文字化けを回避することができる。現在、各メーカーは、市場の要請から各社独自の変換テーブルからマイクロソフトの「CP932」と呼ばれる変換テーブルに合わせて変換テーブルを入れ替える動きがある。これが結実すれば問題は軽減されるかも知れないが、すでに多くの変換テーブルを含むソフトウェアが世の中に普及してしまったという事実があるため、完全な解決にはならない。
結局、問題を完全に解決するためには、最初から最後までUnicodeを使うしかない。XMLでは、Unicode以外の文字コード系を使用するオプションを用意しているが、これは利用できないと考え、全面的にUnicodeに移行するしかない。
しかしながら、ただ単にXML文書をUnicodeで書くようにしただけでは十分ではない。システムの中のどこかで文字コード変換を行っていれば、そこでトラブルが起きる可能性がある。たとえば、入力や出力をUnicodeで行うことができないシステムでは、入出力時に文字コードを変換してやらねばならない。その時点でトラブルが起きる可能性がないとは言えないわけだ。実際に、システムが一貫してUnicodeを扱うことができないOSやアプリケーションソフトも、まだまだ存在する。たとえば、Windows
2000は一貫してUnicodeで処理できるが、Linuxはまだ発展途上であり、Li18nuxなどの国際化とUnicode対応の強化プロジェクトが存在する。
いろいろ厳しい話を書いてきたが、悲観する必要はないと筆者は考える。ドッグイヤー、キャットイヤーで変化し続けるこの業界において、ソフトウェアやシステムの世代交代は早い。このような文字化け問題が、過渡期の笑い話となる日はそれほど遠くないだろう。それまでの間、XML利用者は、このような文字化けが起きるリスクに注意を払って、それを回避するように行動すればよいのである。少なくとも、Unicodeで記述されたXML文書形式で資産を蓄積しておけば、未来においてそれが無駄になることはないだろう。
さて、これまでXML 1.0 勧告のアウトラインを見てきたが、今回文字の話題を扱ったことで、そろそろ全体像が見えてきたと思う。そこで、次回からは、XML
1.0勧告の枠を飛び出して、その周辺の世界にも目を向けてみよう。最初に取り上げるのは、XML 1.0勧告そのものを一部変更する構文を含むほど、密接な関係のある名前空間（Namespaces
in XML）を解説しよう。これは、現在の実用言語（XMLによる）では、必ずと言ってよいほど使用されている重要な機能である。
QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21） データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された
文字符号化方式にまつわるジレンマ （2005/9/13） 文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる
XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16） セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
エンジニアとしての力量を数値で測った経験は？ITSSレベルを無料で判定、12月25日（火）まで
ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン
＠ITトップ｜XML & SOAフォーラム トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ

[ 42] Unicodeでも発生する文字化けの危機と回避
[引用サイト]　 http://www.atmarkit.co.jp/fxml/rensai/xmlwomanabou06/learning-xml06.html



回避とは？トップへ↑

お気に入り



  • track feed
    • seo