9

問題の説明："\:nnnn" Unicode入力の構文として Mathematicaを使用 します。たとえば、入る "\:6c34"と、"水"（中国語で「水」）が得られます。しかし、もし人が入りたいと思ったらどうなるでしょう"\:1f618"（キスを投げる顔）。私がこれを試したとき、私は得ました"ὡ8"、ではありません"a face throwing a kiss"。だから、Mathematicaは"\:1f61"私が入る前に評価し"8"ます。

質問： この評価を遅らせるにはどうすればよいですか、または一般的にユニコード入力を入力するにはどうすればよいですか（4文字を超える16進数の場合）。

ソフトウェアとハ​​ードウェアのプラットフォーム： 私はIntelMacでMathematica8を実行しています。MathematicaのコマンドラインバージョンとMathematicaノートブックの両方を試しましたが、同じように動作します。

ありがとうございました。

考察： Unicodeは拡張可能な標準であり、成長する可能性があります（そして、成長する可能性があります:)）。この標準を実装するソフトウェアシステムは、有効で有用であるために、この標準のサブセットのみを実装できます（8ビット、16ビット、または32ビットエンコーディング）。1つは、特定のソフトウェアパッケージのユーザーとして、ソフトウェアがUnicodeをサポートしていると言ったら、Unicodeのユニバーサルセットをサポートしていると想定してはなりません。

4

2 に答える 2

9

簡単な答え: Mathematica はこれらの文字を適切にサポートしていないため、これを行うことはできません。いくつかの回避策については、投稿の最後を参照してください。

いくつかのことを明確にするために：

~65000 を超える Unicode 文字を処理するために 32 ビット エンコーディングは必要ありません。Unicode で使用される最も一般的なエンコーディングである UTF-8 およびUTF-16は、マルチバイト エンコーディングです。これは、文字を表すために可変数のバイトが使用されることを意味します。UTF-16 では、2 バイトまたは 4 バイトを使用して文字を表すことができます。Mathematica カーネルはすべての 2 バイト シーケンスを文字列内の 1 文字として解釈するため、場合によっては無効な文字が生成されます（4 バイト シーケンスに遭遇した場合）。これはバグと見なされる場合があります。フロント エンドは、4 バイト シーケンスの処理方法について非常に不機嫌です。これは間違いなくバグです。

限定的な回避策

カーネル内で厳密に作業している場合 (ファイルから Unicode データを読み取る場合など)、この関数を回避策として使用して、2 単位 (4 バイト) の UTF-16 シーケンスの実際の Unicode コード ポイントを取得することがあります。

toCodePoint[{a_, b_}] /; 16^^d800 <= a <= 16^^dbff && 16^^dc00 <= b <= 16^^dfff := (a - 16^^d800)*2^10 + (b - 16^^dc00) + 16^4

使用できます

Split[ToCharacterCode[str], If[16^^d800 <= # <= 16^^dbff, True] &]

UTF-16 文字列を Unicode 文字に正しく分割するには (文字に応じて長さ 1 または長さ 2)。

これは見苦しく不便な回避策であり、フロント エンドでこれらの文字を表示することはできません。たとえば、unicode.org (少なくともCJKの場合、彼らはそれらを持っています）。

こちらもご覧ください

同じトピックに関する以前の質問を参照してください: Mathematica で UTF-8 でエンコードされたテキスト ファイルを読み取る

中国語を扱う場合は、別の問題に遭遇するかもしれません: Mathematica のフロントエンドが FontFamily オプションに従うようにする

于 2011-11-09T08:29:13.633 に答える