Кодировка одного символа, с которой я пытаюсь работать, начинается с 0x7F и имеет длину 4 байта
Какие другие байты? У вас есть латинский текст в этой кодировке?
Если это «0x7f 0x ... 0x00 0x00», вы смотрите на UTF-32LE. Это также может быть два символа UTF-16 (либо LE, либо BE).
Большинство восточноазиатских кодировок используют 0x80-0xFF в качестве начальных байтов для символов не ASCII; я не знаю ни одного, кто использовал бы начальный 0x7F как что-либо кроме удаления ASCII.
ETA:
Должны ли быть знаки порядка байтов?
Нет необходимости в спецификации, если есть внеполосный способ сигнализации о том, что кодировка - «UTF-32LE» (возможно, она потеряна до того, как она попадет к вам).
Мне также пришлось работать с японской кодировкой, которая начинает каждый символ с 0xE3 и имеет длину три байта.
Это, конечно, UTF-8. Последовательность 0xE3 0x ... 0x ... привела бы к символу между U + 3000 и U + 4000, где живут хирагана / катакана.
Он правильно отображается на моем компьютере, если я выбираю японский язык в Windows, однако в нашем приложении он не отображается должным образом.
Тогда, скорее всего, ваше приложение является одной из прискорбных орд не-Unicode-совместимых приложений, все еще использующих «A» (*) версии интерфейсов Win32 внутри «W» с суффиксами. То, что вы можете читать в строке в соответствии с ее реальной кодировкой, является спорным: приложение, не поддерживающее Юникод, никогда не сможет отображать восточноазиатскую идеографию в западном регионе.
(*: по имени «ANSI», что является вводящим в заблуждение термином Windows для «какой бы ни была системная кодовая страница на данный момент». Вот почему изменение вашей локали повлияло на это.)
ETA (2):
ОК, взломали его. Это не какая-либо стандартизированная кодировка, с которой я встречался ранее, но ее относительно легко расшифровать, если вы исходите из предположения, что кодируются кодовые точки Unicode.
0x00-0x7E: plain ASCII
0x7F A B C: Unicode character
Символ, закодированный в escape-кодировке Unicode, можно рассчитать, взяв индекс в строке ключей A, B и C и сложив вместе:
A*0x1000 + B*0x40 + C
То есть это набор символов base-64, но это не обычный стандарт Base64. Небольшой эксперимент дает ключевую строку:
.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz
Символы ‘.’ И ‘_’ являются догадками, поскольку ни один из опубликованных вами символов не использует их. Нам нужно больше данных, чтобы узнать точную строку.
Так, например:
0x7F 3 u g
A=4 B=58 C=44
4*0x1000 + 58*0x40 + 44 = 0x4EAC
U+4EAC = 京
ETA (3):
Да, должно быть легко создать собственную строку Unicode, высасывая каждую кодовую точку вручную и присоединяясь как символ. Не совсем уверен, что доступно на любой платформе, которую вы используете, но любая Unicode-совместимая платформа должна иметь возможность просто создавать строку из кодовых точек (и, надеюсь, без необходимости перекодировать вручную в байты UTF-16LE).
Я подумал, что это должны быть кодовые точки Unicode, заметив, что три примера символов имеют первые escape-символы в том же общем диапазоне и в том же порядке номеров, что и их кодовые точки Unicode. Два других символа, по-видимому, менялись случайным образом, поэтому весьма вероятно, что кодирование кодовой точки выполняется с прямым порядком байтов, и, вероятно, кодировка base-64 в виде 6 - это столько бит, сколько вы можете получить из читаемого ASCII.
Стандартный Base64 сам по себеrts с буквами, которые помещали бы что-то, начинающееся с числа, слишком далеко, чтобы быть в Основной Многоязычной Плоскости. Итак, я начал угадывать с «0123456789ABCDEFG ...», который был бы другим очевидным выбором ключевой строки. В результате были получены числа, которые были близки к кодовым точкам для заданных символов, но немного занижены. При вставке дополнительного символа в начале ключевой строки (так что цифра «0» не соответствует цифре 0), один из символов оказался правильным, а два других - очень близкими; у того, который был прав, не было строчных букв, поэтому чтобы изменить только строчные буквы, я вставил другой символ между прописными и строчными буквами. Это пришло с правильными номерами.
Не гарантируется, что это действительно правильно, но (кроме произвольного выбора вставленных символов), вполне вероятно, что так оно и будет.