byte[] в String без изменений

Цель - байты должны дойти в строку без изменений с точки зрения hex.

val str = new String(arr, StandardCharserts.US_ASCII)
str.getBytes(StandardCharserts.US_ASCII)

стока состоит из unsigned char

Ты вообще в курсе, что char в жабе это 2 байта?

в 9-ке пофиксить планируют же 8)

в 9-ке пофиксить планируют же 8)

Сделают 4?

str.getBytes(StandardCharserts.US_ASCII)

Так ведь это будет не то что он хочет, хотя я не понял зачем он хочет свой бред. Так получится что будут нулевые байты между данными.

только в памяти, но он это никак не увидит

вообщето 1, для случаев когда все символы ascii http://openjdk.java.net/jeps/254

но он это никак не увидит

Но ведь

байты должны дойти в строку без изменений с точки зрения hex

Хз как это понимать и зачем это надо.

мой блондиночный телепат подсказывает что это то самое что он хочет

«Улучшение» из серии «сделаем ещё хуже!».

Затем что оно потом идет в http-post со строкой внутри, по независящим от меня причинам. И когда оно конвертит байты с строку оно берет двухбайтный char, считает что скажем байт 0xff отрицательный и кодирует его в 65535.

Косячок, надо ISO_8859_1 - она 8ми битная, а не US_ASCII

ну если оно '\0' тоже будет кодировать - то тебе ничего не поможет, ну максимум похачить этот чудо код с которым ты работаешь

кстати что это за поделка такая?

Вот ее вроде не пробовал кстати

Да так, драйвер jdbc такой. Через http работает

народ должен знать своих героев, давай колись

Расскажу когда исправим драйвер

Кстати, можно ж в char сразу по 2 байта запихать, и потом уже в объект. Может сработать

можно ж в char сразу по 2 байта запихать, и потом уже в объект. Может сработать

Не может, а так и надо делать если я всё правильно понял.

надо смотреть сорцы той поделки - если оно тупо каждый char в два байта переводит - то да, но это маловероятно

«Улучшение» из серии «сделаем ещё хуже!».

Почему хуже?

1) если тебе нужен аналог reinterpret_cast, то ручками со сдвигами и битовыми масками играйся по перегонке byte[] -> char[] -> String(char[]).

2) если тебе нужно непойми что, то уточняй задачу, пока сам не поймёшь что хочешь.

я думаю там просто String.format("... %s", new String(bytes)) если честно. завтра гляну

Почему ничего не поможет. Кодировка это тупо пара кодер/декодер. Я писал свою кодировку — там делов на полчаса. Не припомню, чтобы в JDK где-то была проверка на \0, нет такого скорее всего. Так что без проблем можно засунуть в String нулевые байты. Если этому драйверу можно подсунуть свою кодировку для обратного преобразования в байты (скорее всего можно), то всё будет работать, хоть и через ректу.

не не, возможно там:

outputStream.write((byte)(str[i]>>>8))
outputStream.write((byte)str[i])

тогда оно клало на все и что не суть в старший байт - все будет на выходе

оно потом идет в http-post

base64?

Не, хрен.

Hex.encodeHexString(byteArray) = 4682ed57b14...
Hex.encodeHexString(new String(byteArray,StandardCharsets.ISO_8859_1).getBytes()) = 46c282c3ad57...

c ASCII аналогично. чую правда по два байта в символ в цикле пихать

Не, хрен.
getBytes()

действительно хрен, только не там где ты подумал, кто кодировку будет указывать?

автор драйвера :( сейчас зарылся в драйвер, пытаюсь понять в каком месте он перекодирует байт-массив. но судя по всему там кодировка не указывается, так что getBytes() без кодировки как раз корректная проверка

нашел, там просто аргумент засовывается в stringbuilder, который автоматом кастует byte[] в char[], что и плодит ошибку

не, это полный залет, увы. при попытке передать строку драйвер присобачивает кавычки и все портит. при попытке передать байт-массив - коряво кодирует его. если передавать объект - получаю вообще Arrays.toString(). печаль.

если передавать объект - получаю вообще Arrays.toString()

Arrays или именно объект?

getBytes кодирует стандартной кодировкой, которую можно указать через -Dfile.encoding виртуальной машине. Попробуй написать свою кодировку, которая будет тупо байт в char кастовать и обратно, может и получится. С UTF-8 оно правда будет не очень совместимо, так что может поломать программу в других местах, если кроме латинницы что-то используется.

если код синхронный то безопаснее править System.getProperty\setProperty до и после вызова

если ему передать массив char[] и запихать его в PreparedStatement через setObject()

Дык, а если ему String через setObject передать?

зы. а вообще нахрен, ты как красная девица шифруешься что у тебя там за говнокод, разбирайся сам