wl-encoding-and-regex

name	wl-encoding-and-regex
description	Use when generating or editing .wl or .m files, dealing with Unicode escapes, Windows Mathematica encoding issues, Japanese identifiers, or RegularExpression patterns in Wolfram Language.

.wl エスケープと正規表現の検証手順

制約は rules/30-encoding-safety.md に従う。このスキルは検証方法と修正手順を定める。

最重要: ノートブック出力コードの日本語

ClaudeQuery / ClaudeEval が生成する \``mathematica` コードブロック内の文字列では、日本語を必ずリテラル UTF-8 でそのまま書く。

書き方	判定	例
リテラル日本語	✅ 正しい	"一致 ✓"
\xNN エスケープ	❌ 絶対禁止	"\x4e00\x81f4"
\uXXXX エスケープ	❌ 禁止	"\u4e00\u81f4"
\:XXXX (.wl以外)	❌ 禁止	"\:4e00\:81f4"

• Style テキスト、Grid ヘッダー、エラーメッセージ、Print 文など 全ての文字列 に適用。
• .wl パッケージファイルの編集時のみ \:XXXX が許可される (Windows ShiftJIS 対策)。

A. Unicode エスケープの検証

形式	Mathematica での扱い	結果
\:3082	正しい	正常動作
\u3082	認識されない	文字化け
\x3082	認識されない	Syntax::stresc の原因

検証コマンド

grep -n '\u[0-9a-fA-F]\{4\}' file.wl
grep -n '\x[0-9a-fA-F]' file.wl | grep -v RegularExpression

修正例（Python）

import re
content = re.sub(r'\\u([0-9a-fA-F]{4})', lambda m: chr(int(m.group(1), 16)), content)

修正例 (Python、.wl ファイル向け \u → \:)

.wl パッケージファイル内では \:XXXX 形式を維持する必要がある (Windows ShiftJIS 対策)。リテラル日本語に置換すると新たな encoding 問題を引き起こすため、\u を \: に置換するだけに留める:

import re
# \uXXXX (4桁hex) を \:XXXX に置換
new_content = re.sub(r'\\u([0-9a-fA-F]{4})', r'\\:\1', content)

実際にあった例 (Stage B Week 2c-4 prelude、罠 #11)

ClaudeOrchestrator_workflow_diff_harness.wl の末尾 Print 文と ClaudeRuntime_stategraph.wl の usage 出力で、Python/JS の感覚で \u3001 (、) や \u3002 (。) を書いてしまい、ロード時に「未知のエスケープ文字列\u」エラー。.wl ファイル全体に対する一括置換で復旧した。

検出時は次のコマンドで全 .wl を一括チェックすると安全:

for f in *.wl; do
  grep -l '\\u[0-9a-fA-F]\{4\}' "$f"
done

B. RegularExpression 二重エスケープの検証

.wl ファイル内	PCRE の意味	正否
\\s	空白クラス	正しい
\\\\s	リテラル \\ と s	誤り
\\[	[ のエスケープ	正しい
\\\\[	余計な \\	誤り

検証コマンド

grep -n '\\\\[sntwdDWb\[\]]' file.wl

C. 日本語変数名の推奨パターン

(* 推奨: Unicode プロパティで境界判定 *)
RegularExpression["(?<![\\p{L}\\p{N}$])" <> varName <> "(?![\\p{L}\\p{N}$])"]
RegularExpression["[\\p{L}$][\\p{L}\\p{N}$]*"]

context / symbol は数字で始めない（日本語は可、数字は不可）

WL の context セグメント・シンボル名は letter（日本語を含む）か $ で始まらねばならず、数字で始められない。 日本語シンボルは有効（設計仕様V2 / 株価V2 は正常）。問題になるのは 先頭の数字。 slug やファイル名（日付始まり 20260622-... 等）から context / シンボルを機械生成すると踏みやすい。

BeginPackage["MyPkg`20260622Foo`"]  (* ✗ BeginPackage::cxt: Invalid context specified *)
BeginPackage["MyPkg`株価V2`"]        (* ✓ 日本語始まりは有効 *)
BeginPackage["MyPkg`W20260622Foo`"]  (* ✓ letter 始まりにすれば有効 *)

.wl を静的 parse する段階では context は文字列リテラル扱いで通ってしまい、実ロード時 （BeginPackage 実行）に初めて BeginPackage::cxt で落ちる（生成は成功なのに使う段でエラー）。 自由文字列から leaf を作るときは、先頭が数字なら letter を前置する（folder / slug / 表示名は数字始まりのままでよい。 補正するのは symbol leaf だけ）。同じ context を複数箇所で導出するなら全箇所に同一ガードを入れる。詳細は skills/wolfram-syntax-pitfalls 罠 #64。

D. Windows ShiftJIS 問題の回避

必要なら非 ASCII を \:XXXX に変換して ASCII ファイル化する。

result = ''.join(
    f'\\:{ord(c):04x}' if ord(c) > 127 else c
    for c in text
)

E. 総合検証スクリプト

import re

with open('file.wl', 'r', encoding='utf-8') as f:
    lines = f.readlines()

errors = 0
for i, line in enumerate(lines, 1):
    if re.search(r'(?<!\\)\\u[0-9a-fA-F]{4}', line):
        print(f"L{i} [A:unicode] \\uXXXX detected")
        errors += 1
    if 'RegularExpression' not in line:
        for m in re.finditer(r'(\\+)x([0-9a-fA-F]{2})', line):
            if len(m.group(1)) % 2 == 1:
                print(f"L{i} [A:hex] \\x{m.group(2)} detected")
                errors += 1
    if 'RegularExpression' in line:
        for pat in [r'\\\\s', r'\\\\n', r'\\\\t', r'\\\\w', r'\\\\d', r'\\\\b']:
            if re.search(pat, line):
                print(f"L{i} [B:double-escape] {pat}")
                errors += 1
    if 'RegularExpression' in line and re.search(r'\\[A-Za-z', line):
        print(f"L{i} [C:ascii-class] [A-Za-z] detected")
        errors += 1

print(f"\n{'PASS' if errors == 0 else f'FAIL: {errors} issue(s)'}")

実行時のバイト I/O (HTTP / JSON ファイル)

HTTP 送受信ボディや JSON ファイルの読み書きでの文字列⇔バイト変換 (Windows のシステムエンコーディング対策、ExportString["RawJSON"] vs DeveloperWriteRawJSONString のエンコード差、ISO8859-1 / UTF-8 の使い分け) は、独立 skill **skills/wl-runtime-byte-io`** に分離した。API 通信や JSON ストアで日本語が化けるときはそちらを参照。