>>173
今更だけど、文字が分断される可能性についても公平を期すために触れておくよ。
単純にバイト数で分割する場合等を除けば、ほとんどはパターンマッチにおける誤マッチが原因だろう。
strchr や strstr 、あるいはもっと高度なライブラリを使った結果かもしれない。
探すパターンに [\100-\176] にマッチする文字が含まれているなら EUC では誤マッチは起こらない。
シフトＪＩＳではダメ文字のせいで誤マッチが起こりうる。
実際に問題になるのはほとんどがこのケース。
grep "\]"
などとやろうものなら悲惨なことになる。
探すパターンがマルチバイト文字だけなら EUC でもシフトＪＩＳと同程度には誤マッチが起こりうる。
しかし実際にはほとんど起こらない。
もちろん起こるときは起こるし対策も出来るが対策は速度の低下と引換だ。
30 年前の CPU クロックは 10MHz 程度だったので速度も重要だった。
ほとんど起こらない上に致命的でもないなら速度を犠牲にしてまで常に対策を講じる必要は無い。
ちなみに対策だが、EUC で grep する場合なら
egrep "^([\000-\177]|\216[\240-\337]|\217[\241-\376][\241-\376]|[\241-\376][\241-\376])*$pattern"
的なことをするプログラムを grep_euc とかそういう名前で作っておけばいい。
シフトＪＩＳの場合はこれに加えてシフトＪＩＳな部分を 8 進エスケープシーケンスに置き換える必要がある。
同じやり方で iso-2022-jp も処理できる。
シフトＪＩＳしか通さない grep など技術的には邪魔なだけだよ。