1. ホーム
  2. perl

[解決済み] 最近のPerlはなぜデフォルトでUTF-8を避けるのですか?

2022-03-17 06:54:05

質問

Perl を使って作られた最新のソリューションのほとんどが、なぜ UTF-8 をデフォルトで使用します。

Perlのコアスクリプトにはレガシーな問題が多く、それが原因で物事が壊れてしまう可能性があることは理解しています。しかし、私の見解では、21の st 世紀には、大きな新しいプロジェクト(あるいは大きな視野を持ったプロジェクト)は、自分たちのソフトウェアをゼロからUTF-8対応にすべきなのです。それでも私は、それが実現するとは思っていません。例えば ムース は strict と warnings を有効にしますが ユニコード . モダン::パール もボイラープレートを削減しますが、UTF-8 の処理は行いません。

なぜ?2011年の現代のPerlプロジェクトにおいて、UTF-8を避けるべき理由があるのでしょうか?


コメント@tchristが長くなりすぎたので、ここに追加します。

私の説明が不十分だったようです。少し補足してみます。

チクリスト と私はかなり似たような状況を見ていますが、結論は全く逆になっています。しかし、だからこそ、私たち(Perlユーザーとコーダー)は、UTF-8を簡単に扱えるようにする層(またはプラグマ)を必要としているのです。

トクリスト を指摘されると、何日も、あるいは何週間も読んで考えることになる。それでも、これは私のポイントではありません。 トゥクリスト は、UTF-8を有効にする方法は1つではないことを証明しようとしています。私はそれに反論できるほどの知識を持っていません。だから、私は実例にこだわるのです。

で遊んでみました。 楽土 とUTF-8がそこにあるだけでした 必要な . 何の問題もなく、ただ動きました。もしかしたら、もっと深いところで何らかの制約があるのかもしれませんが、とりあえず、私がテストしたものはすべて期待通りに動きました。

それは最新のPerl 5でも目指すべきことではないでしょうか?もっと強調しておきます。私はUTF-8をコアPerlのデフォルト文字セットとして提案しているのではなく、それをトリガーする可能性を提案しているのです。 ポンと を開発する人のために 新しい プロジェクトがあります。

別の例ですが、より否定的なトーンです。フレームワークは開発を容易にするものでなければなりません。数年前、私はウェブフレームワークを試しましたが、UTF-8を有効にすることがあまりにも不明瞭だったため、そのまま投げ出してしまいました。というのも、UTF-8を有効にする方法があまりにも不明瞭だったからです。それはとても時間がかかることで、私は古い方法で行く方が簡単だと感じました。今、私はここで、同じ問題に対処するための懸賞金があることを知りました。 メイソン 2: Mason2のUTF-8をクリーンにするには? . というわけで、かなり新しいフレームワークですが、UTF-8で使うには、その内部を深く知る必要があります。大きな赤信号のようなものです。私を使わないでください。

私はPerlがとても好きです。でも、Unicodeを扱うのは苦痛です。今でも壁にぶつかっている自分がいます。なんとか チクリスト 新しいプロジェクトがUTF-8を採用しないのは、Perl 5では複雑すぎるからです。

どのように解決するのですか?

???????????????????????????????? : ???? ???????????????????????????????? ????????????????????????????????????????????????????????????

  1. 設定する PERL_UNICODE 変数に AS . これにより、すべてのPerlスクリプトは、デコードされた @ARGV をUTF-8文字列とし、stdin, stdout, stderrの3つすべてのエンコーディングをUTF-8に設定します。これらはいずれもグローバルな効果であり、レキシカルな効果ではありません。

  2. ソースファイル(プログラム、モジュール、ライブラリ。 do ヒッキー) を使っていることを目立つように主張してください。

    use v5.12;  # minimal for unicode string feature
    use v5.14;  # optimal for unicode string feature
    
    
  3. 前の宣言は警告ではなく、厳密性と機能のみを有効にしているので、警告を有効にしてください。また、Unicode警告を例外に昇格させることを提案しますので、これらの行を片方だけでなく両方使用してください。 ただし、v5.14では utf8 警告クラスは3つのサブ警告から構成されており、それぞれを個別に有効にすることができます。 nonchar , surrogate および non_unicode . これらは、より大きな制御を行うことができます。

    use warnings;
    use warnings qw( FATAL utf8 );
    
    
  4. このソースユニットはUTF-8としてエンコードされていることを宣言します。昔々、このプラグマは他のこともしていましたが、現在はこの1つの目的だけに使用され、他の目的には使用されません。

    use utf8;
    
    
  5. ファイルハンドルを開くものはすべて、以下のように宣言します。 このレキシカルスコープ内の他の場所ではなく は、特に指示しない限り、そのストリームがUTF-8でエンコードされていると仮定することです。そうすることで、他のモジュールや他のプログラムのコードに影響を与えずに済みます。

    use open qw( :encoding(UTF-8) :std );
    
    
  6. 名前付き文字を有効にするには \N{CHARNAME} .

    use charnames qw( :full :short );
    
    
  7. がある場合は DATA ハンドルは、明示的にそのエンコーディングを設定する必要があります。もしこれをUTF-8にしたいのであれば、こう言ってください。

    binmode(DATA, ":encoding(UTF-8)");
    
    

もちろん、最終的にあなたが関心を持つであろう他の事柄は無限にありますが、これらの用語の感覚を多少弱めたとはいえ、「すべてをUTF-8で動作するようにする」という国家目標に近づけるには十分でしょう。

もう一つ、Unicodeとは関係ありませんが、プラグマがあります。

      use autodie;

強く推奨します。

???? ???????????? ???? ???????? ???????????????? ???????????? ???????? ???????????????????????????????? ???? ???????????? ????


???? ???? ????????????????????????⸗???????????????????? ???????????? ????????????????????????????⸗???????????????????? ???????????????? ???? ????


最近の自分のボイラープレートは、こんな感じになりがちです。

use 5.014;

use utf8;
use strict;
use autodie;
use warnings; 
use warnings    qw< FATAL  utf8     >;
use open        qw< :std  :utf8     >;
use charnames   qw< :full >;
use feature     qw< unicode_strings >;

use File::Basename      qw< basename >;
use Carp                qw< carp croak confess cluck >;
use Encode              qw< encode decode >;
use Unicode::Normalize  qw< NFD NFC >;

END { close STDOUT }

if (grep /\P{ASCII}/ => @ARGV) { 
   @ARGV = map { decode("UTF-8", $_) } @ARGV;
}

$0 = basename($0);  # shorter messages
$| = 1;

binmode(DATA, ":utf8");

# give a full stack dump on any untrapped exceptions
local $SIG{__DIE__} = sub {
    confess "Uncaught exception: @_" unless $^S;
};

# now promote run-time warnings into stack-dumped
#   exceptions *unless* we're in an try block, in
#   which case just cluck the stack dump instead
local $SIG{__WARN__} = sub {
    if ($^S) { cluck   "Trapped warning: @_" } 
    else     { confess "Deadly warning: @_"  }
};

while (<>)  {
    chomp;
    $_ = NFD($_);
    ...
} continue {
    say NFC($_);
}

__END__


???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ????


Perlは[ ]であるべきだ」と言うこと。 なんとか Unicodeをデフォルトで有効にする "というのは、ある種の稀で孤立したケースにおいて、ほんのわずかでも役に立つようなことを言うようになることを考え始めることさえしません。 Unicodeは、単に文字のレパートリーが増えたというだけでは不十分で、それらの文字がどのように相互作用するかということも重要です。

一部の人々が望んでいると思われる、単純明快な最小限の対策でさえ、何百万行ものコード、つまり、あなたの美しい新しいコードに「アップグレード」する機会のないコードを、悲惨にも壊してしまうことが保証されています。 ブレイブニューワールド 近代化です。

それは、人々がふりかざしているよりもずっとずっと複雑なことなのです。 私はこの数年間、このことについて非常にたくさん考えてきました。 私は、自分が間違っていることを教えてもらいたいと思います。 しかし、私はそうではないと思います。 Unicodeは、あなたが課したいと思っているモデルよりも根本的に複雑であり、ここには、あなたが決して掃き清めることのできない複雑さがあります。もしそうしようとすれば、あなた自身のコードか、他の誰かのコードを壊してしまうでしょう。 ある時点で、あなたは単純に分解して、Unicodeが何であるかを学ばなければならないのです。 そうでないもののふりをすることはできないのです。

私がこれまで使ってきたどの製品よりも、Unicodeを簡単にするためにわざわざ作っているのです。これが悪いと思うなら、しばらくの間、他のものを試してみてください。より良い世界に戻ってきたか、あるいは同じような知識を持ってくるでしょうから、私たちはあなたの新しい知識を利用して、これらのことをより良くすることができます。


???? ???????????????????? ???????????? ???? ???????????????????????????? ⸗ ???????????????????? ???? ???????????????????????????? ???????????????? ????


最低限、あなたが言うように「デフォルトでユニコードを有効にする」ために必要だと思われるものをいくつか挙げてみます。

  1. すべてのソースコードは、デフォルトでUTF-8であるべきです。 それを得るには use utf8 または export PERL5OPTS=-Mutf8 .

  2. は、? DATA のハンドルはUTF-8でなければなりません。のように、パッケージごとに行う必要があります。 binmode(DATA, ":encoding(UTF-8)") .

  3. スクリプトのプログラム引数は、デフォルトでUTF-8であると理解する必要があります。 export PERL_UNICODE=A または perl -CA または export PERL5OPTS=-CA .

  4. 標準入力、出力、エラーストリームのデフォルトはUTF-8であること。 export PERL_UNICODE=S をすべて使用するか、あるいは I , O および/または E を一部だけ使用することができます。これは次のようなものです。 perl -CS .

  5. で開かれる他のハンドルは、特に宣言されない限りUTF-8とみなされるはずです。 export PERL_UNICODE=D または io を、これらの特定のものに対して使用します。 export PERL5OPTS=-CD が機能します。 そうすると -CSAD を全てに使用することができます。

  6. 両方のベースに加えて、あなたが開くすべてのストリームをカバーします。 export PERL5OPTS=-Mopen=:utf8,:std . 参照 一意性 .

  7. UTF-8のエンコードエラーを見逃さないようにしたい。試す export PERL5OPTS=-Mwarnings=FATAL,utf8 . また、入力ストリームは常に binmode dから :encoding(UTF-8) に限らず :utf8 .

  8. 128-255のコードポイントは、単なる未整理のバイナリ値ではなく、対応するUnicodeコードポイントであると「? use feature "unicode_strings" または export PERL5OPTS=-Mfeature=unicode_strings . これによって uc("\xDF") eq "SS""\xE9" =~ /\w/ . 単純な export PERL5OPTS=-Mv5.12 以上でも取得できます。

  9. 名前付き Unicode 文字はデフォルトでは有効ではないので、文字列の前に export PERL5OPTS=-Mcharnames=:full,:short,latin,greek などがあります。参照 名前なし tcgrep .

  10. の関数にアクセスする必要がある場合がほとんどです。 標準的な Unicode::Normalize モジュール 様々な種類の分解 export PERL5OPTS=-MUnicode::Normalize=NFD,NFKD,NFC,NFKD そして、常にNFDからの受信とNFCからの送信を実行します。私が知る限りでは、これらのためのI/Oレイヤーはまだありませんが、以下を参照してください。 nfc , nfd , nfkd および nfkc .

  11. を使用した文字列比較。 eq , ne , lc , cmp , sort は、常に間違っています。 ですから、代わりに @a = sort @b が必要です。 @a = Unicode::Collate->new->sort(@b) . を追加するとよいでしょう。 export PERL5OPTS=-MUnicode::Collate . バイナリ比較のためにキーをキャッシュすることができます。

  12. のようなビルトインがあります。 printfwrite は、Unicode データに対して間違ったことをします。 そのため その Unicode::GCString モジュール は前者で、それと同じく Unicode::LineBreak モジュール のように、後者については 参照 ユーユーシー ユニファーム .

  13. もし、整数としてカウントさせたいのであれば、あなたの \d+ キャプチャを その Unicode::UCD::num 機能 というのも、ビルトインの アトイ (3)は今のところ十分に賢いとは言えません。

  14. ファイルシステム上で問題が発生する可能性があります。あるファイルシステムは無言で NFC への変換を強制し、別のファイルシステムは無言で NFD への変換を強制します。また、他のものは、まだ何か他のことをします。あるものは、この問題を完全に無視し、さらに大きな問題を引き起こします。そのため、正気を保つためには、独自のNFC/NFDハンドリングを行う必要があります。

  15. あなたのコードに関わるすべての a-z または A-Z といった を変更する必要があります。 を含む。 m// , s/// および tr/// . これは、あなたのコードが壊れていることを示す悲鳴のような赤旗として目立つはずです。しかし、どのように変更しなければならないかは、明らかではありません。正しいプロパティを取得し、そのケースフォールドを理解することは、想像以上に難しいことなのです。私が使っている 一文字 ユニプロップス 毎日毎日

  16. を使用するコード \p{Lu} を使うコードと同じぐらい間違っています。 [A-Za-z] . この場合 \p{Upper} の代わりに、その理由を知っておいてください。そうです。 \p{Lowercase}\p{Lower} とは異なります。 \p{Ll}\p{Lowercase_Letter} .

  17. を使用するコード [a-zA-Z] はさらに悪い。 そして、それは \pL または \p{Letter} を使用する必要があります。 \p{Alphabetic} . アルファベットの全てが文字ではありませんよ。

  18. という変数を探している場合。 /[\$\@\%]\w+/ であれば、問題があります。 あなたが探す必要があるのは /[\$\@\%]\p{IDS}\p{IDC}*/ それすらも、句読点変数やパッケージ変数について考えていないのです。

  19. 空白をチェックする場合は、以下のいずれかを選択します。 \h\v によって、異なります。 そして、決して \s というのは を意味するものではありません。 [\h\v] 一般に信じられていることとは異なりますが。

  20. を使用している場合 \n は線の境界線、あるいは \r\n というのは、間違っています。 その場合は \R これは同じではありません。

  21. をいつ、どのように呼び出せばいいのかわからない場合は、以下のようにします。 Unicode::Stringprep ということで、勉強したほうがいい。

  22. 大文字小文字を区別しない比較では、2つのものが発音記号などに関係なく同じ文字であるかどうかをチェックする必要があります。 これを行う最も簡単な方法は 標準的な Unicode::Collate モジュールを使用します。 Unicode::Collate->new(level => 1)->cmp($a, $b) . また eq メソッドなどについて学ぶべきでしょう。 matchsubstr メソッドもあります。これらは、ビルトインとは異なる利点があります。

  23. それでも足りず、必要な場合があります。 Unicode::Collate::Locale(ロケール)です。 モジュールのように Unicode::Collate::Locale->new(locale => "de__phonebook", level => 1)->cmp($a, $b) の代わりに 次のように考えてください。 Unicode::Collate::->new(level => 1)->eq("d", "ð") は真であるが Unicode::Collate::Locale->new(locale=>"is",level => 1)->eq("d", " ð") は偽である。同様に、"ae"と"æ"は eq ロケールを使用しない場合、または英語のロケールを使用している場合でも、アイスランド語のロケールでは異なります。 さて、どうする?難しいですね。 で遊べます。 ucsort を使い、これらのことをいくつかテストしてみました。

  24. 文字列のパターン CVCV (子音、母音、子音、母音) にマッチする方法を考えてみましょう。 ニョーニョ ". そのNFD形式(これを入れるのを忘れてはいけない)は "ninx{303}o" となる。 さて、どうするんだ? 母音があるようにみせかけても [aeiou] (のようなことはできません(ちなみに、これは間違いです)。 (?=[aeiou])\X) というのも、NFDでも'ø'のようなコードポイントは は分解されません。 ! しかし、先ほどお見せしたUCAの比較では、「o」と同じようにテストされます。NFDに頼るのではなく、UCAに頼らなければならないのです。


???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ????


しかも、それだけではありません。人々がUnicodeについて抱く思い込みは、百万通りもあるのです。これらを理解しない限り、彼らのコードは壊れてしまうでしょう。

  1. エンコーディングを指定せずにテキストファイルを開くことができると仮定しているコードは壊れています。

  2. デフォルトのエンコーディングがある種のネイティブプラットフォームのエンコーディングであると仮定しているコードは壊れています。

  3. 日本語や中国語のWebページがUTF-16の方がUTF-8よりもスペースを取らないと仮定するコードは間違っています。

  4. Perlが内部でUTF-8を使用していると仮定しているコードは誤りです。

  5. エンコーディングエラーが常に例外を発生させると仮定しているコードは間違っています。

  6. Perl のコードポイントが 0x10_FFFF に限定されると仮定しているコードは誤りです。

  7. を設定できると仮定しているコード $/ をどのような有効なラインセパレータでも動作するようなものに変更するのは間違っています。

  8. 大文字小文字を区別する際に往復で等しいと仮定するようなコード lc(uc($s)) eq $s または uc(lc($s)) eq $s は、完全に壊れているし、間違っている。 を考えてみてください。 uc("σ")uc("ς") はいずれも "Σ" しかし lc("Σ") の両方が返されることはあり得ません。

  9. 小文字のコードポイントがすべて大文字のコードポイントを持っていると仮定するコード、またはその逆のコードは、壊れています。例えば "ª" は大文字を含まない小文字です。 "ᵃ""ᴬ" は文字ですが、小文字ではありません。しかし、これらは両方とも小文字のコードポイントであり、対応する大文字のバージョンはありません。わかったか?これらは ではない \p{Lowercase_Letter} であるにもかかわらず \p{Letter}\p{Lowercase} .

  10. 大文字小文字を変えても文字列の長さが変わらないことを前提としたコードは壊れる。

  11. 2つのケースしかないと思い込んでいるコードは壊れています。タイトルケースもあります。

  12. 文字だけに大文字小文字があると思い込んでいるコードは破綻しています。文字だけでなく、数字や記号、マークにも大文字と小文字があることが分かっています。実際、大文字と小文字を区別することで、その大まかなカテゴリを変更することができます。 \p{Mark}\p{Letter} . また、あるスクリプトから別のスクリプトに切り替えるようにすることもできます。

  13. 大文字小文字がロケールに依存しないことを前提としたコードは破綻しています。

  14. UnicodeがPOSIXロケールについて考えることを前提としたコードは壊れています。

  15. 基本的なASCII文字を得るために発音区分符号を削除できると仮定しているコードは、邪悪で、やはり、壊れており、脳に障害があり、間違っており、死刑を正当化するものです。

  16. ダイアクリティクスを前提としたコード \p{Diacritic} とマーク \p{Mark} が同じものであることは壊れています。

  17. を前提としたコード \p{GC=Dash_Punctuation} と同じだけカバーします。 \p{Dash} が壊れている。

  18. ダッシュ、ハイフン、マイナスがそれぞれ同じものであるとか、それぞれ1つしかないと仮定しているコードは壊れており、間違っています。

  19. すべてのコードポイントが1つの印刷列より多くを占めないと仮定するコードは壊れています。

  20. すべての \p{Mark} 文字が0列で表示されることはありません。

  21. 似たような文字があると仮定するコード は壊れています。

  22. を行う文字を想定したコード ない が似ているのは ではない は壊れています。

  23. コードポイントの数に制限があることを前提としたコードでは、1つのコードポイントだけでは \X がマッチするのは間違いです。

  24. を想定したコード \X で始まることはありません。 \p{Mark} の文字は間違いです。

  25. を想定したコード \X は決して2つの非 \p{Mark} は誤りです。

  26. を使えないと思い込んでいるコード "\x{FFFF}" は間違いです。

  27. 2つのUTF-16(サロゲート)コードユニットを必要とする非BMPコードポイントを、コードユニットごとに1つずつ、2つの別々のUTF-8文字にエンコードすると仮定したコードは誤りです。そうではなく、1つのコードポイントにエンコードされます。

  28. BOMを先頭に持つUTF-16またはUTF-32からUTF-8にトランスコードするコードは、結果のUTF-8の先頭にBOMを置くと壊れます。 これはとても愚かなことで、エンジニアはまぶたを切除されるべきです。

  29. CESU-8が有効なUTFエンコーディングだと思い込んでいるコードは間違っています。同様に、U+0000を以下のようにエンコードすると考えるコードも誤りです。 "\xC0\x80" がUTF-8であることは、壊れているし、間違っている。こいつらもまぶたの処置に値する。

  30. のような文字を想定したコード > は常に右を向いており < というのは、実際にはそうではないからです。

  31. 最初に文字を出力した場合を想定したコード X で、次に文字 Y として表示されます。 XY は間違いです。そうでない場合もあるのです。

  32. 英語を正しく書くにはASCIIで十分だとするコードは、愚かで、近視眼的で、無教養で、壊れており、邪悪で、間違っています。 彼らの首を切れ!極端すぎるようであれば、妥協することもできる。今後、彼らは片足の母趾だけでタイプすることができる。(残りはダクトテープで固定する)。

  33. をすべて想定したコード \p{Math} コードポイントが可視文字であることは誤りです。

  34. を想定したコード \w が文字と数字とアンダースコアだけであることは間違いです。

  35. を想定したコード ^~ が句読点であることは誤りです。

  36. を想定したコード ü がウムラウトを持つのは間違いです。

  37. などと信じているコード に文字が含まれているのは間違いです。

  38. を信じるコード \p{InLatin} と同じです。 \p{Latin} が凶悪に壊れている。

  39. と信じているコード \p{InLatin} が有用であることは、ほぼ間違いないでしょう。

  40. が与えられたと信じるコード $FIRST_LETTER をあるアルファベットの最初の文字として、そして $LAST_LETTER を、その同じアルファベットの最後の文字として、その [${FIRST_LETTER}-${LAST_LETTER}] が何らかの意味を持つことは、ほとんどの場合、完全に破綻しており、間違っており、意味がない。

  41. 誰かの名前に特定の文字しか含まれないと信じているコードは、愚かで、不快で、間違っています。

  42. UnicodeをASCIIに還元しようとするコードは単に間違っているだけでなく、その加害者は二度とプログラミングで働くことを許されるべきではないのです。期間限定です。私は、彼らが再び見ることを許されるべきだとさえ思っていません。なぜなら、それは明らかにこれまであまり良い結果をもたらしていないからです。

  43. テキストファイルのエンコーディングが存在しないことにする方法があると信じているコードは、壊れているし、危険です。もう片方の目も突き刺した方がいいかもしれません。

  44. 未知の文字を変換するコード ? は、壊れているし、愚かで、頭が悪いし、標準的な勧告に反しています。 そんなことしちゃだめだ! なぜダメなのかはRTFMをご覧ください。

  45. マークされていないテキストファイルのエンコーディングを確実に推測できると信じているコードは、ゼウスの稲妻だけが解決してくれる、傲慢とナイーブの致命的な混成物の罪を犯しています。

  46. を使えると信じているコード。 printf 幅を使用して Unicode データをパッドし、正当化することは、壊れており、間違っています。

  47. 指定した名前のファイルを作成することに成功したら、そのファイルに対して ls または readdir という名前のファイルを作成した場合、そのファイルはバグだらけで、壊れており、間違っていることがわかります。こんなことで驚かないでください!

  48. UTF-16が固定幅のエンコーディングだと信じているコードは、愚かで、壊れており、間違っているのです。プログラミングライセンスを剥奪してください。

  49. ある平面からのコードポイントを、他の平面からのコードポイントよりも若干異なって扱うようなコードは イプソファクト 壊れているし、間違っている。学校に戻りなさい。

  50. のようなものがあると信じているコード /s/i が一致するのは "S" または "s" が壊れている、間違っている。 驚かれることでしょう。

  51. を使用するコード \PM\pM* を使う代わりに、書記素クラスターを見つけるために \X は壊れているし、間違っている。

  52. アスキーの世界に戻りたい人は、心からそうするように勧められるべきだし、その輝かしいアップグレードに敬意を表して、彼らは提供されるべきなのだ。 無償 データ入力に必要な電気式以前の手動タイプライター。 彼らに送られるメッセージは、1行40文字の電信機で送られ、宅配便で手渡されるべきです。 停止する。


???? ???? ???? ???? ???? ???? ???? ???? ????


私が書いたものよりも「?のデフォルトのユニコード」がどれだけ多くなるかは分かりませんが。まあ、そうなんですけどね。 Unicode::CollateUnicode::LineBreak も、あります。 そして、おそらくもっと多いでしょう。

ご覧のように、Unicodeには、本当に する を心配する必要があります。 これまで デフォルトでUnicodeにする」なんてことはありえません。

その結果、私たちが「? 5.8で行ったように、これらのことを最初から考慮に入れて設計されていないコードに課すことは、単に不可能であることを発見することになるでしょう。あなたの善意の利己主義が、世界のすべてを壊してしまったのです。

そして、たとえそれができたとしても、正しく動作させるために多大な思考を必要とする重大な問題が残されているのです。 スイッチを切り替えることはできません。 脳以外には何もない、つまり リアルブレイン ということです。学ばなければならないことが山ほどあるのです。手動タイプライターへの回帰はともかく、無知のままこっそりやり過ごすのは無理な話です。これは21世紀であり、無知でUnicodeが消えていくことを望むことはできません。

それを学ばなければならない。期間限定です。すべてがうまくいく」ほど簡単にはいかないでしょう なぜならそれは多くのことを保証することになるからです しない これは、「すべてをうまくやる」方法があるという仮定を無効にするものです。

ごく限られた操作のために、いくつかの合理的なデフォルトを得ることができるかもしれませんが、私が思う以上に、もっともっと物事を考えないと無理です。

一例を挙げると、canonical orderは本当に頭痛の種になりそうです。???? "\x{F5}" 'õ' , "o\x{303}" 'õ' , "o\x{303}\x{304}" 'ȭ' であり、かつ "o\x{304}\x{303}" 'ō̃' はすべて一致するはずです。 'õ' ということですが、いったいどうするのでしょうか?これは見た目よりも難しいことですが、考慮しなければならないことです。 ????

Perlについて私が知っていることが1つあるとすれば、それはそのUnicodeビットが何をし、何をしないかであり、このことは私があなたに約束することです。 “ ̲ᴛ̲ʜ̲ᴇ̲ʀ̲ᴇ̲ ̲ɪ̲s̲ ̲ɴ̲ᴏ̲ ̲U̲ɴ̲ɪ̲ᴄ̲ᴏ̲ᴅ̲ᴇ̲ ̲ᴍ̲ᴀ̲ɢ̲ɪ̲ᴄ̲ ̲ʙ̲ᴜ̲ʟ̲ʟ̲ᴇ̲ᴛ̲ ̲ ” ????

デフォルトを一部変更しただけで、順風満帆になるわけではありません。 確かに、私は「? PERL_UNICODE に設定します。 "SA" しかし、それだけで、それもほとんどコマンドライン用のものです。 実際の作業では、上記のような多くのステップを踏んで、非常に慎重に行います。


???? ƨdləɥ ƨᴉɥʇ ədoɥ puɐ λɐp əɔᴉu ɐ ə↪Ll28C↩ɐɥ ʻl⅁ ?・・・?